Home

Kleyna Moore Almeida GARANTIA DA QUALIDADE DE SOFTWARE

image

Contents

1. Reusabilidade 2 1 3 2 T CNICAS DE AVALIA O 2 1 3 2 1 GOAL QUESTION METRIC GQM A metodologia GQM Goal Question Metric Objetivo Pergunta M trica de Basili BASILI et al 1994 tem sido muito utilizada atualmente para definir um processo de medi o que viabiliza o acompanhamento e a avalia o do processo de produ o de software Basili emprega esta metodologia para definir um processo de coleta e an lise de dados BASILI et al 2000 O primeiro passo de um programa de m tricas estabelecer uma refer ncia de forma que o progresso possa ser avaliado em termos dos objetivos e atrav s de compara o com esta refer ncia Depois executar a metodologia GQM da seguinte forma ALMEIDA et al 2003 Primeiro selecionar alguns objetivos do processo que estejam em conformidade com os objetivos organizacionais e definir esses objetivos de modo que sejam quantific veis e mensur veis 44 Para cada objetivo identificar perguntas para serem respondidas com a finalidade de coletar informa o sobre a situa o do objetivo se est sendo alcan ado ou n o Finalmente identificar m tricas que ajudem a responder cada pergunta Algumas delas s o diretas simples itens de dados por exemplo o valor total gasto em reparo Outras m tricas s o indiretas calculadas a partir de um ou mais itens de dados Segundo MCGARRY 2001 o modelo GQM resolve o problema de defini o de m tricas
2. 4 retorno i 180 Diagrama de Seqii ncia Extra o de Dados da Plataforma Prim ria Extra o PlatMat extrairPlatPrim l l p 1 getPlatPrim pH 2 retorno belos Cedo 3 getDadosConf gt 4 retorno ie atte yw Bas em pte Al 5 getDados Amb 6 retorno Lae SS ee oe ee ee ee a ee et fact A Diagrama de Seqii ncia Extra o de Dados de posi o da Plataforma Primaria Extra o PlatMat HistPosMat extrairPosEstPrim i t I I 1 get i gt 2 retorno EE a e PPA E E Se ol 3 getPos i 4 get I 5 retorno nee ee ee q aN 6 retorno 7 calcularPosEst Diagrama de Seqii ncia Extra o de Dados do Acompanhamento Extra o PlatMat HistPosMat extrairAcomp I 1 getAcomp l I 2 retorno A l ji l I l l I i extrairAcompD adosHisi 1 getPos 2 get 3 retorno 4 retorno 5 calcularPosEst 181 Diagrama de Seqii ncia Atualiza Acompanhamento AtualPlat PlatMat HistPosMat atualPlat gt 1 inserirPos 2 criar 3 retorno am m m m oo m e m 4 retorno 5 getPos
3. Sem restri es Data da pr xima revis o o Jcom restri es PEM C Refazer para nova revis o Data da pr xima revis o f E JRevis o n o completada Problemas Listar os problemas detectados que n o s o n o conformidades por exemplo o artefato a ser verificado n o foi produzido e as devidas a es decorrentes para resolver o problema o Gerente de Re so justificou e autorizou por escrito a dispensa da elabora o do artefato que se encontra em Problemas A es Decorrentes O Question rio de Sugest es para Melhoria da Garantia da Qualidade deve ser preenchido e entregue junto a este Relat rio Sua CONTRIBUI O fundamental para o cont nuo progresso da melhoria da NOSSA QUALIDADE FIG 4 2 3 1 1 b Relat rio da Revis o 99 42 32 REVIS O A Revis o foi realizada da seguinte forma T cnica Utilizada As t cnicas de leitura elaboradas no Planejamento da Revis o baseadas nas T cnicas de Leitura OO para os artefatos produzidos na Engenharia de Dom nio veja ANEXO 2 conforme apresentadas na FIG 3 1 2 2 1 Tempo Despendido Uma m dia de tr s horas por cada reuni o no decorrer de tr s semanas Fatores de Influ ncia A falta de conhecimento do dom nio do projeto piloto dificultou o entendimento por parte dos revisores para realiza o da inspe o individual requerendo assim mais tempo de treinamento para explicar mais detalhadamente o dom nio do Controlador
4. Recep o de dados Dados Navega o Camada de Capacidade servi os Dados Detec o T tico Extra o de dados Dados Navega o Dados Detec o Sistemas opera es a b pera A Vento relativo Velocidade Plataforma manual autom tico apresenta es extemos emprego local remoto local atributos etc Manual automatico autom tico manual Ss aves ela oe lee 5s A Camada de Ambiente de Opera o plataforma sistem a Li operacional Banco de Dados sistema de redes remoto d pas j Sistemas Sistema de Armas identifica o _ po ee N NH I inki LinkYb imka MD Camada de Tecnologia do Dominio m todo disciplinas etc Texto formatado fies Gees ee Hod metro radar Camada de Tecnologia de Implementa o algoritmos tipos abstratos de dados etc d GPS anem metro DGPS 178 Al a optica Modelo Tipo de Neg cio do Controle T tico type Plataforma Prim ria dadosConfiguracao dadosAmbiente type Plataforma numAcomp dadosPlataforma AS type Acompanhamento dadosTaticos Arquitetura do Controle T tico type Histo ricoPo si o posicao data hora 179 O rf Z metaclass lt E Visao O Z ctw so ew metaclass metaclass of Controle Disp ach an
5. 168 Garantia da Qualidade de Software Leitura Vertical 6 Vers o 1 2 RELV601 03 Data da vers o 03 03 2004 TLV 6 Arquitetura do Dom nio X Especifica o de Componentes Objetivo Verificar se todas as classes do diagrama arquitetural do dom nio e seus relacionamentos est o capturados na Especifica o de Componentes Pr requisito Esta leitura requer que o diagrama Arquitetura do Dom nio tenha sido aprovado pelo Processo Controle de Qualidade Entrada para o processo 1 Arquitetura de Dom nio representada por diagrama de classe em camada 2 Especifica o de Componentes representados por diagrama de classe com nota o lollipop Procedimentos I Analise na Arquitetura do Dom nio as classes de cada camada para entender as especifica es dos componentes ENTRADAS Arquitetura do Dom nio Especifica o de Componentes SA DAS Relat rio de Discrep ncias A Para cada classe da Arquitetura do Dom nio execute os seguintes passos 1 Encontre a especifica o de componente correspondente e a marque com um asterisco azul O nome do componente deve ser similar ou sin nimo ao nome da classe de especifica o de componente Caso n o consiga encontrar a especifica o do componente preencha a Tabela de Discrep ncia pois um componente n o est presente na Especifica o de Especifica o de Componentes 2 Verifique se a classe tem algum relacionamento de associa o heran a agrega o ou composi o Cas
6. O m todo de Leitura baseado em Cen rio tem apresentado uma taxa mais alta de detec o de defeitos do que ad hoc e checklist PORTER et al 1995 MILLER et al 1998 REGNELL et al 1999 taxa superior a 35 Isto ocorre porque os cen rios ajudam a focar classes espec ficas de defeitos e independem da habilidade de identificar outras classes de defeitos 2 1 2 2 1 TECNICA DE LEITURA BASEADA EM PERSPECTIVA Na T cnica de Leitura baseada em Perspectiva o revisor ao preencher a lista de confer ncia deve assumir uma perspectiva espec fica revisor avaliador visando o objetivo de inspecionar e validar o documento A lista de confer ncia deve ser composta por um conjunto de aspectos e cada aspecto deve conter uma s rie de quest es relacionadas Os 36 aspectos devem considerar o tipo de produto a ser especificado e os atributos de qualidade necess rios para atender a satisfa o do cliente Cada quest o deve ter op es de resposta e deve ser elaborada de forma que a resposta positiva assegura adequa o ao objetivo do aspecto proposto Ap s a conclus o da inspe o deve ser elaborado um documento onde devem estar registrados os resultados obtidos coment rios e sugest es de melhorias PAGLIUSO et al 2002 Nesta t cnica os revisores s o solicitados a desenvolver abstra es do sistema pelos requisitos utilizando diferentes pontos de vista Para um projeto OO as abstra es das informa es importantes j
7. Os m todos ad hoc e checklist s o os dois m todos de detec o de defeitos mais utilizados LAITENBERGER 2002 Entretanto Cheng identifica alguns dos principais problemas dos revisores ao utilizar esses m todos CHENG et al 1996 tais como Os revisores s o sobrecarregados com informa o excessiva Desconhecimento dos revisores sobre o assunto de neg cio e detalhes do projeto Responsabilidades amb guas N o tem ponto de partida bem definido devido aos itens acima Intera o limitada entre revisores e equipe de projeto Participa o de revisores inexperientes Procedimento de revis o n o sistem tica e conjunto de perguntas despreparadas para questionar sobre o projeto No m todo de Leitura baseado em Cen rio o cen rio um procedimento que o revisor de um documento deve seguir durante a inspe o O cen rio pode ser ben fico ao dirigir a aten o dos revisores para os defeitos mais cr ticos da organiza o LAITENBERGER 2002 Neste m todo os revisores l em um documento com diferentes perspectivas REGNELL et al 1999 de forma que diferentes revisores tenham diferentes 35 responsabilidades e sejam direcionados em suas leituras por um cen rio espec fico que se agrega ao construir o modelo inv s de uma leitura passiva Existem duas variantes da t cnica de Leitura baseada em Cen rio Leitura baseada em Defeito PORTER et al 1995 e Leitura baseada em Perspectiva BASILI et al
8. o da Qualidade de Projetos OO BANSIYA et al 2002 com a finalidade de medir a qualidade do projeto OO desenvolvido no processo baseado em reuso Assim foram estabelecidos seis objetivos do ponto de vista dos atributos de qualidade TAB 2 2 3 1 1 TAB 4 2 4 1 3 Os objetivos perguntas e m tricas relativos qualidade do projeto OO a Compreensibilidade do projeto CP Objetivo controlar a capacidade de compreens o e entendimento do projeto Quest es M tricas 1 O qu o f cil de se aprender e entender N mero m dio de antecessores Acoplamento direto da classe Coes o entre m todos na classe N mero de m todos Medida de acesso aos dados N mero de m todos polimorfos Tamanho do projeto em classes b Efetividade do projeto EfP Objetivo controlar a capacidade efetiva do projeto Quest es M tricas 1 Quanto das funcionalidades e comportamentos N mero m dio de antecessores desejados foram alcan ados Medida de agrega o Medida de acesso aos dados Medida de abstra o funcional N mero de m todos polimorfos 105 c Extensibilidade do projeto EsP Objetivo controlar a capacidade de inser o de novos requisitos no projeto Quest es M tricas 1 Quanto novos requisitos podem ser introduzidos N mero m dio de antecessores no projeto Acoplamento direto da classe Medida de abstra o funcional N mero de m todos polimorfos d Flexibilidade d
9. 1997 Portanto os benef cios da qualidade resultantes da aus ncia de n o conformidades possibilitam que as organiza es minimizem o esfor o do retrabalho reduzindo o tempo de desenvolvimento de software e os custos Segundo ROSENBERG et al 1998 os problemas que n o s o encontrados e corrigidos at a fase de teste custam 14 vezes mais do que corrigi los na fase de requisitos A implanta o de um programa de qualidade deve come ar pela defini o e implanta o de um processo de desenvolvimento de software Este processo deve ser documentado compreendido e seguido por todos os profissionais nele envolvidos O m todo utilizado para exercer a o sobre o processo o ciclo de Deming DEMING 1982 conhecido como PDCA Plan Do Check Act Na FIG 1 3 1 apresentada um diagrama explicativo do ciclo PDCA de Deming e da espiral de ascens o de qualidade O ciclo de Deming representado por um c rculo em rota o no sentido hor rio demonstrando um desenvolvimento iterativo e a necessidade da melhoria cont nua Na espiral de ascens o de qualidade apresentado o uso sistem tico do PDCA que possibilita a melhoria da qualidade 24 s Qualidade do Produto de n Software ATUA NO PROCESSO EM FUN O DOS a Sadie E Action Plan RESULTADO DETERMINA A PARA ATINGIR E es Dae CTION PLAN ASMETAS ere AE CHECK DO VERIFICA os PARA O EFEITOS DO TRABALHO TRABALHO
10. Idantitfica o da ventica o Fro bto Conbokidor Taboo Id do arteTat CTNHCODNWOS Werltioa dor Dat da vendoa o Holds conhsclmento de dominio L eaxo jmen Tas Dados da Vente agao 4nallae da Ventica gaa Totalde Tempo ab Toba de lk rme do ciechi Prepara o az Tobal de k mr veriicados Redlza o da veriica o 2H de lene alerdidor Dkperdido 2H de likre N o akrdidos Buan da ds az Toblde ler N o spllcavels P glreas veridcadas Total de Detlt o Deteo tido c Resultado da verntica o H o o alte peste 7 Dak dapr dma veridoa o Lo Jem merges aio Ai ani com Hi Ein i _ _ Peteerpora nova verhca o ala da pr dma verhica o i I Los lics m o comple lada Problemas Us tar or problemas de eclador que n os cecomormidader por ex careta a ser verhcado n o prodicido ar devidar a es deca nk pararerdyver problema Geren de Re rolus ico autorizou pore mrio a dispensa da elabora o do aketlo que se enconha em areca o GuecHondne de Sugectes para Melhora da Samanta da Qualidade deve cer preenchido e entregue bina erk Relal do Cat COM TRIBUS 2 dirdamental para o confine progresso da melhora da NO CDS O MAL ADE Da ti 4cdnaturada vertoador Das 21 200 FIG 4 2 2 2 1 c Relat rio de Verifica o de Necessidades do Cliente e Gloss rio 4 2 3 ETAPA SUBPROCESSO DE REVIS O 4 2 3 1 PLANEJAMENTO DA REVIS O O Planejamento da Revis o foi realizada da seguinte form
11. Manual da Checklist on ee EE j PI ano de Ger ncia spy ai Plano de Verifica o wW de Projeto gt Relat rio de Consultorde artefato asset Ds RE Rio Qualidade Verifica o Verifica o SPV A2 Verificador FIG 3 2 1 2 1 1 Diagrama de Constru o do Subprocesso de Verifica o SPV 65 Este subprocesso inicia o Planejamento da Verifica o SPV A1 quando do recebimento da Manual da Qualidade pelo Comit de Qualidade para obten o dos requisitos e objetivos do projeto com o prop sito de produzir um plano de verifica o PGQSP da Verifica o cronograma das atividades de verifica o e elabora o das listas de confer ncia checklists adequadas aos artefatos assets a serem verificados O Plano de Ger ncia do Projeto artefato do Processo de Fornecimento de GURGEL 2004 deve ser aderente a este plano e cronograma de verifica o importante ressaltar que todos os produtos de qualidade gerados neste subprocesso devem ser incorporados no Manual da Qualidade Portanto o Gerente de Projeto deve obter os dados 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 asset supracitado que foi produzido para uma determinada vers o conforme cronograma do projeto definido no Plano de Ger ncia do Projeto Ap s dois dias teis do recebimento o verificador deve enviar o Relat
12. o de m tricas para correlacion las ao produto de software permite uma avalia o da sua qualidade importante ressaltar que cada caracter stica de qualidade depende da classe do produto de software e da tica do usu rio interno ou externo CMM PAULK et al 1993 classifica as organiza es quanto ao nivel de maturidade Entende se como n vel de maturidade como os est gios bem definidos que evoluem para um processo de software maduro ou seja cada est gio compreende em um conjunto de objetivos que quando alcan ados estabiliza um componente do processo de software Desta forma uma organiza o madura possui uma capacidade organizacional para gerenciar o desenvolvimento e manuten o de software Este modelo avalia as reas de um processo KPA key process areas Para cada KPA existem requisitos estabelecidos metas comprometimentos e capacidades e orienta es pr ticas chave para o seu atendimento Ent o uma organiza o evolui de um n vel para outro atendendo aos requisitos estabelecidos para as KPAs H 18 KPA s de processo distribu das nos n veis de maturidade com exce o do N vel 1 Inicial como apresentado na FIG 7 3 2 Na FIG 7 3 2 tamb m s o apresentadas de forma resumida para cada n vel de maturidade as caracter sticas os objetivos e as atua es para mudan a de n vel A Norma 15504 ISO15504 1998 o projeto SPICE que consiste em elaborar um padr o aplic vel melhoria de proces
13. odo Estudo C s0 E RR RAN RR EEES EER RTE 89 Participantes do Estudo CaSO iieciisiisinicesisrriciseresiis rninaco iin isian 89 Objetivo do Est do de gedit iiaii ea enin a S a anaa 90 Monitora o do Estudo de I cca pyran saccptavonenedieveceaactanientueiaedeaieasciudgdenrseasdneez 90 Elapa Garanin A Qualidade sa e E E E E es 90 Etapa Subprocesso de Verifica o sia aas ada IC tj 92 4 2 2 1 Planejamento dy VY BE A ssa E E EAEE ideias enfia 92 4 2 2 2 e e a a ceded E EAR A E RR career 95 4 2 3 Etapa Subprocesso de Revis o ocecicnciosiii esisiini sneis i eks iii 97 4 2 3 1 Planejamento DOIDO occisione inso sansir liaeean 97 4 2 3 2 EAA EE aa E E ensaiar ta ninho adia agp nda bacanas cpa spas 100 4 2 4 Etapa Subprocesso de Medi o e AVINA O quo muiito pda ad qt 102 4 2 4 1 Planejamento d RG sogra 102 4 2 4 Indicadores de Qualidade do Processo de Verifica o e Revis o IQPVR 103 4 2 4 1 2 Indicadores de Produtividade do Processo de Verifica o e Revis o IPPVR 104 4 2 4 1 3 Indicadores de Qualidade do Projeto OO Baseado em Reuso IQPOOR 105 MAR MII ennn ea E E EE E REEE ida ad 109 4 3 Avalia o do Estudo I esc dcestcsenaedctisa a osiinsa enii ness 111 5 CONOR ROD adia 111 51 Beneficios aiai RR AN DA GR RO 113 5 2 Trabalhos PMDE sussa issira nesai reinar osani nnas redia iroa odasi raais 114 6 REFER NCIAS BIBLIOGR FICAS j ssssesssssssssssssssssessscesnsssss
14. requerem m tricas diferentes das tradicionais de produto tamanho complexidade desempenho e qualidade CHIDAMBER et al 1994 HITZ 1996 LI 1993 Al m disso muitos dos modelos de qualidade e de m tricas dispon veis para an lise de software OO s podem ser aplicados ap s a fase de implementa o do produto Ent o com o intuito de melhorar a redu o do retrabalho durante e ap s a implementa o pela detec o e remo o de n o conformidades como tamb m melhorar a elabora o dos planos de teste e planejamento dos recursos h uma necessidade por m tricas e modelos que possam ser aplicados nas fases do desenvolvimento de software Bansiya e Davis apresentam um Modelo de Hierarquia para Avalia o da Qualidade de Projetos OO BANSIYA et al 2002 Neste modelo as estruturas e os comportamentos das classes objetos e seus relacionamentos s o avaliados usando um conjunto de m tricas de projeto OO Este modelo relaciona as propriedades de projeto com os atributos de qualidade Bansiya fornece uma ferramenta de software QMOOD 4 para avalia o de qualidade para v rios projetos OO que permite tratar a avalia o de projeto automaticamente BANSIYA 1997 Esta ferramenta facilita a coleta de dados de medi es de componentes de projeto implementados em C Baseado nos atributos da ISO 9126 Bansiya e Davis selecionam e identificam seis atributos de qualidade que s o apresentados na TAB 2 1 3 1 1 BANSIYA et al
15. resolu o do problema 4 Atrav s da an lise de Pareto ARTHUR 1993 os problemas devem ser classificados por categoria em uma tabela ou utilizando o Diagrama de Pareto PALMER 1997 quadro de barras de categorias de frequ ncia de ocorr ncia em cada categoria com as categorias ordenadas da maior para a menor fregii ncia 5 Para cada problema identificar as causas e analis las 6 Para cada problema o registro do problema a resolu o do problema encontrada e sua aplica o devem ser documentadas no relat rio de acompanhamento e este enviado ao Grupo de GQS Corporativo Gerente de Reuso e Grupo de M tricas Ao Subprocesso de Medi o e Avalia o tamb m enviado o cronograma atualizado para que o Grupo de M tricas juntamente com o relat rio de acompanhamento possa alimentar sua base de dados gerenciais para obten o de indicadores de produtividade de processo de desenvolvimento de software O resultado desta atividade deve estar acordado pelos revisor e autor de forma a Fazer com que as atividades de elabora o do artefato progridam de acordo com o Plano de Ger ncia do Projeto baseadas em uma avalia o da situa o do artefato Manter o controle geral do projeto atrav s da aloca o adequada de recurso 61 Redirecionar o projeto ou determinar a necessidade de um planejamento alternativo Avaliar e gerenciar situa es de risco que possam comprometer o sucesso do projeto 3 2 1 2 N V
16. Processos de Ciclo de Vida Organizacional Ger ncia Melhoria Sr Infra estrutura Treinamento Ger ncia de Proorama de Reuso Processos de Ciclo de Vida Aquisi o bb af a ia ng io es vida de Longo Prazo Opera o genharia de Dom nio Manuten o Processos de Ciclo de Vida de Ap io Documenta o Walida o Ger ncia de Configura o Revs o Conjunta Ger ncia de Ativo Garantia da Qualidade Auditoria Verifica o Resolu o de Problema FIG 7 3 3 1 Processos de ciclo de vida da ABNT 12207 com as extens es para processos de ciclo de vida de reuso da IEEE 1517 Os processos de ciclo de vida do software atividades e tarefas que s o exigidos para praticar reuso s o apresentados em quatro categorias de reuso veja FIG 7 3 3 1 1 Desenvolvimento opera o e manuten o de produtos de software com assets com a adi o das atividades e tarefas de reuso os processos de ciclo de vida fundamentais empregam modelos de dom nio arquiteturas de dom nio e assets para desenvolver e manter 137 produtos de software Agentes respons veis pela execu o dos Processos Fundamentais s o adquirente fornecedor desenvolvedor operador e mantenedor 2 Desenvolvimento e manuten o de assets o processo de Ger ncia de Dom nio especifica um processo de ciclo de vida para um projeto de asset fornecendo asset que pode ser usado por v rios projetos Este asset pode ser usado por processos do ciclo de vida fundament
17. Uma pe a de informa o tang vel que criada alterada e usada durante o desenvolvimento das atividades representa uma rea de responsabilidade e pass vel de ser colocada separadamente sobre um controle de vers es Um artefato pode ser um modelo um elemento de modelo ou um documento JACOBSON et al 1999 ASSET s m Asset um artefato ou conjunto de artefatos que tenham sido criados com um prop sito expl cito de ser reutilizado em outros esfor os de desenvolvimento Neste sentido ele a unidade que ir ser produzida utilizada e gerenciada para permitir o reuso RATIONAL SOFTWARE CORPORATION 2001 CARACTER STICA s f Um atributo de um sistema que expressa ou afeta diretamente o usu rio o desenvolvedor ou outra entidade que interage com o sistema NIST 1994 COMPONENTE s m Um pacote coerente de artefatos de software que podem ser desenvolvidos independentemente e entregues como uma unidade e que podem ser compostos ou trocados com outros componentes para formar algo maior D SOUZA et al 1998 CONFORMIDADE s f Atendimento a um requisito ABNT9000 2001 DEFEITO s m Passo processo ou defini o de dados incorretos por exemplo um comando incorreto IEEE610 12 1990 DOMINIO s m O espa o do problema NIST 1994 EFIC CIA s f O grau em que um sistema realiza o que dele se espera fazer a coisa certa SEPIN 2002 EFICI NCIA s f O grau em que um sistema utilizou
18. atividades selecionadas e estimativas de esfor o empregadas pelo consultor de GQS e equipe de desenvolvimento no processo de Verifica o Revis o CSA Femme Listas de Verifica o Revis o GEC Entrada para Atividade a da da Atividade FIG 4 2 1 1 Plano de GQS do Projeto PGQSP Na FIG 4 2 1 2 apresentado um modelo de Hist rico de Vers es para ser introduzido em todos artefatos produzidos com a data da vers o n mero sequencial da vers o descri o sucinta da vers o autor respons vel pela vers o o nome do revisor e por quem foi aprovado Data Vers o Descri o Autor Revisor Aprovado por lt dd mm aaaa gt lt X X gt lt detalhes gt lt nome gt lt nome gt lt nome gt FIG 4 2 1 2 Hist rico de vers es O cronograma para as verifica es revis es de GQS dos artefatos do projeto piloto deve ser inserido no cronograma do projeto piloto obedecendo aos itens apresentados na FIG 4 2 1 3 N Verifica o Atividade Tarefa Data de Data de Esfor o homens hora Revis o In cio T rmino GOS Equipe de Projeto lt Numero lt Atividade em Tarefa da lt Data de orate ae lt quantidade lt quantidade em sequencialde quesedaa a tas ae em homens homens hora gastos verifica verifica Atividade a acess ronda hora gastos elos desen pieces Sniipagao ser verificada verifica o verifica o 8 p revisoes do revisao de ievisadas Irevi
19. ceeeececcccesceccccssceccccsseccccceseeccecseecceaseeceees 82 TAB 4 2 4 1 1 Os principais objetivos perguntas e m tricas relativos aos estados das n o conformidades encontradas durante a verifica o e revis o dos artefatos 104 TAB 4 2 4 1 2 Os principais objetivos perguntas e m tricas relativos previsibilidade de esfor o associado verifica o e revis o dos artefatos 105 TAB 4 2 4 1 3 Os objetivos perguntas e m tricas relativos qualidade do projeto OO 105 TAB 4 2 4 1 4 Fun es de c lculo das medi es das qualidades do projeto OO com os ndices definidos por BANSIYA et al 2002 nine 107 TAB 4 2 4 1 5 Especifica o do Indicador de Qualidade do Processo de Verifica o e RE VIDA censacenerradesos niafades saindo Dracena da aa L escovas ala EOE Alana se eddie ser D Sab adoro abas duadi ias 108 TAB 4 2 4 1 6 Formul rio associado ao procedimento de Coleta de Dados 108 12 LISTA DE ABREVIATURAS E S MBOLOS ABREVIATURAS ADC Acoplamento Direto da Classe CMC Coes o entre M todos na Classe MAD Medida de Acesso aos Dados MAF Medida de Abstra o Funcional MAg Medida de Agrega o NHgq N mero de Hierarquia NM N mero de M todos NMA N mero M dio de Antecessores NMP N mero de M todos Polimorfos TIC Tamanho da Interface da Classe TPC Tamanho do Projeto em
20. existem a informa o est descrita em diferentes diagramas e documentos como diagramas de classes e intera o descri o de classes e outros Mas apesar disso os defeitos ainda existem e precisam ser identificados ROCHA et al 2001 2 1 2 2 2 TECNICA DE LEITURA ORIENTADA A OBJETO A T cnica de Leitura Orientada a Objeto TLOO um conjunto de sete t cnicas diferentes para leitura de projeto OO Estas t cnicas foram desenvolvidas para fornecer um procedimento para as inspe es individuais dos diferentes diagramas e documentos de projeto OO e identificar as classes de defeitos gen ricos relativos especifica o de requisitos e ao projeto TRAVASSOS et al 2003 O processo de leitura utilizando TLOO baseia se em t cnicas horizontais e verticais para apoiar as revis es Na FIG 2 1 2 2 2 1 apresentado o conjunto de TLOO TRAVASSOS et al 2003 onde cada linha entre os diferentes artefatos de software representa uma t cnica de leitura definida para ler um documento comparando o com outro Descri o dos Casos de uso requisitos Diagrama de Diagrama de Estados Intera o t Leitura vertical Leitura horizontal Especifica o de requisitos Diagrama de Descri o dos Classes Requisitos FIG 2 1 2 2 2 1 Conjunto de TLOO 37 Atrav s das leituras horizontais assegura se que todos os diagramas de projeto estejam consistentes E atrav s das leituras verticais assegura se consist n
21. incluir a dist ncia calculada no PMA inferior a definida como segura Curso Normal 1 O sistema apresenta mensagem de alarme de colis o com o n mero do acompanhamento e o PMA do mesmo Cursos Alternativos 175 Modelo de Contexto do Dom nio do Controlador T tico Sistemas Externos Sensores de Navega o ext service request ext replay nav service request Controle T tico usu service request usu service display det service request Legenda S ao z entidade externa ensores de Detecc o Usu rio lt gt dominio aa O fluxo de dados fluxo de dados Modelo Conceitual do Controle T tico Sensor de Navega o Sensor de Detec o Sistema Externo Qar fornece Dados de Am biente Ou fornece Hist ricoPosi o usa 0 Doo 1 Calculador Navega o EEE as Plataforma Calculador T tico RE ES fs 1 Plataforma Prim aria Acompanhamento fornece Doo a 1 a 0 fh Dados T ticos Diss 1 pertence 176 Diagrama de Casos de Uso do Dom nio do Controle T tico Controlador T tico inserir dados de sensores de navega o am biente definir configura o cancelar operador abrir acompanhamento sensores de detec o atualizar dados da plataforma uses acompanhamento alarme de colis o extrair dados sistemas externos I
22. na TAB 3 2 2 1 s o apresentados os assets que devem ser gerados pelo rg o contratado para fornecimento do software com os artefatos que o comp e frutos de uma atividade espec fica de um processo definido de GURGEL 2004 Para o asset ser aprovado ele deve atender a um crit rio de aprova o inerente aos artefatos gerados que o comp e Al m disso a documenta o deve ser leg vel identific vel e completa e tamb m protegida de acordo com o grau de seguran a da informa o contida no asset conforme especificado no Contrato IEEE1517 1999 81 TAB 3 2 2 1 Tipos de assets produzidos pelo Processo de Desenvolvimento de Software baseado em Reuso na MD Assets Artefatos Atividade Processo Dom nio Modelo de Contexto An lise de Engenharia de Modelo Conceitual Dom nio Dom nio Modelo de Casos de Uso do Dom nio e Cen rios Modelo de Caracter sticas Ontologias Taxonomias Linguagens de Dominio Arquitetura de Modelo Tipo de Neg cio Projeto de Engenharia de Dom nio Interfaces da Camada de Neg cio e Tipos de Dominio Dom nio Dados Interfaces da Camada de Aplica o Arquitetura de Dominio Componente de Especifica o de Componentes de Dominio Projeto de Engenharia de Dom nio Interfaces de Componentes de Dominio Dom nio Dom nio Componentes C digo de Componente Constru o do Processo de Teste de Componentes Software Desenvolvimento Os verifica
23. o 7 4 1 do AP NDICE 4 e os modelos de relat rios correspondentes de acordo com o artefato a ser verificado A seguir na FIG 4 2 2 1 1 s o apresentados os modelos supracitados em a b c em d a lista de confer ncia e em e o Relat rio de Verifica o para Necessidades do Cliente e Gloss rio PGQSP Plano de Garantia da Qualidade de Software do Projeto Objetivo Definir a estrutura de GQS adotada para o projeto piloto Controlador T tico Respons vel Consultor de GQS CGQS Templates VENC001 03 ESTUDO Caso CT_Qualidade ARTEFATOS KLEYNA Modelos_Checklist_v1 5 xls ESTUDO Caso CT_Qualidade ARTEFATOS KLEYNA EXEMPLOS 5 Checklist Necessidades Cliente v1 5 xis Listas de Verifica o VENC001 03 VEAR001 03 VEPT001 03 VETUOO 1 03 VETI001 03 VETG001 03 VETV001 03 VECJ001 03 T cnica utilizada Checklists baseados em aspectos Orienta es T cnicas Na pr pria lista de confer ncia Opcionalidade Obrigat ria ntrada para Atividade Verifica o a da da Atividade Planejamento FIG 4 2 2 1 1 a PGQSP do projeto Controlador T tico 93 Cronograma Esfor o homens hora C digo da Atividad Taref Data de Data de Verifica o venta argia In cio T rmino Gas Verificador Prepara o do Eales das VENC001 03 ai Necessidades 09 12 2003 09 12 2003 0h 1h p do Cliente FIG 4 2 2 1 1 b Cronograma de verifica o do artefato Necessi
24. o Corformidades 2 Aspecto Padroniza o Este aspecto deve verificar as quest es de adequa o ao padr o estabelecido na especifica o da apresenta o 21 Sevarias janelas s o exibidas o nome da janela corretamente apresentado s 2 2 As cores e ou som dentro da janela ou quando uma seq ncia de opera es com janelas for apresentada esta de acordo com a especifica o s Total de itens do aspecto verificados Total de n o conformidades 3 Aspecto Confiabilidade Este aspecto deve verificar o n vel de desempenho mediante a ocorr nda de restri es do software ou de defeitos na especifica o de requisitos projeto e implementa o P 3 1 A janela que sofreu atualiza o reescrita e apresentada com os novos dados s 3 2 Se sele es indevidas como mouse forem realizadas dentro da janela estas causam efeitos colaterais inesperados n 3 3 Os dados inv lidos s o corretamente identificados s Total de itens do aspecto verificados Total de n o conformidades 4 Aspecto Usabilidade Este aspecto deve verificar a legibilidade atratividade e facilidade operativa e de aprendizado do software pelo usu rio 41 Ajanela pode ter tamanho reajustado ser movida ou rolar 4 2 Cada item de menu est dispon vel no Ajuda help on line Para cada item do menu est implementado o contexto sensitivo Para cada fun o do menu existe um comando altemativo Os nomes das fun es de menu s o clarose auto explicati
25. o de como o reuso deve ser implantado na organiza o 85 os aspectos de reusabilidade e compatibilidade devem ser estabelecidos com seus objetivos definidos e conjunto de perguntas Estas perguntas que o verificador deve responder devem atender aos objetivos do aspecto referente Para estas listas de confer ncia devem ser reutilizados modelos aplic veis se existirem PAA A1 4 Determinar os recursos respons veis e cronogramas para as verifica es dos seguintes assets Dom nio Arquitetura de Dom nio Componente de Dom nio e Componentes Todos os asset exceto Componentes s o produzidos no Processo de Engenharia de Dom nio e o asset de Componentes gerado no Processo de Desenvolvimento conforme apresentado na TAB 3 2 2 1 As verifica es dos assets s o para assegurar padroniza o da documenta o qualidade reusabilidade compatibilidade completude rastreabilidade corretude e facilidade no entendimento dos mesmos Todas as n o conformidades detectadas devem ser corrigidas pelo respons vel pela elabora o do artefato verificado que comp e o asset e suas corre es verificadas pelo verificador respons vel Durante a atividade Verifica o os problemas detectados que fogem ao escopo do respons vel pela elabora o do artefato devem ser listados no Relat rio de Verifica o assim como as a es decorrentes Os resultados da verifica o devem ser disponibilizados para o Gerente de Reuso e aos rg os envolv
26. o de problemas com rela o aos requisitos de qualidade estabelecidos ao longo de todo o desenvolvimento do software ou seja na especifica o das necessidades e requisitos modelagem conceitual arquitetura de dom nio projeto l gico implementa o testes e implanta o Desta forma este processo deve avaliar os artefatos produzidos tanto nos n veis de gerenciamento do projeto como nos n veis t cnicos durante a vig ncia do Contrato do Projeto ABNT12207 1998 3 2 1 1 N VEL DE GERENCIAMENTO O Processo de Controle de Qualidade PCQ ao N vel de Gerenciamento consiste em exercer avalia es gerenciais No ltimo dia til do m s o Gerente do Projeto deve realizar estas avalia es verificando o andamento e situa o do projeto conforme cronograma estabelecido no Plano de Ger ncia do Projeto e o gerenciamento dos recursos e treinamentos necess rios para a equipe de desenvolvimento montadores do Projeto de Software Os dados destas avalia es devem ser informados formalmente ao Subprocesso 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 3 2 1 1 1 De posse deste relat rio e do cronograma atualizado o Grupo de M tricas deve alimentar sua base de dados gerencias sobre projetos para obten o de indicadores de produtividade do processo de desenvolvimento do software Na FIG 3 2 1 1 1 s o apresentas as intera
27. opera o engenharia e apoio Cada uma destas vis es representa a forma como uma organiza o emprega estes processos agrupando os de acordo com suas necessidades e objetivos As vis es t m o objetivo de organizar melhor a estrutura de uma empresa para definir suas ger ncias e atividades alocadas s suas equipes 7 3 3 PROCESSOS VOLTADOS A REUSO DE ASSETS PELA IEEE 1517 A norma IEEE 1517 1999 consiste em Estabelecer um framework comum para processos de reuso e como integrar a pr tica de reuso nos processos de ciclo de vida do software Integrar processos de reuso atividades e tarefas com os processos de ciclo de vida do software descritos em ISO IEC Std 12207 0 1996 ABNT12207 1998 Definir os processos atividades e tarefas que s o necess rios para executar e administrar a pr tica de reuso em um nico projeto de software por v rios projetos de software e por uma organiza o Facilitar a comunica o entre adquirentes de software fornecedores desenvolvedor gerentes de programa de reuso gerentes de asset e engenheiros de dom nio ao prover um entendimento comum de reuso e por unificar terminologia de reuso O framework de processo de reuso da IEEE 1517 TEEE1517 1999 cobre ambos o ciclo de vida de um produto de software desenvolvido de assets e o ciclo de vida de um asset Os processos de reuso abordam como os produtos de software s o constru dos com assets e como identificar construir manter e gerenci
28. s Total de itens do aspecto verificados Total de n o conformidades Restrito Instituto Militar de Engenharia Pagina 1 2 142 Garantia da Qualdade de Software Checklist C digo Fonte em Java Vers o 1 5 VECF001 03 Data da vers o 01 03 2004 Checklist C digo Fonte em JAVA Artefato Verificado pacote CTCF001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 1 Aspecto Defeito de Declara o de Constantes Vari vel e Atributo Este aspecto deve verificar defeitos em declara es de constantes vari veis e atributos 1 1 Os nomes das vari veis e constantes est o de acordo com a conven o de nomes Todas as vari veis e atributos est o com nomes distintos Todas as vari veis e atributos est o digitados corretamente Todas vari veis e atributos est o inicializados corretamente se foro caso Todas as vari veis locais est o declaradas dentro do seu escopo ou seja n o existe vari veis n o locais que podem ser locais Todas a
29. 1 1998 p 37 64 MYERS G The art of software testing and Edition Nova York John Wiley amp Sons 1979 192 p NIST NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Glossary of software reuse terms Special Publication 500 222 1994 OGUSH M Terms in transition a software reuse lexicon Crosstalk v 39 1992 p 41 45 PAIVA D M B NUNES M G V FORTES R P M Qualidade de produto de software avalia o pr tica de um sistema de auditoria hiperm dia educacional VII Workshop de Qualidade de Software Out 2001 p 114 122 PAGLIUSO P B B TAMBASCIA C A VILLAS BOAS A Melhoria da inspe o de requisitos segundo a t cnica de leitura baseada em perspectiva XI SEMINCO Semin rio de Computa o 2002 Santa Catarina Blumenau Setembro de 2002 p 105 115 http www inf furb br seminco 2002 artigos Pagliuso seminco2002 27 pdf capturado em julho 2003 PALADINI E P Qualidade total na pr tica implanta o e avalia o de sistemas de qualidade total 2 Edi o S o Paulo Atlas 1994 PALMER Traceability software requirements engineering R H Thayer and M Dorfman 1997 p 364 174 PARK R E Software size measurement a framework for counting source statements Technical Report CMU SEI 92 TR 20 ESC TR 92 20 Software Engineering Institute Carnegie Mellon University Pittsburgh Sep 1992 242 p Dispon vel http www sei cmu edu pub documents 92 reports pdf tr20 92 pdf capturado em ju
30. 2002 TAB 2 1 3 1 1 Seis atributos de qualidade de projetos OO Atributos de Qualidade Descri o 1 Compreensibilidade Evidencia a presen a de caracter sticas que revelam a facilidade em aprender e compreender 2 Efetividade Evidencia a presen a de caracter sticas para alcan ar a funcionalidade e o comportamento desejados usando conceitos e t cnicas de OO 3 Extensibilidade Evidencia a presen a e o uso de caracter sticas que permitem a introdu o de novos requisitos no projeto 4 Flexibilidade Evidencia a presen a de caracter sticas que permitem a um projeto de ser adaptado para fornecer funcionalmente uma capacidade espec fica 5 Funcionalidade Evidencia a presen a de caracter sticas de responsabilidades atribu das s classes de um projeto que est o dispon veis atrav s de suas interfaces p blicas 6 Reusabilidade Evidencia a presen a de caracter sticas de projetos OO que permitem ao projeto ser reaplicado para um novo problema sem esfor o significativo 42 As propriedades de projeto tais como abstra o encapsulamento acoplamento coes o complexidade e tamanho de projeto s o frequentemente usadas como caracter sticas de qualidade de projeto tanto para desenvolvimento estrutural como OO As mensagens composi o heran a polimorfismo e hierarquias de classe s o conceitos do paradigma OO fundamentais para a qualidade de um projeto OO Este modelo
31. 6 5 Conformidade Evidencia o quanto o software est de acordo com as normas ou conven es relacionadas portabilidade da aplica o caracter sticas e as A norma ISO IEC 9126 1S09126 2000 enumera as subcaracter sticas de um produto de software mas n o define como pontuar um software em cada um dos itens Algumas caracter sticas podem ser realmente medidas tempo de execu o de um programa n mero de linhas de c digo n mero de erros encontrados em uma sess o de teste ou o tempo m dio entre falhas Para estas caracter sticas poss vel utilizar uma ferramenta ou software para realizar as medi es Mas existem caracter sticas altamente subjetivas necessitando formular um conjunto de perguntas do tipo sim ou n o onde as respostas sim indicam melhor pontua o para as caracter sticas Depois de avaliar o software respondendo a cada pergunta deve verificar o percentual de sim em rela o quantidade de perguntas Pode se melhorar atribuindo um n mero m nimo de perguntas para cada caracter stica e para as perguntas mais importantes podem ter pesos maiores e ainda para cada pergunta pode ter cinco op es de resposta indicando um escore diferenciado Existem outras formas diferentes de medir uma caracter stica baseada em conceitos do tipo n o se aplica n o satisfaz satisfaz parcialmente satisfaz totalmente e excede os padr es 134 7 3 2 CI
32. Arquitetura de Dom nio e marque o com asterisco verde A especifica o do componente deve estar representada por uma classe com estere tipo comp esp com nota o lollipop para interface do componente O nome da interface do componente deve ser o mesmo nome da classe de interface de sistema da especifica o das Interfaces da Camada de Aplica o O nome da classe comp esp do componente deve iniciar por letra em mai scula e ter o mesmo nome da classe de interface sem a vogal mai scula inicial I 1 Caso n o consiga encontrar o componente correspondente preencha a Tabela de Discrep ncia pois h informa o em um diagrama que n o est presente em outro ou h inconsist ncia entre os dois 2 Caso consiga encontrar o componente corresponde verifique se o componente est especificado na Camada de Aplica o da Arquitetura de Dom nio Caso n o esteja na Camada de Aplica o preencha a Tabela de Discrep ncia pois h inconsist ncia entre os dois diagrama Encontre no Diagrama de Intera es de Componente o diagrama correspondente ao componente identificado no passo anterior 1 O nome do componente deve ser similar ou sin nimo do nome da intera o correspondente 1 Caso n o consiga encontrar o diagrama de intera o correspondente preencha a Tabela de Discrep ncia pois h informa o em um diagrama que n o est presente em outro ou h inconsist ncia entre os dois 2 Caso consiga encontra
33. Classes S MBOLOS gt S mbolo matem tico de somat rio 13 LISTA DE SIGLAS ABNT Associa o Brasileira de Normas T cnicas ACM Association for Computing Machinery APF An lise por Pontos de Fun o CGQS Consultor de GQS CMM Capability Maturity Model CMMI Capability Maturity Model Integration COCOMO Constructive Cost 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 Question Metric ICP Indicador de Compreensibilidade do Projeto IEC International Electro Technical Commission IEEE Institute of Electrical and Eletronics Engineers IEfP Indicador de Efetividade do Projeto IESP Indicador de Extensibilidade do Projeto IFPUG International Funcion Point Users Group IFuP Indicador de Funcionalidade do Projeto IFxP Indicador de Flexibilidade do Projeto IME Instituto Militar de Engenharia IPPVR Indicador de Produtividade do Processo de Verifica o e Revis o IPqM Instituto de Pesquisa da Marinha IQPOOR Indicadores de Qualidade do Projeto OO Baseado em Re so IQPVR Indicador de Qualidade do Processo de Verifica o e Revis o IRP Reusabilidade do Projeto ISO International Organization for Standardization KPA Key Process Areas LOC Lines Of Code linhas de c digo MD Minist rio da Defesa NIST
34. T tico Por outro lado como o Consultor de Qualidade j tem alguma experi ncia mesmo que academicamente com este tipo de reuni o descrita na se o 3 2 1 2 2 foi um fator positivo na integra o e condu o das reuni es exercendo o papel de l der moderador Avalia o dos Resultados e do Tempo Foi observado inicialmente v rias d vidas e inseguran a por parte dos revisores individuais na realiza o da T cnica de Leitura As d vidas eram relativas ao dom nio da aplica o e a inseguran a devido utiliza o de um procedimento novo Isto resultou na necessidade de um treinamento mais espec fico ou seja realiza o em grupo grupo de revisores de uma experi ncia pr tica com um artefato e tamb m uma explica o mais detalhada sobre o dom nio do problema Controlador T tico Na FIG 4 2 3 2 1 apresentada a Tabela de Discrep ncia para T cnica de Leitura Vertical em a e em b a T cnica de Leitura Horizontal assim como o Detalhamento de Discrepancia para T cnica de Leitura em c e em d o QSMGQ Question rio de Sugest es para Melhoria da Garantia da Qualidade preenchido pelo revisor de TLH1 ap s a realiza o da inspe o individual para TLV1 e TLH1 respectivamente 100 Tabela de Discrep ncia para Leitura Vertical Projeto c7001 03 Tipo Leitura Vertical TLV TLV1 Data da revis o 10 3 2003 In cio da revis o 9 hr Nome e tipo dos documentos inspecionados Doct CU010 03 Dia
35. Vers es e Question rio de Sugest es para Melhoria da Garantia da Qualidade QSMGQ Os modelos foram realizados da seguinte forma T cnica Utilizada Consulta a consultores de qualidade de organiza es que j t m introdu o da pr tica de qualidade nos processos de desenvolvimento de projetos e pesquisa na literatura sobre modelos de qualidade Tempo Despendido Duas semanas Fatores de Influ ncia Houve um ponto favor vel facilidade de acesso a consultores de qualidade de duas grandes organiza es como SERPRO RJ e SIEMENS RIJ Avalia o dos Resultados e do Tempo Foram realizadas no total de tr s entrevistas com os consultores de qualidade e algumas consultas por telefone As entrevistas duraram em m dia 2 horas cada Nas entrevistas foram levantados v rios tipos de artefatos de qualidade apontados pela Norma IS09000 2000 ABNT9000 2001 mas nenhum dos consultores relatou sobre algum procedimento de avalia o dos produtos de qualidade Nesta etapa da Monitora o s foram definidos os modelos que nas etapas seguintes foram devidamente preenchidos Para o Plano de Garantia de Qualidade de Software do Projeto PGQSP foi utilizado um modelo que est apresentado na FIG 4 2 1 1 90 PGQSP Plano de Garantia da Qualidade de Software do Projeto Definir a estrutura de GQS adotada para o projeto a forma de atua o das verifica es revis es o cronograma das verifica es revis es para as
36. a ordem os tipos e os valores de par metros de todas as chamadas dos m todos est o de acordo com as suas declara es de chamdas dos m todos 11 2 Os valores est o na mesma unidade por exemplo jardas 11 3 Se um objeto ou array passado como par metro alterado a altera o est correta para o m todo chamador s Total de itens do aspecto verificados Total de n o conformidades 12 Aspecto Defeito de Coment rio Este aspecto deve verificar os defeitos de coment rio cC I 12 1 Todo m todo dasse e arquivo t m um coment rio de cabe alho adequado 12 2 Toda dedara o de constante atributo e vari vel t m um coment rio 12 3 O comportamento de cada m todo e classe est comentado em uma linguagem clara e objetiva 12 4 O coment rio de cabe alho para cada m todo e classe est consistente com o comportamento do m todo ou classe 12 5 Os coment rios est o de acordo como c digo 12 6 Os coment rios ajudam no entendimento do c digo 12 7 Existem suficientes coment rios no c digo 12 8 Os coment rios atendem as diretivas do aplicativo de documenta o utilizado s Total de itens do aspecto verificados Total de n o conformida des 13 Aspecto Defeito de Performance Este aspecto deve verificar os defeitos de desempenho CI 13 1 A organiza o dos testes l gicos est de forma que os testes mais baratos e frequentemente bem sucedidos precedem aos mais carose menos sucedidos 13 2 Todo resultado que calcu
37. al 1997 FICHMAN 2001 avaliou nos modelos de desenvolvimento de artefatos projetados para reuso como um dos mais promissores A vantagem deste que os desenvolvedores produzem artefatos reutiliz veis quando esses artefatos ainda est o recentes em suas mentes e apenas uma nica biblioteca de artefatos de alta qualidade precisa ser mantida e procurada Entretanto um esfor o despendido sem saber quando ou se o artefato ser efetivamente reusado A vantagem do artefato transformado para reuso ser um modelo just in time para a produ o de componentes que resulta na necessidade de pelo menos de duas bibliotecas prim ria contendo s artefato aprovado para ser reutiliz vel e secund ria para artefato n o candidato ao reuso ou ao que ainda n o foi transformado A desvantagem deste ltimo est no esfor o extra para fazer artefatos reutiliz veis a partir de artefatos candidatos que o desenvolvedor n o esteja familiarizado e na busca em mais de uma biblioteca por artefatos reus veis ou artefatos candidatos a serem transformados para reuso Tamb m n o h nenhuma garantia que um desenvolvedor execute a busca do artefato ao inv s de desenvolver novamente 47 O reuso sistem tico de software requer a inclus o de elementos fundamentais de controle de qualidade no processo de desenvolvimento de asset tais como Valida o e verifica o dos assets ou seja estes devem ser submetidos a um processo para assegurar
38. ao projeto FENTON 1991 Zz Reuso privado ou interno a reutiliza o de itens do produto dentro do pr prio produto Reuso p blico ou externo a por o de um produto que foi constru do externamente Modifica o refere se quantifica o de modifica o do asset que pode ser caixa branca caixa preta verbatim ou adaptativo 2 Reuso de caixa preta o reuso de componentes de software sem qualquer modifica o PRIETO DIAZ et al 1993 BIEMAN et al 1993 o reuso as is Reuso de caixa branca o reuso de componentes com modifica o ou adapta o PRIETO DIAZ et al 1993 Reuso adaptativo uma estrat gia de reuso que usa grandes estruturas de software como variabilidade invari vel e restritiva para locais isolados e de baixo n vel BARNES et al 1991 Abordagem refere se ao m todo para implementa o de reuso que pode ser por gerador composi o estreito amplo indireto direto transporte e influenciado Reuso gerador reuso no n vel de especifica o com aplica o ou geradores de c digo o reuso que oferece o mais alto investimento PRIETO DIAZ et al 1993 Reuso de composi o o reuso de componentes existentes como blocos de constru o para novos sistemas PRIETO DIAZ et al 1993 Um exemplo a programa o de linguagem alto n vel BARNES et al 1991 Reuso estreito de componentes que s o dependentes no ambiente da aplica o para tod
39. artefato a ser verificado n o foi produzido e as devidas a es decorrentes para resolver o problema Gerente de Re so justificou e autorizou por escrito a dispensa da elabora o do artefato que se encontra em anexo Problemas A es Decorrentes O Question rio de Sugest es para Melhoria da Garantia da Qualidade deve ser preenchido e entregue junto a este Relat rio Sua CONTRIBUI O fundamental para o cont nuo progresso da melhoria da NOSSA QUALIDADE Data Assinatura do Verificador f FIG 4 2 2 1 1 e Relat rio de Verifica o para Necessidades do Cliente e Gloss rio 4 2 2 2 VERIFICA O A Verifica o foi realizada da seguinte forma T cnica Utilizada As listas de confer ncias checklists elaboradas no Planejamento da Verifica o baseadas em aspectos para os artefatos Necessidades do Cliente e Gloss rio Arquitetura de Dom nio C digo fonte e Casos de Testes de Qualifica o e os relat rios correspondentes conforme descrito na se o 3 2 1 2 1 Tempo Despendido Em m dia uma hora para cada artefato no decorrer de duas semanas Fatores de Influ ncia A execu o da aplica o dos checklists foi facilitada pela disponibilidade de um grupo acad mico de p s gradua o em Ci ncia da Computa o 95 Avalia o dos Resultados e do Tempo Apesar da falta de conhecimento por parte dos verificadores do dom nio do projeto piloto Controlador T tico estes n o tiveram dific
40. assets na biblioteca incluem tempo de uso reusos bem sucedidos revis es de reuso complexidade inspe es e testes Uso de biblioteca de reuso Lillie Frakes e Terry FRAKESb et al 1996 Indicadores de utiliza o de biblioteca incluem tempo on line sistema dispon vel considera es demogr ficas tipo de desempenho da fun o da biblioteca busca browse extra o distribui o de asset quantidade de subscritor assets disponibilizados por tipo opera o fornecedor de listas componentes locais n mero de extra o por cole o n mero de assets extra dos por cole o n mero de assets extra dos por avalia o de n vel lista de assets por dom nio solicita o de servi os atrav s de Telnet Logins modem Logins FTP World Wide Web 7 3 AP NDICE 3 PRINCIPAIS NORMAS Os padr es de processos mais utilizados atualmente pelas industrias e organiza es s o CMM CMMI ISO 9000 ISO 12207 ISO 15504 Extreme programming Estes padr es delineiam e justificam a organiza o os pap is dos interessados stakeholders as principais atividades e tarefas os tipos e pontos de controle da qualidade Normalmente n o especificam como deve ser realizado Os processos devem ser utilizados em uma grande gama de projetos Assim eles devem ser instanciados para determinado dom nio de tecnologia Estas inst ncias s o restritas a projetos que estejam em conformidade com estes dom
41. aumento na produtividade fundamental que a qualidade do processo de desenvolvimento destes artefatos e os pr prios artefatos tenham qualidade assegurada JACOBSON 1997 Desta forma necess rio um controle de qualidade para incluir preven o e remo o de defeitos dos artefatos JONES 1994 Neste trabalho foi adotado como defini o de qualidade de software um conjunto de propriedades de software a serem satisfeitas em determinado grau de modo a satisfazer as necessidades e expectativas mensur veis de todos seus usu rios internos e externos ROCHA et al 2001 ABNT9000 2001 Assim a partir deste conjunto de propriedades a qualidade do produto de software pode ser descrita e avaliada de forma objetiva e padronizada Os princ pios a serem adotados na implanta o do processo proposto foram Cria o da rea de qualidade para melhoria continua da qualidade medi o e an lise de processo e artefatos de forma a aumentar efetivamente a produtividade e a satisfa o dos usu rios externos e internos KAN 1995 SEI 2002 Assim os resultados de cada fase do processo de desenvolvimento de software devem ser avaliados para assegurar a qualidade dos artefatos e garantir um software de boa qualidade Pois em cada fase do processo um artefato produzido para um usu rio da fase seguinte Portanto cada artefato possui atributos da qualidade que afetam a qualidade do produto final HAZAN 1999 O controle da qualidade deve
42. consumidor DEMING 1990 Nesta defini o a qualidade est ligada satisfa o do usu rio interno ou externo abrangendo suas necessidades e expectativas mensur veis que devem ser medidas atrav s das caracter sticas da qualidade dos produtos ou servi os finais ou intermedi rios da organiza o Estas caracter sticas compreendem aus ncia de defeitos e presen a de atributos que agregam valor ao produto ou servi o de forma confi vel acess vel segura e no tempo certo s necessidades do cliente Essas caracter sticas s o previsibilidade e confiabilidade de todas as opera es treinamento cont nuo objetividade e clareza da informa o ger ncia por processo e n o por resultados de forma a ter uma ger ncia preventiva de problemas n o permitindo que o mesmo problema se repita pela mesma causa Qualidade a adequa o ao uso JURAN 1990 Diferentes usu rios podem usar os mesmos produtos de diversas formas ou seja os produtos devem ter v rios atributos de qualidade tais como capacidade usabilidade desempenho confiabilidade instabilidade manutenibilidade documenta o e disponibilidade Qualidade a conformidade com os requisitos dos clientes CROSBY 1996 Os requisitos devem ser claramente especificados para que durante o processo de desenvolvimento do produto as medi es possam ser realizadas para determinar a conformidade aos requisitos especificados A n o conformidade detectada a aus nci
43. correspondente no Modelo Tipo do Neg cio quando encontrar 1 Caso n o consiga encontrar certifique no Modelo de Casos de Uso do Dom nio que o relacionamento pode ser proveniente de uma classe do Modelo Conceitual do Dom nio que representa o conceito de uma intera o de ator sistema com o dom nio do neg cio Caso contr rio preencha a Tabela de Discrep ncia pois um relacionamento n o est presente no Modelo Tipo do Neg cio 2 Certifique que a cardinalidade esteja representada no relacionamento no Modelo Tipo do Neg cio de acordo com a representa o correspondente no Modelo Conceitual do Dom nio B Se o Modelo Conceitual de Dom nio especifica algum mecanismo de heran a para esta classe verifique se eles est o corretamente representados no Modelo Tipo do Neg cio 1 Caso n o consiga encontrar certifique no Modelo de Casos de Uso do Dom nio que a classe pode ser proveniente de uma classe do Modelo Conceitual do Dom nio que representa o conceito de uma intera o de ator sistema com o dom nio do neg cio Caso contr rio preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsistente entre os dois II Analise a Descri o dos Cen rios dos Casos de Uso do Dom nio para verificar se os atributos das classes do Modelo Tipo do Neg cio foram capturadas adequadamente ENTRADAS Descri o dos Cen rios dos Casos de Uso do Dom nio Modelo Tipo do Neg
44. da disserta o de GURGEL 2004 e mudan as constantes dos artefatos a serem produzidos Entretanto paralelamente foi estabelecendo a t cnica de qualidade apropriada ao projeto piloto Controlador T tico desenvolvido sob o paradigma OO grande facilitador ao reuso 4 1 2 HIP TESE DO ESTUDO DE CASO A hip tese do estudo de caso para esta disserta o foi avaliar at que ponto o processo de Garantia da Qualidade de Software se mostrou adequado ao processo de desenvolvimento baseado em reuso de assets de GURGEL 2004 no dom nio de controle t tico de plataformas de forma a garantir a qualidade dos artefatos produzidos e prover uma refer ncia para a reusabilidade A avalia o deste processo deve ser verificada atrav s de sua implanta o ao projeto piloto para obter dados de refer ncia para futuros projetos desenvolvidos sob o processo de GURGEL 2004 Estes dados devem servir de base para comparar a qualidade e reusabilidade dos pr ximos projetos Desta forma os artefatos de qualidade definidos para o projeto piloto devem ser analisados para se verificar a valida o da hip tese 88 4 1 3 CONDU O DO ESTUDO DE CASO O projeto piloto seguiu o processo de Garantia de Qualidade de Software proposto no cap tulo anterior tendo como subs dio os artefatos reus veis definidos para o Estudo de Caso de GURGEL 2004 Cada subprocesso foi conduzido conforme a etapa Monitora o de KITCHENHAM et al 1995 apresentad
45. da verifica o revis o n o deve ultrapassar a quinze minutos Na entrega do Projeto de Software ao Cliente o Manual da Qualidade do Projeto deve conter todos os artefatos produzidos para avalia o e os resultados obtidos os problemas e a resolu o destes problemas que surgiram durante todo o ciclo de vida de desenvolvimento do Projeto inclusive o Plano e Cronograma de Garantia da Qualidade importante ressaltar que todos os artefatos do Processo de Garantia da Qualidade de Software devem estar dispon veis a toda equipe de desenvolvimento montadores a qualquer momento para que assim estes artefatos possam contribuir como suporte na elabora o dos produtos de software das atividades dos processos de Engenharia de Dom nio e Desenvolvimento de GURGEL 2004 Al m disso os registros das atividades e das tarefas de Garantia da Qualidade dos problemas detectados e da avalia o dos problemas devem ser mantidos e disponibilizados a todos interessados stakeholders 59 Nas se es seguintes atrav s da t cnica de modelagem SADT Structure Analysis and Design Technique desenvolvida por Douglas T Ross ROSS 1984 e SOFTech s o definidos por meio dos actigramas o Processo de Controle de Qualidade PCQ ao N vel T cnico e seus respectivos subprocessos veja FIG 3 1 e o Processo de Aprova o de Assets PAA 3 2 1 PROCESSO DE CONTROLE DE QUALIDADE PCQ O Processo de Controle de Qualidade consiste na identifica
46. de Agrega o esta medida mede a extens o do relacionamento do tipo parte do todo realizado pelo uso dos atributos 6 Encapsulamento refere se s classes que previnem quanto o acesso s declara es de atributos protegendo as representa es internas dos objetos M trica de Acesso aos Dados esta m trica a taxa do n mero de atributos privado protegido pelo n mero total de atributos declarados na classe 7 Heran a uma medida de relacionamento uma entre as classes Este relacionamento relativo ao n vel das classes quanto a uma hierarquia de heran as Medida de Abstra o Funcional esta media consiste na taxa do n mero de m todos herdados por uma classe pelo n mero total dos m todos acess veis por m todos de membro da classe 8 Hierarquia hierarquia usada para representar diferentes conceitos de especializa es generaliza es em um projeto N mero de Hierarquia esta m trica consiste em contabilizar o n mero de classes m e no projeto 9 Mensagem uma quantia do n mero de m todos p blicos que est o dispon veis como servi os para outras classes Tamanho da Interface da Classe esta m trica consiste em contabilizar o n mero de m todos p blicos das classes 10 Polimorfismo a capacidade para substituir objetos cujas interfaces conciliam com outras em tempo de execu o N mero de M todo Polimorfos esta m trica consiste em conta
47. de Discrep ncia falta ou est incompleta fluxo de dados no modelo de contexto ou sua descri o 4 Para cada fluxo de dado identificado verificar se o nome est no padr o todo em min sculo e o mesmo utilizado pela entidade externa Caso contr rio preencha a Tabela de Discrep ncia nome do fluxo de dados n o est adequado B Verifique se todas as necessidades est o sendo encapsuladas dentro do escopo do dom nio 1 Certifique que o mesmo conjunto de necessidades esteja presente na descri o do contexto do dom nio Caso contr rio preencha a Tabela de Discrep ncia pois informa o est presente em um documento mas ausente no outro II Reveja o Modelo Conceitual do Dominio para assegurar que todas as entidades externas e seus relacionamentos est o sendo levados em considera o ENTRADAS Entidades externas marcadas com asterisco azul Relacionamentos real ados em amarelo SA DAS Relat rio de Discrep ncias A Reveja as entidades externas e seus relacionamentos para ter certeza que todo o conjunto de entidades e seus relacionamentos aparecem descritos no documento de Necessidades do Cliente e Gloss rio 1 Certifique que n o exista nenhuma entidade externa sem asterisco e relacionamento sem estar real ado em amarelo Caso exista algum preencha a Tabela de Discrep ncia pois uma entidade externa ou relacionamento no Modelo de Contexto do Dom nio n o est presente no documento Necessidades do Cliente e Gloss
48. de armazenamento t cnicas de an lise e mecanismos de comunica o e de feedback Implementa o da coleta armazenamento an lise e comunica o dos dados Fornecimento de resultados objetivos que podem ser usados na tomada de decis o e implementa o de a es corretivas adequadas Neste trabalho um processo de Controle da Qualidade PCQ especificado ao estabelecer os subprocessos de Verifica o SPV Revis o SPR e Medi o e Avalia o SPM Para garantir que os assets definidos em GURGEL 2004 possam ser classificados e gerenciados para reuso o processo proposto deve validar os artefatos que comp em os assets Para isto um processo de Aprova o de Asset PAA definido e este deve estar em sintonia com o processo de Controle da Qualidade IEEE1517 1999 Com o objetivo de desenvolver com e para reuso de assets e de produzir assets de qualidade a ger ncia de reuso deve implantar e utilizar os processos abordados neste cap tulo fundamental que todas as pessoas dos rg os envolvidos com o desenvolvimento de software tenham incorporado as pr ticas deste processo em suas rotinas 54 3 1 ESTRUTURA ORGANIZACIONAL DO GRUPO DE GARANTIA DA QUALIDADE DE SOFTWARE Como o Minist rio da Defesa uma institui o centralizadora e hier rquica que possui Comandos Subordinados e estes comandos por sua vez cont m v rios rg os de desenvolvimentos com diferentes reas de atua o este trabalho
49. de artefatos a ser inspecionado e a dura o desta atividade n o deve ultrapassar a duas horas A segii ncia de tarefas da atividade Prepara o para Revis o T cnica consiste em SPR A3 1 Os revisores devem aprender sobre os artefatos a serem examinados e prepararem se para desempenhar as leituras individualmente verificando para o tipo de leitura os recursos necess rios para execu o do procedimento da leitura SPR A3 2 Uma vez que todos os revisores est o preparados o grupo revisor procura n o conformidades utilizando a T cnica de Leitura Vertical TLV e Horizontal TLH adequada ao artefato em revis o Em cada leitura o revisor deve procurar evid ncias de que o 74 artefato esteja completo aderente aos padr es e especifica es relacionados como tamb m o artefato esteja implementado adequadamente A inspe o de cada artefato n o deve ultrapassar mais de uma hora SPR A3 3 Cada revisor documenta os resultados da revis o no Relat rio de N o Conformidades da Revis o SPR A4 REVIS O T CNICA A atividade Revis o T cnica consiste na realiza o da reuni o da revis o do conjunto de artefatos inspecionados individualmente na atividade Prepara o para Revis o T cnica SPR A3 Esta atividade deve ser realizada pelos integrantes estabelecidos na atividade Planejamento SPR A1 ou seja um lider um grupo de revisores um grupo de autores do conjunto de artefatos inspecionados um secret rio e um
50. definir os integrantes que v o participar das atividades seguintes ao Planejamento SPR A1 ou seja deve estabelecer os seguintes pap is WIEGERS 1995 para cada conjunto de artefatos a ser revisado Grupo autor grupo formado por autores dos artefatos a serem examinados 70 Grupo revisor grupo formado por pessoas do rg o Descentralizado de Fornecimento de Software contratado e opcionalmente pelo s cliente s ou representante s legal is que tenham conhecimento e qualifica o inerentes ao artefato mas que n o atuaram na elabora o do artefato Um secret rio um membro do grupo autor do artefato que deve realizar a ata da reuni o Um lider um consultor de qualidade alocado ao projeto Um expositor um membro do grupo revisor que exp e o problema A atividade de Treinamento SPR A2 inicia ao receber um conjunto de artefatos que foi produzido para uma determinada vers o conforme cronograma do projeto definido no Plano de Ger ncia do Projeto Na TAB 3 2 1 2 2 1 especificado cada conjunto de artefatos que deve ser enviado ao expositor e quando do envio pelo Gerente do Projeto TAB 3 2 1 2 2 1 Conjunto de artefatos para revis o Conjunto de Artefatos Quando Modelo de Contexto T rmino da atividade An lise do Dom nio do Modelo Conceitual Processo ao Longo do Projeto Modelo de Casos de Uso e Cen rios Modelo de Caracter sticas Modelo de Tipo de Neg cio Durante a atividade Projeto de Dom ni
51. do Ponto de Maior Aproxima o do Acompanham ento Calcular a posi o e a hora de maior aproxima o do acompanhamento plataforma prim ria baseado na posi o atual e anterior do mesmo 5 13 C lculo do Rumo para Passagem Segura Calcular o rumo para a plataforma prim ria passar a uma dist ncia pr determinada do acompanhamento definido mantendo sua velocidade caso seu PMA esteja inferior dist ncia de passagem segura 5 14 Alarme de Colis o Apresenta o n mero do acompanhamento e hora prevista do ponto de maior aproxima o caso este venha a passar a uma dist ncia inferior dist ncia de passagem segura definida previamente 171 5 15 Cancelamento de Acompanhamentos Um acompanhamento cancelado por infer ncia direta do operador ou caso se afaste para fora dos limites do Cen rio T tico definido 6 Caracter sticas desejadas 6 1 Usabilidade 6 1 1 Tempo de treinamento do usu rio padr o Quatro horas Uma pessoa com n vel secund rio de forma o deve estar capacitada a operar o sistema com quatro horas de treinamento 6 1 2 Tempo de treinamento do mantenedor do sistema Oito horas Uma pessoa com conhecimento b sico de computa o deve estar capacitada a detectar falhas e reiniciar o sistema com oito horas de treinamento 6 2 Confiabilidade 6 2 1 Disponibilidade O sistema deve poder permanecer em funcionamento 24 vinte e quatro horas por dia 6 2 2 Tempo entre falhas MTBF Mean Time Between failures N o deve apr
52. e os tipos de testes aplicados a cada etapa assissapesdprssousatogassgudorsrsendas ans soaareaesrnva 30 FIG 2 2 1 1 Procedimentos para re so de software sccsscsssscesscsennscsseessncesscesnnscnaceesecesaces 49 FIG 3 1 Escopo do Processo de Garantia da Qualidade de Software 52 FIG 3 2 1 Processo de Garantia da Qualidade do Software ccccccsccccessssceceessceeeessnaeeeeeees 58 FIG 3 2 1 1 1 Processo de Controle de Qualidade ao N vel de Gerenciamento 61 FIG 3 2 1 1 1 Processo de Controle de Qualidade ao N vel T cnico s 62 FIG 3 2 1 2 2 Amplia o do Processo de Garantia da Qualidade do Software 64 FIG 4 1 4 1 Cronograma do estudo de casos do prot tipo Controlador T tico 89 FIG 4 2 1 1 Plano de GOS do Projeto POQSPL secesataesniraiaas indo encara dentina soninidcantaadatcta 91 10 FIG 4 2 1 2 Hist rico de vers es errar errar aeee aeee errar nana aan erre nrada 91 FIG 4 2 1 3 Cronograma para as verifica es e revis es de GOS do projeto 91 FIG 4 2 1 4 Question rio de Sugest es para Melhoria da Garantia da Qualidade 92 FIG 4 2 2 1 1 a PGOSP do projeto Controlador T tico cceeemeeeeeeneorerereeresaeranaso 93 FIG 4 2 2 1 1 b Cronograma de verifica o do artefato Necessidades do Cliente e FIG 4 2 2 2 1 b Coment rios do
53. es padr es e documentos necess rios para realiza o do teste 2 3 Cada requisito especificado na fase de an lise de requisito est coberto pelo plano de teste de aceita o 2 4 Todos os casos de teste podem ser localizados pelo requisito especificado na fase de an lise de requisito Total de itens do aspecto verificados Total de nao conformidades 3 Aspecto Corretude e Completude Este aspecto deve analisar a corretude e completude dos testes cC I 3 1 O teste de cobertura suficiente para fornecer confiabilidade de que a fun o que testada opera corretamente dentro de seu ambiente planejado 3 2 O teste de integra o testa cada interface dos documentos de projeto correspondentes 3 3 A descri o da fun o de teste documentada no plano de teste est complete e precisa Todos os crit rios de entrada e sa da de teste s o suficientes e adequados ao ambiente planejado Todos os itens exclu dos do teste est o devidamente documentados O plano de teste est completo correto e sem ambiguidade Os n veis desejados de exig ncias e cobertura de c digo est o quantitativamente especificados s As condi es de entradas v lidas e inv lidas s o testadas s 3 9 Todos os crit rios de omiss o e falhas est o definidos s 3 10 O plano de teste esbo a os n veis de aceitabilidade para toler ncia a falhas s Total de itens do aspecto verificados Total de n o conformidades 4 Aspecto Teste de Regress o Es
54. es do Processo de Controle da Qualidade PCQ ao N vel de Gerenciamento com os processos de GURGEL 2004 apresentando os artefatos de entrada sa da com seus respectivos pap is e os respons veis pelo PCQ 60 Relat rio de Avalia o de Processo de Controle Acompanhamento de Projeto Plano de Ger ncia de Qualidade PCQ Grupo de GQS Corporativo Processo de do Projeto ao N vel de Gerente de Re so Fornecimento Gerenciamento Gerente do par Projeto Cronograma atualizado Relat rio Subprocesso de de Avalia o de Acompanhamento Medi p Avaliac de Projeto edi o e Avalia o Consultor de Qualidade do Grupo de M tricas Projeto Gerente de Projeto FIG 3 2 1 1 1 Processo de Controle de Qualidade ao N vel de Gerenciamento A atividade do Processo de Controle de Qualidade ao N vel de Gerenciamento a Avalia o de Gest o dos artefatos e recursos Esta atividade deve ser realizada em reuni o pelo Consultor de Qualidade do Projeto exercendo o papel de revisor e o Gerente de Projeto como autor A seq ncia de tarefas desta atividade consiste em l Avaliar a situa o do projeto em rela o ao Plano de Ger ncia de Projeto e Cronograma 2 Registrar as situa es de riscos e problemas detectados na tarefa anterior 3 Definir um esquema para categorizar e priorizar os problemas Cada problema deve ser classificado por categoria e prioridade para facilitar a an lise
55. est o em diferentes unidades de dados n 7 5 H possibilidade de ocorrer overflow ou underflow s o durante um c lculo n Total de itens do aspecto verificados Total de n o conformidades 8 Aspecto Defeito de Input Output Este aspecto deve verificar os defeitos de entrada e sa da de dados 8 1 Todos os arquivos s o abertos antes de serem usados 8 2 Os atributos de entrada do objeto s o consistentes com o arquivo em uso 8 3 Todos os arquivos s o fechados ap s serem usados 8 4 Todas as exce es de I O s o controladas 8 5 Existemerros gramaticais e de sintaxe em qualquer texto impresso Total de itens do aspecto verificados Total de n o conformidades 9 Aspecto Defeito de E mpa co tame nto Este aspecto deve verificar os defeitos de empacotamento e sua apresenta o 9 1 Aendenta o padr o e o formato do layout s o usados constantemente 9 2 Cada m todo tem aproximadamente menos do que 60 linhas 9 3 Cada pacote tem aproximadamente menos do que 600 linhas 9 4 Existe um baixo n vel de acoplamento entre os pacotes m todos e classes 9 5 Existe um alto n vel de coes o dentro de cada pacote m todos ou classe 9 6 As bibliotecas de Java s o usadas onde e quando adequadamente 9 7 Existe c digo repetitivo que pode ser substitu do por uma chamada a um m todo que prov o comportamento do c digo repetitivo Total de itens do aspecto verificados Total de n o conformidades 10 Aspecto Defeito de Armazenamen
56. focusing on a more productive reuse 17 1 INTRODU O 1 1 MOTIVA O A era da inform tica teve in cio na d cada de 60 com a difus o dos computadores nos diferentes setores da sociedade atrav s da utiliza o de software para os servi os e fun es O modelo de ciclo de vida de software surgiu para atender a necessidade do mercado no desenvolvimento de software de forma planejada controlada e dentro da estimativa de prazos estabelecidos Nos anos 80 a redu o progressiva do pre o do hardware incentivou a busca pelo menor custo do desenvolvimento de software Nesta poca os modelos para estimar custos e recursos come aram a surgir assim como a preocupa o pela qualidade e produtividade no desenvolvimento de software BASILI et al 1991 A necessidade de garantir a qualidade no processo de desenvolvimento do software resultou na utiliza o de processos criteriosos de avalia o de software para identificar seus pontos fortes e oportunidades de melhoria SEPIN 2002 A qualidade dos servi os e dos produtos de software est fortemente relacionada com a qualidade do processo de desenvolvimento do software CROSBY 1996 ABNT12207 1998 HAZAN 1999 ROCHA et al 2001 Assim o n mero de defeitos apresentados no software diretamente proporcional qualidade do processo usado para a constru o do software JACOBSON et al 1997 HENNINGER 1999 ROCHA et al 2001 Isto provocou uma grande preocupa o com a defin
57. n o s o capazes de identificar todos os defeitos do software fazendo com que as equipes de desenvolvimento n o prestem a devida aten o na qualidade dos artefatos intermedi rios produzidos PERRY 1999 As inspe es de software n o substitu ram os testes mas ajudaram a manter a qualidade nos artefatos principalmente os que compunham a estrutura do asset correspondente No trabalho aqui proposto foi apresentado um Processo de Medi o e Avalia o que constituiu um caminho para o controle de projetos de software atrav s de indicadores que podem ser utilizados posteriormente para promover a melhoria cont nua do Processo de Desenvolvimento de Software baseado em Reuso Al m disso este trabalho forneceu dados e informa es quantitativas para que o Gerente de Reuso possa decidir sobre que a es a serem tomadas As caracter sticas da qualidade apresentadas neste trabalho foram os atributos de qualidade de projeto OO Estes atributos foram relacionados aos requisitos da qualidade estabelecidos para o produto de software como a compreensibilidade efetividade 112 flexibilidade extensibilidade funcionalidade e reusabilidade Estas qualidades foram utilizadas como indicadores da qualidade do produto de software baseado em reuso Uma considera o importante observada durante a aplica o do processo proposto no estudo de caso foi que a assimila o de novas pr ticas dentro de uma abordagem totalmente diferente at ent o
58. ncias A Reveja no Modelo Tipo do Neg cio as classes seus atributos e relacionamentos para ter certeza que todo o diagrama de classe represente integralmente os Modelos Conceitual de Dom nio e Casos de Uso e Descri o dos Cen rios dos Casos de Uso do Dom nio 1 Certifique que n o exista nenhuma classe sem asterisco relacionamento sem estar real ado em amarelo e atributo sem estar sublinhado Caso exista algum preencha a Tabela de Discrep ncia pois uma classe ou relacionamento no Modelo Tipo do Neg cio n o est presente no Modelo Conceitual do Dom nio ou por um atributo no Modelo Tipo do Neg cio n o est presente na Descri o dos Cen rios dos Casos de Uso do Dom nio Restrito Instituto Militar de Engenharia P gina 2 2 165 Garantia da Qualidade de Software Leitura Vertical 4 Versao 1 2 RELV401 03 Data da vers o 03 03 2004 TLV 4 Modelo de Casos de Uso do Dom nio e Cen rios X Interface da Camada da Aplica o Objetivo Verificar se a especifica o da Interface da Camada da Aplica o projeta todas as interfaces necess rias do sistema com todos os tipos de interface seus atributos com os tipos b sicos e suas assinaturas de opera o inerentes modelagem do sistema representada pelo Modelo de Casos de Uso do Dom nio Pr requisito Esta leitura requer que o diagrama do Modelo de Casos de Uso do Dom nio e Descri o dos Cen rios dos Casos de Uso do dom nio tenham sido aprovado pelo Processo Cont
59. o de Com son K Stakeholders Equipede Desenv olvimento Montadores Gerente de Projeto Modelo de Contexto ModeloConceitualdoDominio C digo fonte Casos deTeste assets documenta Qualidade Plano de cia Interfaces daCamada de Projeto Modelo de Casos de Uso Modelo Tipo do Neg cio Interfaces daCamada de Neg cio e Tipos de Dados Arquiteturade Dom nio Relat rios de Testes PGQSP Cronogramade Modelo deCaracter sticas dos Com rg o Descentralizado de To oo o Fornecimento de Software Processo ao Longo do Projeto Engenharia de Dominios _ enharia de Dom nios Ha de Processo de Engenharia de Dominios Desenvolvimento Fornecimento FIG 3 2 1 2 2 Amplia o do Processo de Garantia da Qualidade do Software O Processo de Controle de Qualidade PCQ atrav s das verifica es do Subprocesso de Verifica o deve garantir que os artefatos Necessidades do Cliente e Gloss rio a Arquitetura do Dom nio os C digos Fonte e os Testes de Qualifica o do Desenvolvimento sejam aceit veis pelo cliente e adequados quanto aos padr es rastreabilidade corretude completude recursos e escalabilidade Al m disso atrav s do Subprocesso de Revis o o PCQ deve assegura que os artefatos e suas respectivas documenta es produzidos pela Engenharia de Dom nio estejam de acordo com o as necessidades e caracter sticas desejadas 64 especificadas no documento Necessidades do Cliente e Gloss rio Pelo Subproces
60. o devem ser definidos obedecendo conforme o tipo do asset aos seguintes Crit rios de Aprova o 1 Utilidade e reusabilidade dos requisitos de dom nio do componente 2 Utilidade e reusabilidade da arquitetura de dom nio do asset 3 Grande potencial de reuso dos requisitos para serem usados em v rios dom nios 4 Grande potencial de reuso da arquitetura de dom nio do asset ou parte dela para ser usada em v rios dom nios 5 Compatibilidade da arquitetura de dom nio do asset com o modelo de dom nio e componentes de dom nio 6 Conformidade com os padr es de reuso da organiza o estabelecidos no Programa de Reuso IEEE1517 1999 A sequ ncia de tarefas da atividade Planejamento consiste em PAA A1 1 Identificar o tipo de asset em fun o dos artefatos com qualidade aprovada pelo Processo de Controle de Qualidade conforme especificado na TAB 3 2 2 1 e registrar pedido de avalia o do asset PAA A1 2 Identificar e especificar os requisitos para avalia o do asset segundo Crit rios de Aprova o de asset supracitados PAA Al 3 Enviar as especifica es de requisitos para avalia o do asset ao Subprocesso de Verifica o do Processo de Controle de Qualidade para estabelecer uma lista de confer ncia para avaliar o asset baseado na perspectiva dos reutilizadores e selecionar respons veis qualificados para realiza o das verifica es Na perspectiva dos reutilizadores 19 ani fred Formaliza
61. o dos indicadores para promover a melhoria do processo Al m disso apresentado um estudo de caso aplicando o processo de garantia de software estabelecido em um projeto piloto Controlador T tico desenvolvido com base no processo de Desenvolvimento de Software Baseado em Reuso no Contexto do Minist rio da Defesa e de seus Comandos Subordinados de GURGEL 2004 Este estudo de caso aponta que a estrat gia utilizada pode proporcionar a melhora da qualidade do modelo conceitual final assim como no processo de produ o de software para reuso mais produtivo 16 ABSTRACT The software quality warranty in development based on reuse is currently a topic of a great interest mainly due to the need of assuring and controlling the quality of the software development process and of the generated products under the perspective of subsequent reuse In order to increase productivity and improve the quality of a software development process based on assets reuse software products created with the explicit purpose of later reuse a Software Quality Warranty Process is defined by a group of systematic activities designed to assure the adaptation needed to reuse software products So this process promotes assets and projects development in an effective way based on qualitative and quantitative aspects The quantitative indicators consist on assuring a better planning and control of assets and projects as well as the reuse on applications development b
62. os recursos que deveria ter utilizado para atingir os objetivos ou realizar as atividades programadas fazer certo as coisas SEPIN 2002 185 EFETIVIDADE sf A qualidade do que gera efeito real e resultados verdadeiros que merece confian a que se pode contar com seguran a SEPIN 2002 ENGANO s m A o humana que produz um resultado incorreto por exemplo uma a o incorreta tomada pelo programador IEEE610 12 1990 ENGENHARIA DE DOMINIO Uma linha baseada em reuso para definir o escopo defini o do dom nio especificar a estrutura arquitetura do dom nio e construir os assets por exemplo projeto de requisitos c digo de software documenta o para uma classe de sistemas subsistemas ou aplica es Engenharia de dom nio pode incluir as seguintes atividades defini o do dom nio an lise de dom nio desenvolver a arquitetura de dom nio e implementa o do dom nio NIST 1994 ENGENHEIROS DE DOM NIO Um grupo que desempenha atividades de engenharia de dom nio incluindo an lise de dom nio projeto de dom nio constru o de asset e manuten o de asset IEEE1517 1999 ERRO s m Diferen a entre o valor obtido e o valor esperado por exemplo qualquer estado intermedi rio incorreto ou resultado inesperado na execu o do programa constitui um erro IEEE610 12 1990 FALHA s m Produ o de uma sa da incorreta com rela o especifica o Veja tamb m n o conf
63. processo Caracter sticas Custo e cronograma confi veis desempenho de qualidade melhora mas ainda imprevis vel Atua o Estabelecer objetivos da qualidade quantitativos e medi es de processo KPA s Focaliza o do Processo da Organiza o Defini o do Processo da Organiza o Programa o de Treinamento Gest o Integrada de Software Engenharia do Produto de Software Coordena o Intergrupos An lise Cr tica Conjunta N vel 2 REPET VEL Maturidade Intuitiva Objetivo Controle gerencial b sico Caracter sticas Custo e qualidade vari veis controle de cronogramas m todos de processos informais e ad hoc Atua o Desenvolver defini es e pradr es de processo estabelecer recursos de processo e m todos requsistos projeto inspe o e teste KPA s Gest o de Requisitos Planejamento de Projeto de Software Supervis o e Acompanhamento do Projeto de Software Gest o da Subcontrata o de Software Garantia da Qualidade de Software Gest o da Configura o de Software N vel 1 INICIAL Maturidade Ca tica Objetivo N o estabelecido Caracter sticas Custo cronogramas e desempenho de qualidade imprevis veis Atua o Planejamento controle de desempenho controle de altera es gerenciamento de compromissos garantia da qualidade KPA s nenhuma FIG 7 3 2 Os n veis de maturidade do CMM CMMI SEI 2000 uma variante da CMM PAULK et al 199
64. processos hardware software facilidades e pessoas que prov em uma capacidade de atender uma necessidade ou objetivo definido ABNT12207 1998 STAKEHOLDER Um grupo ou indiv duo que possui um grande interesse no sucesso do sistema de software que est sendo desenvolvido e possui alguma influ ncia direta ou indireta nos requisitos do sistema HEINEMAN et al 2001 187 TEMPLATE Um asset com par metros ou slots que podem ser usados para construir uma inst ncia de asset IEEE1517 1999 USABILIDADE s f Conjunto de atributos que evidenciam o esfor o necess rio para se poder utilizar o software bem como o julgamento individual desse uso por um conjunto expl cito ou impl cito de usu rios ISO9126 1 2000 VALIDA O s f Confirma o por exame e fornecimento de evid ncia objetiva de que os requisitos espec ficos para um uso pretendido s o atendidos Informa es cuja veracidade pode ser comprovada com base em fatos obtidos atrav s da observa o medi o ensaios ou outros meios constituem evid ncia objetiva ISO8402 1994 VERIFICA O s f Confirma o por exame e fornecimento de evid ncia objetiva do atendimento aos requisitos especificados Processo de avalia o de um sistema ou componente com o objetivo de determinar se o produto de uma dada fase do desenvolvimento satisfaz s condi es impostas no in cio dessa fase ISO8402 1994 WALKTHROUGH s f T cnica de an lise est tica na
65. qual um projetista ou programador apresenta aos membros do grupo de desenvolvimento e outros profissionais interessados uma parte de documenta o ou c digo e os participantes fazem perguntas e coment rios sobre poss veis erros viola o de padr es de desenvolvimento ou sobre outros problemas TEEE828 1990 188
66. qualidade sente que eles Sim contribu ram para melhorar a qualidade do artefato ou asset pela verifica o revis o 3 Todos tiveram tempo suficiente para fazer prepara o Se N o pois a maioria n o possui conhecimento suficiente sobre n o quanto tempo precisa o mini mundo Controlador T tico 4 H necessidade de conhecimento espec fico para utilizar o Sim deveria ter um conhecimento sobre o Cortrolador T tico checklist t cnica de leitura para este tipo de artefato asset durante a prepara o 5 Foi til para detectar n o corformidades Sim 6 O checklist t cnica de leitura podem ser melhorados Sel Sim caso venha acompanhado de uma descri o dos sim como modelos 7 No subprocesso Revis o todos os participantes estavam Sim presentes Se n o quem estava ausente Indicar e justificar se nao havia necessidade 8 Os procedimentos para as verifica es revis es foram Sim sendo que alguns n o foram seguidos por falta de seguidos corretamente informa o textual do modelo 9 No subprocesso de Revis o como as reuni es conjuntas Na parte do treinamento quanto a explica o sobre dominio poderiam melhorar da aplica o 10 H necessidade de ajuda para realzar efetivamente Sim checklist t cnica de leitura 11 H alguma outra sugest o para melhorar o Processo N o Garantia da Qualidade Data 31 08 2004 Nome Ana Carolina Restrito Instituto Milita
67. que permite troca de informa es entre plataformas sobre acom panhamentos Giro O mesmo que agulha girosc pica Global Positioner System GPS Um dos Sistemas de Posicionamento Sat lite existente Sua precis o da informa o de posicio nam ento de aproximadamente 100 metros Hod metro Sensor que fornece a velocidade relativa da plataforma em rela o ao meio na qual ela se encontra Link Equipamento respons vel pela conex o de uma plataforma a outras atrav s de um enlace autom tico de dados por radio transmiss o O Link pode ser considerado como um sensor de detec o para o sistema Sistema Externo Sistema que n o pertencem ao Controlador T tico mas que interage com este fornecendo ou extraindo dados de acompanham ento e de ambiente Sistema de Posicionamento Sat lite Sistema formado por sensor que fornece atrav s da detec o de sinais enviados de sat lites informa es sobre a plataforma tais como latitude longitude rumo velocidade e altitude em rela o superf cie da terra Velocidade Relativa Velocidade da plataforma em rela o ao meio na qual se encontra Para Navios o mesmo que velocidade na superf cie Velocidade Velocidade abso luta ou relativa a superf cie da terra Para Navios o mesmo que velocidade no fundo Vento Realou Verdadeiro VV Rumo e dire o do vento existente no local Vento Relativo VR Rumo e velocidade do vento em rela o plataforma prim ria 178 Ce
68. que s o apresentadas no diagrama da FIG 3 2 2 1 Identifica o e Avalia o PAA PROCESSO APROVA O DE ASSETS Crit rios de Aprov a o conjunto de artefatos que comp e o assetcom qualidade aprov ada Identifica o Especifica es derequisitos do asset E PAA A1 documenta o do asset Comit deQualidade Relat rio Aprov a o Avalia o do Asset Relat rio Verifica o PAA A2 Comit deQualidade FIG 3 2 2 2 Diagrama de Constru o do Processo de Aprova o de Assets PAA As duas atividades do Processo de Aprova o de Assets s o detalhadas a abaixo 84 PAA A IDENTIFICA O A partir do recebimento do asset juntamente com seus respectivos artefatos com qualidade aprovada que o comp e o Comit de Qualidade deve identificar e especificar os requisitos do asset submetido para aprova o reusando um modelo aplic vel de especifica o de requisitos para aprova o de asset se existir segundo Crit rios de Aprova o de assets Essas especifica es de requisitos para aprova o de asset devem ser fornecidas ao Subprocesso de Verifica o do Processo de Controle de Qualidade para que os verificadores possam validar via checklist aspectos de reusabilidade e de compatibilidade dentre outros aspectos como padroniza o da documenta o rastreabilidade corretude e facilidade no entendimento das funcionalidades e objetivos do asset Para aprova o de asset os requisitos de aprova
69. rio Restrito Instituto Militar de Engenharia P gina 1 1 162 Garantia da Qualidade de Software Leitura Vertical 2 Vers o 1 2 RELV201 03 Data da vers o 03 03 2004 TLV 2 Necessidades do Cliente e Gloss rio X Modelo de Caracter sticas Objetivo Verificar se todas as caracter sticas expl citas comuns e vari veis do dom nio do problema atrav s das funcionalidades e caracter sticas desejadas est o capturadas no Modelo de Caracter sticas baseado no m todo FORM para estabelecer as possibilidades de sele o destas caracter sticas mediante uma tomada de decis o Este modelo deve estar representado em quatro camadas de capacidades identifica servi os opera es fun es apresenta es ou performances de uma aplica o de um dado dom nio que pode ser funcional ou n o funcional ambiente de opera o identifica ambiente operacional plataforma operativa sistema de rede de comunica o banco de dados tecnologia de dom nio detalha a implementa o de mais baixo n vel que mapeia um conjunto espec fico de t cnica de implementa o e t cnica de implementa o identifica algoritmos tipos abstratos de dados Pr requisito Esta leitura requer que o documento Necessidades do Cliente tenha sido aprovado pelo Processo Controle de Qualidade Entrada para o processo 1 Descri o das Necessidades do Cliente e Gloss rio 2 Modelo de Caracter sticas representado pelo diagrama de caracter sticas em c
70. rio de Verifica o ao Consultor de Qualidade alocado ao projeto Para apoiar os verificadores quanto aos objetos de verifica o o Consultor de Qualidade deve estabelecer lista de confer ncia checklist adequada ao artefato e requisitos do projeto reusando um modelo de checklist aplic vel ao artefato e requisitos do projeto a ser verificado se existir Os verificadores devem empregar o m todo checklist para detec o de defeitos por ser sistem tico ao ajudar a definir responsabilidades aos verificadores por sugerir um modo aos verificadores para identificar n o conformidades e principalmente por fornecer um modelo pr tico sem necessitar de treinamento pr vio Laitenberger LAITENBERGER 2002 relata que 25 artigos apontam o m todo checklist como um dos m todos de detec o de defeitos mais utilizados na ind stria de software O checklist sistem tico pois ajuda definir as responsabilidades dos verificadores e sugere um modo aos verificadores para identificar defeitos ou seja apresenta listas de perguntas itens do checklist que devem ser respondidas durante a leitura do documento Os itens do checklist capturam li es importantes adquiridas de verifica es anteriores dentro de um ambiente ou dom nio da aplica o Os itens de checklist particularmente podem enumerar caracter sticas de defeitos priorizar diferentes defeitos ou apresentar perguntas que auxiliam os verificadores descobrirem defeitos Entretanto este m
71. ser exercido de forma sistem tica ABNT12207 1998 IS015504 1998 PAULK et al 1993 SEI 2002 O software deve estar sem defeito aus ncia de n o conformidades bem documentado e desenvolvido por m todos eficazes e t cnicas adequadas KAN 1995 Um software bem documentado significa que a documenta o existe al m disso esta documenta o est completa e atualizada de acordo com as altera es realizadas no software ROCHA 2001 23 Al m disso um software de qualidade deve produzir resultados relevantes e confi veis no tempo certo ter as funcionalidades necess rias e as poss veis expectativas desejadas ao uso ser mensur vel ser corrig vel adaptativo e evolutivo operar com economia de recursos e ser desenvolvido economicamente dentro do prazo estipulado FIORINI et al 1998 STAA 2002 Para a qualidade ser efetiva dentro do processo de desenvolvimento de software ela deve resultar na redu o significativa do retrabalho CROSBY 1996 Desta forma os defeitos introduzidos ao longo do processo de desenvolvimento de software devem ser identificados o quanto antes se poss vel na pr pria fase em que s o cometidos pois o esfor o gasto e os custos associados para corrigir um defeito aumentam proporcionalmente ao tempo entre a sua introdu o e exclus o ou seja quanto mais cedo for descoberto o defeito menor o esfor o para corrigi lo JACOBSON et al 1997 FICHMAN 2001 ROCHA et al 2001 JONES
72. usa quatro caracter sticas comuns para organizar as pr ticas gen ricas conforme s o apresentadas na FIG 7 3 3 SEI 2002 N veis de Maturidade a y Se Peal gt rea de Processo 1 rea de Processo 2 rea de Processo n Objetivos Espec ficos Objetivos Gen ricos 1 ee d j Caracter sticas Comuns Compromisso Habilidade para Diretrizes para Verifica o de para realizar executar implementa o implementa o rove ae ee Praticas Especificas Praticas Gen ricas FIG 7 3 3 Componentes do Modelo CMMI representa o Organizado 7 3 1 INDICADORES DE PRODUTO DE SOFTWARE Para os indicadores do produto de software a norma ISO IEC 9126 ISO9126 2000 representa a atual padroniza o mundial para a qualidade de produtos de software definindo seis caracter sticas de qualidade e m tricas para um produto de software Cada uma dessas caracter sticas divide se em subcaracter sticas que associadas a uma defini o de m tricas para correlacion las ao produto de software permite uma avalia o da sua qualidade Al m disso cada caracter stica de qualidade depende da classe do produto de software e da tica do usu rio cliente usu rio final equipe de desenvolvimento e equipe de suporte Desta forma um software deve ter um conjunto de atributos que evidenciam as caracter sticas e
73. 0 ABNT9000 2001 apresenta como principal modifica o no objetivo da garantia da qualidade que anteriormente significava atendimento aos requisitos especificados para satisfa o do cliente A satisfa o do cliente envolve tanto os requisitos expl citos como os impl citos ou seja a satisfa o est diretamente relacionada com a qualidade dos produtos e servi os fornecidos 129 A Norma ISO IEC 12207 ABNT12207 1998 estabelece um modelo para defini o de processos de software onde as etapas relevantes s o defini o do processo padr o especifica o do processo padr o e a instancia o para projetos Ela oferece uma estrutura de processos baseada em framework para processos de ciclo de vida com terminologia bem definida processos fundamentais processos de apoio e processos organizacionais Esta norma cont m processos atividades e tarefas que devem ser aplicadas aquisi o de sistemas que cont m software produtos de software stand alone e servi os de software durante o fornecimento desenvolvimento opera o e manuten o de produtos de software A Norma ISO IEC 9126 1S09126 2000 define seis caracter sticas de qualidade e m tricas para um produto de software Um software deve ter um conjunto de atributos que evidenciam as funcionalidades a confiabilidade a usabilidade a efici ncia a manutenibilidade e a portabilidade Cada uma dessas caracter sticas subdivide se em outras que associadas a uma defini
74. 1 2 2 2 apresentada a expans o dos processos e subprocessos que comp em o Processo de Garantia da Qualidade do Software mostrando todas as intera es com os processos do rg o Central de Ger ncia de Reuso e do rg o Descentralizado de Fornecimento de Software de GURGEL 2004 al m do feedback s equipes de desenvolvimento montadores e ger ncia 63 Processo de Garantia de Qualidade do Asset no Contexto do Minist rio da Defesa e de seus Comandos Subordinados rg o Central de Ger ncia de Re so o Processo de Processo de Aquisi o Gerente Ger ncia de Assets deReuso GGOSC Manual da Processo de Garantia de Qualidade Qualidade de Software ao do Asset Asset deDom nio Relat rios de Aprova documenta o Necessidades do Gloss rio PCQ Processo de Controle da Qualidade Verifica o Revis o Medi o e Avalia o Relat rios de Dominio documenta o Asset deComponentede Dom nio documenta o Asset deComponentes Asset de Arquitetura de documenta o SPV aa a Subprocesso de requisitds do asset PAA Processo de SPM elat rio Verifica o Verifica o Relat rio Verifica o Aprova o de Asset t de Medi o e Avalia o A A artefatos e ee Rel d V rifi ET ERA PA A gde asset artefatos com qualidade aprov ada E da Qualidade ao de Aplica o Diagramade Intera es entreCamadas Arquiteturade Dom nio specifica
75. 1 4 Opera o Atividades do operador de software Inclui teste operacional opera o de software e suporte operacional aos usu rios 1 5 Manuten o 2 Processos de Apoio Atividades do manutenedor de software Inclui an lise do problema e da modifica o implementa o da modifica o revis o e aceita o da manuten o migra o e descontinua o do software Processos que prov em apoio a um outro processo como parte integrante com prop sito distinto e que contribuem para o sucesso e qualidade do projeto de software 2 1 Documenta o Registro de informa es produzidas por um processo ou atividade Inclui planejamento projeto desenvolvimento produ o edi o distribui o e manuten o dos documentos necess rios a gerentes engenheiros e usu rios do software 2 2 Ger ncia de Configura o Identifica o e controle dos itens do software Inclui controle de armazenamento Libera es manipula o distribui o e modifica o de cada um dos itens que comp em o software 2 3 Garantia da Qualidade Garante que os processos e produtos de software estejam em conformidade com os requisitos e os planos estabelecidos 2 4 Verifica o Determina se os produtos de software de uma atividade atendem completamente aos requisitos ou condi es impostas a eles 2 5 Valida o Determina se os requisitos e o produto final sistema ou software atendem ao uso esp
76. 12 Quando um m dulo executa I O externo s o realizados testes de interface 1 13 Os atributos de arquivo est o corretos 1 14 As declara es OPEN CLOSE est o corretas 1 15 A especifica o de formato est adequado a declara o de I 0 1 16 Otamanho do buffer est adequado ao tamanho dos registros 1 17 Os arquivos foram abertos antes de serem usados 1 18 As condi es de fim de arquivo s o controladas 1 19 Oserros de I O s o controlados 1 20 H ocorr ncia de erro textual nas informa es de sa da Total de itens do aspecto verificados Total de n o conformidades 1 1 on NN NAHNAHAHAAHARHUAVn NU on 2 Aspecto Padr es Este aspecto deve analisar nomes tipos e exce es de dados e vari veis 2 1 Ocorr ncia de datilografia impr pria ou incompat vel 2 2 Ocorr nciade inicializa o err nea ou valores default 2 3 Ocorr nciade nomes de vari veis incorretos mal escritos ou truncados 2 4 Ocorr nciade tipos de dados incompat veis 2 5 Ocorr nciade underflow overflow e exce es Total de itens do aspecto verificados Total de n o conformidades 3 Aspecto Completude Este aspecto deve analisar os recursos envolvidos para ajudar na realiza o do teste 3 1 Ainterface de componente foi testada completamente 3 2 Os dados locais foram testados nos seus limites 3 3 Todos os caminhos b sicos independentes foram testados 3 4 Todos os loops foram testados adequadamente 3 5 Todo o fluxo de dados foi
77. 1996 A Leitura baseada em Defeito concentra se em especificar classes de defeitos enquanto que a Leitura baseada em Perspectiva concentra se na vis o dos usu rios do documento BASILI et al 1996 projetistas na fase de projeto testadores na fase de testes e usu rios na fase de opera o A principal id ia da t cnica de Leitura baseada em Perspectiva que um produto de software deve ser inspecionado sob a perspectiva de diferentes stakeholders BASILI et al 1996 BRIAND et al 1998 LAITENBERGER et al 1997 LAITENBERGER 2000 LAITENBERGER 2002 Para cada perspectiva tanto um como v rios cen rios s o definidos consistindo de atividades repet veis que um revisor precisa executar e de perguntas que um revisor deve responder A t cnica de Leitura baseada em Perspectiva foi aplicada para inspecionar documentos de requisitos BASILI et al 1996 modelos de projeto orientado a objeto LAITENBERGER et al 1997 e documentos de c digo LAITENBERGER 2000 A principal id ia da Leitura baseada em Defeito que diferentes revisores focalizam diferentes classes de defeito enquanto examinam o mesmo documento MILLER et al 1998 PORTER et al 1998 PORTER et al 1995 SANDAHL et al 1998 LAITENBERGER 2002 Para cada classe de defeito h um cen rio que consiste em um conjunto de perguntas que um revisor deve responder enquanto l Ao responder as perguntas o revisor deve estar detectando defeitos daquela classe em particular
78. 225 minutos T cnica de Leitura Vertical 2 quantidade de n o conformidade severidade 3 13 3 5 8 13 45 Dura o 40 50 65 65 40 45 305 minutos minutos minutos minutos minutos minutos minutos Os dados coletados para os indicadores de IQPOOR s o apresentados na TAB 4 2 4 2 2 TAB 4 2 4 2 2 Resultados dos dados coletados para os indicadores de IQPOOR Sigla Descri o Dados N mero M dio de Antecessores Acoplamento Direto da Classe Coes o entre M todos na Classe N mero de M todos Medida de Agrega o Medida de Acesso aos Dados Medida de Abstra o Funcional N mero de Hierarquia Tamanho da Interface da Classe N mero de M todos Polimorfos Tamanho do Projeto em Classes Os dados coletados apresentados nas TAB 4 2 4 2 1 e TAB 4 2 4 2 2 foram aplicados nas fun es de c lculo dos indicadores IQPVR IPPVR e IQPOOR conforme especificado no Planejamento da Medi o Na TAB 4 2 4 2 3 apresentado o resultado das medi es realizadas para os indicadores estabelecidos no Planejamento da Medi o 110 TAB 4 2 4 2 3 Resultado das medi es para os indicadores estabelecidos no Planejamento da Medi o Indicadores l l Resultados Sigta Descri o Qualidade do Processo de Verifica o e Revis o 0 Produtividade do Processo de Verifica o e Revis o 9 02 Compreensibilidade do Projeto 12 74 Ef
79. 3 que apresenta uma abordagem mais flex vel em duas dimens es Cont nuo e Organizado Os benef cios da representa o por Cont nuo consistem em sele o da ordem de melhoria que melhor apresenta os objetivos do neg cio da organiza o e redu o das reas de risco da organiza o compara es entre organiza es sobre uma rea de processo pela compara o dos resultados facilidade de compara o com o modelo de melhoria de processo da ISO 15504 SPICE 1S015504 1998 A implanta o do modelo por Organizado tem como benef cios uma sequ ncia de melhorias iniciando pelas pr ticas gerenciais b sicas e progredindo para os n veis predefinidos sucessivos cada n vel serve como funda o para o pr ximo possibilita 131 compara es entre organiza es pelo uso dos n veis de maturidade f cil migra o do modelo CMM para o CMMI fornece um nico n mero que sumarize os resultados da avalia o e permita compara o entre organiza es Ambas representa es oferecem resultados equivalentes se utilizadas para melhoria do processo ou avalia es A representa o do Organizado organiza reas de processo dentro de cinco n veis de maturidade para suportar e guiar o processo de melhoria Inicial Gerenciado Definido Quantitativamente Gerenciado e Otimiza o Cada rea de processo possui objetivos espec ficos pr ticas espec ficas objetivos gen ricos e pr ticas gen ricas A representa o do Organizado
80. 3 a saber Numero M dio de Antecessores NMA o n mero m dio de classes que herdam informa o 106 Acoplamento Direto da Classe ADC o n mero de classes que uma classe se relaciona diretamente Coes o entre M todos na Classe CMC o n mero de intersec es dos par metros de um m todo com o conjunto m ximo independente de todos os tipos de par metros na classe N mero de M todos NM o n mero total de m todos definidos em uma classe Medida de Agrega o MAg o n mero de declara es de dados cujos tipos s o classes definidas Medida de Acesso aos Dados MAD a rela o entre os atributos privados protegidos pelo n mero total de atributos declarados na classe Medida de Abstra o Funcional MAF a rela o entre o n mero de m todos herdados por uma classe pelo n mero total dos m todos acess veis por m todos de membro da classe Numero de Hierarquia NHq o n mero de classes hier rquicas no projeto Tamanho da Interface da Classe TIC o n mero de m todos p blicos em uma classe Numero de M todos Polimorfos NMP o n mero total de m todos que podem ter comportamento polimorfo Tamanho do Projeto em Classes TPC o n mero total de classes no projeto TAB 4 2 4 1 4 Fun es de c lculo das medi es das qualidades do projeto OO com os ndices definidos por BANSIYA et al 2002 Fun es de Medi o Compreensibilidade 0 33 NMA ADC CM
81. 7 6 get 7 retorno CDS Ey fm 8 retorno 9 calcularRumoVeloc 10 set 11 getPlatPrim gt 12 retorno se acomp Em PlatPrim 13 getP os 14 get 15 retorno ade Ba ss O E 16 retorno H 17 calcularPMA 18 calcularRPS T 19 setDadosT ticos a gt Ly 20 retorno 182 Especifica o de Componentes Componente InsDadosAmb com suas depend ncias comp esp D Ami interface type InsDadosAmb gt linsDadosAmb insDadosAmb in ventoRelativo Vetor in velocRelativa Vetor interface type interface type xs interface type IplatMgt ICalculaCorente ICalc ula Vento Real Componente CalculaCorrente com suas depend ncias comp esp etait CalculaCorrente suena pes E ICalculaCorrente calcula in dadosPlataforma Vetor in velocRelativa Vetor Vetor i avi nterface type ISomaVetorial Componente Calcula VentoReal com suas depend ncias comp esp laVento Real interface type di ICakulaCorrente calcula in dados Plataforma Vetor in ventoRelativo Vetor Vetor gt interface type ISomaVetorial Componente SomaVetor comp esp SomaVetor a interface type g ISomaVetor soma in vetorA Vetor in vetorB Vetor Vetor Componente Extra o Extra o extrairPlatPrim Plataforma Prim ria extrairPos EstPrim D
82. C NM MAD NMP TPC Efetividade 0 22 NMA MAg MAD MAF NMP Extensibilidade 0 5 NMA ADC MAF NMP Flexibilidade 0 25 ADC MAD 0 5 MAg NMP Funcionalidade 0 12 CMC 0 22 NHq TIC NMP TPC Reusabilidade 0 25 ADC CMC 0 5 TIC TPC Baseados nos formul rios de defini o de Constru o Mensur vel proposto pelo PSM foram estabelecidos os seguintes formul rios Especifica o de Indicadores TAB 4 2 4 1 5 Procedimento de Coleta de Dados TAB 4 2 4 1 6 e Procedimento para An lise de Dados TAB 4 2 4 1 7 Estes formul rios foram aplicados nas especifica es de indicadores para apoiar as decis es das atividades de acompanhamento e gest o da qualidade dos artefatos dos processos de Engenharia de Dom nio e Desenvolvimento de GURGEL 2004 Nas tabelas 107 TAB 4 2 4 1 5 TAB 4 2 4 1 6 e TAB 4 2 4 1 7 s o apresentados os formul rios para especifica o do Indicador de Qualidade do Processo de Verifica o e Revis o TAB 4 2 4 1 5 Especifica o do Indicador de Qualidade do Processo de Verifica o e Revis o ESPECIFICA O DO INDICADOR DE QUALIDADE DO PROCESSO DE VERIFICA O E REVIS O Sigla IQPVR Vers o 1 3 Data 10 05 2004 Necessidade de Informa o Avaliar a qualidade dos artefatos para a produ o do asset Categoria de Informa o Qualidade do Produto Conceito Mensur vel Artefato sem defeito Entidade
83. CLO DE VIDA DO SOFTWARE NOS PADR ES DA ISO 12207 A norma ISO IEC 12207 ABNT12207 1998 estabelece um framework comum para o ciclo de vida de software mas n o especifica os detalhes de como implementar estes requisitos de processo Na TAB 7 3 2 1 apresentada uma lista completa e resumida dos processos desta norma A vers o brasileira da norma foi preparada pela ABNT Associa o Brasileira de Normas T cnicas em outubro de 1998 NBR ISO IEC 12207 ABNT12207 1998 TAB 7 3 2 1 Processos do Ciclo de Vida do Software nos padr es da ISO12207 Processos Descri o Processos Fundamentais Processos que atendem as partes principais pessoa ou organiza o Essas partes s o respons veis por iniciar ou executar o desenvolvimento opera o ou manuten o de software durante o seu ciclo de vida 1 1 Aquisi o Atividades do adquirente do software Inclui defini o da necessidade de adquirir um software produto ou servi o pedido de proposta sele o de fornecedor ger ncia da aquisi o e aceita o do software 1 2 Fornecimento Atividades do fornecedor de software Inclui preparar uma proposta assinatura de contrato determina o de recursos necess rios planos de projeto e entrega do software 1 3 Desenvolvimento Atividades do desenvolvedor de software Inclui an lise de requisitos projeto de arquitetura codifica o integra o testes instala o e aceita o do software
84. DESENVOLVIMENTO BASEADO EM REUSO NO CONTEXTO DO MD Necessidades do Cliente 1 Objetivos Auxiliar e automatizar algumas das tarefas de Compila o do Quadro T tico a fim de aumentar os n veis de confiabilidade e disponibilidade das informa es t ticas e melhorar a visualiza o do cen rio t tico 2 Dominio Compila o do Quadro T tico dentro do dom nio de Sistemas de Comando Controle e Navega o 3 Refer ncias Gloss rio Controlador T tico 2 0 4 Vis o Geral do Produto O Controlador T tico dever receber dados dos diversos sensores existentes na plataforma ou de inser o manual e ser capaz de tratar estes dados coletados fomecendo informa es t ticas em tempo real a fim de auxiliar na compila o e avalia o do Quadro T tico 5 Funcionalidade 5 1 Recep o de dados de sensores O aplicativo dever ser capaz de receber dados dos diversos sensores como girosc picas hod metros anem metros GPS DGPS radares e outros al m da possibilidade de inser o manual de valores dos mesmos 5 2 Comunica o via Link YB 14 O aplicativo dever ser capaz de receber dados das diversas plataformas que possuam sistemas autom ticos de informa es t ticas e que as trans mitam atrav s do link YB 5 3 C lculo do Rumo e Velocidade reais da plataforma prim ria Calcular rumo e velocidade reais da plataforma prim ria baseado nos dados de duas posi es inseridos diretamente por um sensor ou inser o manual do op
85. EL T CNICO O Processo de Controle de Qualidade PCQ ao N vel T cnico consiste em exercer avalia es t cnicas dos artefatos assets produzidos nos processos de Engenharia de Dom nio e de Desenvolvimento assim como do documento Necessidades do cliente e Gloss rio do processo de Aquisi o do Processo de Desenvolvimento de Software baseado em Reuso para MD GURGEL 2004 veja FIG 3 2 1 2 1 Na FIG 3 2 1 2 1 s o apresentadas as intera es do Processo de Controle da Qualidade PCQ ao N vel T cnico com os processos de GURGEL 2004 apresentando os artefatos de entrada sa da com seus respectivos pap is e os respons veis pelo PCQ Este processo abrange os subprocessos de Verifica o SPV Revis o SPR e Medi o e Avalia o SPM que ser o detalhados nas pr ximas subse es Processo de Necessidades do Relat rios de Verifica o Revis o e Aquisi o Cliente e Gloss rio Medi o e Avalia o Gerente de GGQSC Re so Processo de Controle Gerente de Re so de Qualidade PCQ Gerente do Projeto Processo de ao N vel T cnico Ea Engenharia de Dom nio artefatos assets ontadores Engenheiros de gt assets artefatos com Dom nio qualidade aprovada Processo de Processo de specifica o de Requisitos do Aprova o de Assets Desenvolvimento ait fatos assels Consultor de Qualidade ae ee ERA TITE Desenvolvedores do Projeto GGQS eee Qualidade montadores Grupo de
86. GQS com os processos de GURGEL 2004 especificando os artefatos de entrada sa da com seus respectivos pap is e os respons veis pelo PGQS 5 Artefato da atividade Prepara o do Plano de Aquisi o do Processo de Aquisi o do Processo de Desenvolvimento de Software baseado em Reuso para MD de GURGEL 2004 O artefato Necessidades do Cliente e Gloss rio defini o dom nio do problema funcionalidades e caracter sticas desejadas e gloss rio de termos do dom nio da aplica o 57 Necessidades do Cliente e Gloss rio Cliente Manual da Qualidade Processo de Garantia do Projet da Qualidade de Stakeholders artefatos assets Software Processo de Engenharia de Dom nio Engenheiros de Assets A Dom nio Documenta o Processo de Ger ncia gt de Assets Processo de y Gerente de Desenvolvimento piiglatosiassels Re so Desenvolvedores Grupo de GSQ Corporativo montadores Comit de Qualidade FIG 3 2 1 Processo de Garantia da Qualidade de Software O Grupo de GQS Corporativo envia este manual junto com o Pedido da Proposta ao Comit da Qualidade do rg o de Fornecimento de Software interno ou externo organiza o para que este comit possa estabelecer o Grupo de Garantia de Qualidade de Software e definir um Plano e Cronograma de Garantia da Qualidade para o projeto em quest o Tanto o plano como o cronograma devem ser integrados pelo Plano de Ge
87. M tricas o Asset FIG 3 2 1 2 1 Processo de Controle de Qualidade ao N vel T cnico Este processo inicia com o recebimento de um artefato prontificado pelos engenheiros de dom nio ou pela equipe de desenvolvimento montadores para ser inspecionado ou verificado conforme o PGQSP e cronograma do projeto No final de cada semana o Gerente do Projeto deve receber do Comit de Qualidade os relat rios das avalia es t cnicas realizadas Relat rios de Verifica o e Revis o na semana Estes relat rios devem conter todas as n o conformidades detectadas e devem ser produzidos pelo Grupo de GQS e Consultor de Qualidade alocados ao projeto conforme o PGQSP 62 A cada nova vers o do projeto conforme estipulado no Plano de Ger ncia do Projeto o Grupo de M tricas deve medir e analisar os dados coletados nos Subprocessos de Verifica o e Revis o e deve enviar um Relat rio de Medi o e Avalia o juntamente com todos os Relat rios de Verifica es e Revis es gerados no per odo de uma vers o para a seguinte aos Gerentes de Reuso e do Projeto uma semana ap s da prontifica o da vers o O Gerente de Projeto juntamente com o Consultor de Qualidade devem determinar quando e quais n o conformidades devem ser resolvidas pela equipe de desenvolvimento engenheiros de dom nio Ap s a cada altera o ou quando uma nova refer ncia for estabelecida necess rio repetir o Controle de Qualidade Na FIG 3
88. MINIST RIO DA DEFESA EX RCITO BRASILEIRO SECRETARIA DE CI NCIA E TECNOLOGIA INSTITUTO MILITAR DE ENGENHARIA Real Academia de Artilharia Fortifica o e Desenho 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 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 Disserta o de Mestrado apresentada ao Curso de Mestrado em Engenharia de Software do Instituto Militar de Engenharia como requisito parcial para a obten o do t tulo de Mestre em Ci ncias da Computa o Orientador Ten Cel Ulf Bergmann D C Co orientador Cel Jos Ant nio Moreira Xex o D C Rio de Janeiro 2004 c2004 INSTITUTO MILITAR DE ENGENHARIA Pra a General Tib rcio 80 Praia Vermelha Rio de Janeiro RJ CEP 22290 270 Este exemplar de propriedade do Instituto Militar de Engenharia que poder inclu lo em base de dados armazenar em computador microfilmar ou adotar qualquer forma de arquivamento E permitida a men o reprodu o parcial ou integral e a transmiss o entre bibliotecas deste trabalho sem modifica o de seu texto em qualquer meio que esteja ou venha a ser fixado para pesquisa ac
89. N o Conformidade N o Resolvida o Grupo de GQS apontou a n o conformidade no entanto a equipe de desenvolvimento relata que n o vai resolver a n o conformidade a o n o realizada Quando uma ocorr ncia de n o conformidade n o resolvida pela equipe de desenvolvimento no prazo estabelecido o Grupo de GQS deve reportar a ocorr ncia ger ncia de reuso A ger ncia de reuso pode fornecer uma dispensa a equipe de desenvolvimento da solu o da ocorr ncia de n o conformidade TAB 4 2 4 1 1 Os principais objetivos perguntas e m tricas relativos aos estados das n o conformidades encontradas durante a verifica o e revis o dos artefatos Objetivo controlar as n o conformidades detectadas nas verifica es revis es dos artefatos inspecionados Quest es M tricas 1 Quantas n o conformidades detectadas N de n o conformidades detectadas 2 Quantas n o conformidades resolvidas N de n o conformidades resolvidas dentro do prazo N de n o conformidades resolvidas fora do prazo 3 Quantas n o conformidades n o resolvidas N de n o conformidades n o resolvida 4 2 4 1 2 INDICADORES DE PRODUTIVIDADE DO PROCESSO DE VERIFICA O E REVIS O IPPVR Na TAB 4 2 4 1 2 apresentado o modelo GQM Goal Question Metric aplicado ao esfor o associado as atividades de verifica es e revis o na realiza o das listas de confer ncias checklists e t cnicas de leitura verticais
90. National Institute of Standards and Technology 14 OO Orientado a Objeto PAA Processo de Aprova o de Assets PCQ Processo de Controle da Qualidade PDCA Plan Do Check Act Ciclo de Deming PF Pontos de Fun o PSM Practical Software Measurement PGQS Processo da Garantia de Qualidade de Software PGQSP Plano de Garantia de Qualidade de Software do Projeto QSMGQ Question rio de Sugest es para Melhoria da Garantia da Qualidade SADT Structure Analysis and Design Technique SEI Software Engineering Institute SEPIN Secretaria da Pol tica de Inform tica SPICE Software Process Improvement and Capability dEtermination SPM Subprocesso de Medi o e Avalia o SPR Subprocesso de Revis o SPV Subprocesso 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 RESUMO A garantia da qualidade de software no desenvolvimento baseado em reuso um dos principais fatores para assegurar e controlar a qualidade do processo de desenvolvimento de software e dos artefatos gerados visando posterior reutiliza o Um Processo de Garantia de Qualidade de Software definido por meio de um conjunto de atividades sistem ticas para assegurar a adequa o ao reuso de artefatos visando obter maior produtividade e melhoria da qualidade de um processo de desenvolvimen
91. O NO CONTEXTO DO MD Org o Central de Ger ncia de Re so as Assets Candidatos Processode Aquisi o An lise de Assets Candidatos ASSES Candidatas ProcessodeGer ncia Prepara o do Plan de Asseis Necessidades do Prepara o do t Cliente e Glossari quisi Contra 2 Gerente de repara o do Teste d fonitoracdo do tt Cliente Operacionalizado Prepara o do Pedido da a Mecanismode ae Aceita o Comunica oda Ger ncia e Controle Ger ncia de Assets rg o Descentralizado de Fornecimento de Sw ato do pma hal Mecanismode Comuni idoda Proposta a Contr Stat Fornecimento Sistem Operacio A i ProcessodeFornecimento ssets Candidatos Prepara o da i i Proposta Prepara o do Plano Ger ncia de Assets de Ger ncia do Projeto Defini o das necessidas d ProcessoaoLongodo Fornecimento Projeto ee E Ger ncia do Projeto A Avalia o de Op es de Engenharia de Fornecimento Dom nios An lise doDominio vimento ProjetodoDom nio ProcessodeDesenvolvimento An lise de Requisitos do Sele o da Tecnologia Sistema Sele o de Assets doDominio ele o de Assetsde C digo Montagem doSistema Teste de Sw Teste doSistema Sistema Operaciondlizado Assit ncia Engenharia de Dom nios Consullana Relat rio de E j EAA Operacionaliza o do Sistema Problemas Suporte ao Usu rio Ee SRS Salehoker 170 8 2 ANEXO 2 ARTEFATOS DOS PROCESSOS DE ENGENHARIA DE DOM NIO E
92. O gloss rio disp e de todas as defini es e explica es que o revisor necessita para o completo entendimento das necessidades e caracteristicas desejadas s s 1 5 Os n meros das linhas do texto do documento est o impressos para facilitar a refer ncia de localiza o especifica durante a verifica o s s Total de itens do aspecto verificados 5 2 Aspecto Qualidade Total de nao conformidades 1 Este aspecto descreve a qualidade que as necessidades isto as funcionalidades e as caracter sticas desejadas devem apresentar no documento P C I 2 1 As necessidades apresentam n vel de detalhamento adequado s s 2 2 Todas as caracter sticas de desempenho est o corretamente especificadas s s 2 3 Toda as considera es de seguran a est o corretamente especificadas s s 2 4 Outras caracter sticas desejadas de qualidade pertinentes est o explicitamente documentadas e quantificadas de acordo com o objetivo especificado s s Total de itens do aspecto verificados 3 Aspecto Completude Total de nao conformidades OU Este aspecto descreve o que o documento deve apresentar com rela o consist ncia das necessidades e a completude destes documentos P C I 3 1 As funcionalidades e caracter sticas desejadas prov em uma base adequada para an lise de requisitos da engenharia de dom nio 0 a 3 2 O documento Necessidades do Cliente inclui todas as funcionalidades do sistema s s 3 3 O documento Necessidades do Cliente incl
93. QUISITO s m Necessidade ou expectativa do cliente e de outra parte interessada geralmente explicitada como condi o de neg cio no contrato com o fornecedor para resolver um problema ou alcan ar um objetivo uma caracter stica tais como especifica o t cnica prazo de entrega garantia que o cliente requer do produto ABNT9000 2001 RETRABALHO s m A o sobre um produto n o conforme afim de torn lo conforme aos requisitos ABNT9000 2001 REUSABILIDADE s f A O grau que um asset pode ser utilizado em mais de um sistema de software ou na constru o de outros assets B Em uma biblioteca de reuso a caracter stica de um asset de ser utilizada em diferentes contextos sistemas de software ou na constru o de diferentes assets IEEE1517 1999 REUSO s m O uso de um asset na solu o de diferentes problemas IEEE1517 1999 REUSO SISTEM TICO A pr tica de reuso de acordo com um processo bem definido e repet vel TEEE1517 1999 SATISFA O DO CLIENTE Percep o do cliente do grau no qual os seus requisitos foram atendidos Reclama es de cliente s o indicadores usuais da baixa satisfa o do cliente por m sua aus ncia n o implica necessariamente alta satisfa o do cliente Mesmo que os requisitos tenham sido acordados com o cliente e atendidos isto n o garante necessariamente uma alta satisfa o ABNT9000 2001 SISTEMA Uma composi o integrada que consiste de um ou mais
94. Qualdade de Software Checklist Plano de Testes de Qualifica o Vers o 1 2 VEPT001 03 Data da vers o 01 03 2004 Checklist Plano de Testes de Qualifica o Artefato Verificado CTPT001 03 As quest es devem ser respondidas ap s um breve contato como documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exoeto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero seguencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 1 Aspecto Planejamento de teste Este aspecto deve analisar o planejamento de teste 1 1 vi vel a realiza o de teste 1 2 Os objetivos de testes est o definidos 1 3 Todas as depend ncias de testes est o referenciadas por exemplo fun o de driver hardware 1 4 O ambiente deteste est completamente especificado 1 5 As condi es de parada e rein cio de teste est o definidas Total de itens do aspecto verificados Total de n o conformidades 2 Aspecto Padr es e Rastreabilidade Este aspecto deve analisar os padr es e a rastreabilidade dos requisitos nos casos de teste 2 1 Todos os padr es especificados no plano de teste est o sendo seguidos 2 2 O plano de teste estabelece todas as especifica
95. S E S MBOLOS SUM RIO COCO COCO COLOCO OCO OC COCO CCO C COLOCO OCO OC COCO COCO OO COCO CO OCO COCO OC OO COCO CCO OCO 0 0 COCO COCO COCO OCO COCO COLOCO CCO CO COCO OC CC OCO C OCO OO OCO CC COCO OC CC OCO OO COOL O CCO OCO COCO OCO COCO 0000 INTRODU AU quereis raras ant ida ads tan aiii sa dad eee te RR DE VEEM AVR RR Ab 0 1h 4 E AROMAS RR RE e ERR RA E RCA RE OR ORNE ER A Vis o Geral do Processo Proposto ossada seassccccachaiaasedusdadsasbateadasiesadsadecactaanadedens EIEE NEE E E E E E S E ERR ERR ERR SRD POR RR FUNDAMENTOS TE RICOS cccccccsssosesossssesesesossssecesesesassececececossssesesesesasasces Engenharia de Qualidade irion n E aan gi Er A EA E E sued RD DR PR A OE SRA END T speches de SOWO ARDER e E E EA E E E Fer ee ea ee Tecnicas de Leitura de Sopa re oriee e ia E T ESEE S T cnica de Leitura Orientada a Objeto sicesiscseiiiisssiiisnrsissirreinissrrsiis issii P ograma de Medi o de Soff WATE essas pastos flop sndanddab ASSAR GAS nada diana nn died baiana Tecnicas O ra US OP PU aaa Goal Question Metric GQM cc sccccccccscsssssssceeeccesesesenseaeeecececsesessaaeeecececeeeenees Practical Software Measurement PSM eres eer rear Ita ria com Ro O eeann SR RD QD IEA LISTA DE SIGLAS 1 di la L2 13 1 4 2 2A 211 2 1 2 21 21 2 1 2 2 1 T cnica de Leitura Baseada em Perspectiva ei 213 2 1 3 1 Medi es T ticas e Hard para Pro
96. SANDAHL K BLOMKVIST O KARLSSON J KRYSANDER C LINDVALL M OHLSSON N An extended replication of an experiment for assessing methods for software requirements inspections Empirical Software Engineering v 3 n 4 1998 p 327 354 SEI SOFTWARE ENGINEERING INSTITUTE CMMI Capability maturity model integration v 1 1 CMU SEI 2002 TR 012 Software Engineering Institute Pittsburgh 2002 p 465 480 122 SEPIN SECRETARIA DA POL TICA DE INFORM TICA DO MINIST RIO DA CI NCIA DE TECNOLOGIA Qualidade e produtividade no setor de software brasileiro Brazilian Software ISSN 1518 112X 2002 Dispon vel www mct gov br sepin SINGER J VINSON N Ethical issues in empirical studies of software engineering IEEE Transactions on Software Engineering v 28 n 12 Dec 2002 p 1171 1180 Dispon vel http int iti nrc cnrc gc ca iit publication iti docs NRC 44912 pdf capturado em agosto de 2003 SOMMERVILLE I Software engineering 6 Edition Massachusetts Addison Wesley Aug 2000 693 p ISBN 02 01398 15 X STAA A Medi o Aspectos Conceituais Rio de Janeiro Pontif cia Universidade Cat lica do Rio de Janeiro PUC RJ 10 Out 2002 Aula ministrada aos alunos da p s gradua o TAVARES G Revis es t cnicas formais Quarto Simp sio Internacional de Melhoria de Processo de Software S o Paulo Brasil 2002 TERRY C Analysis and implementation of software reuse measurement Master s Project
97. Sess o T cnica VI 2003 10 p ARTHUR L J Improving software quality an insider s guide to TQM New York John Wiley amp Sons Jan 1993 310 p BANSIYA J A hierarchical model for quality assessment of object oriented designs PhD Dissertation University of Alabama in Huntsville 1997 BANSIYA J C DAVIS C G A hierarchical model for object oriented design quality assessment IEEE Transactions on Software Engineering v 28 n 1 Jan 2002 p 4 18 BARNES B H BOLLINGER T B Making reuse cost effective IEEE Software v 8 n 1 1991 p 13 24 BASILI V R ROMBACH D H BAILEY J DELIS A Ada reusability and measurement Computer Science Technical Report Series UMIACS TR 90 73 CS TR 2478 University of Maryland May 1990 Dispon vel http www cs umd edu projects SoftEng ESEG papers 84 67 pdf capturado em agosto de 2003 BASILI V MUSA J The future engineering of software a management perspective IEEE Computer v 24 n 9 Sep 1991 p 90 96 BASILI V R CALDEIRA G CANTONE G A reference architecture for the component factory ACM Transactions on Software Engineering and Methodology v 1 n 1 Jan 1992 p 53 80 BASILI V R CALDIERA G ROMBACH H D Goal question metric paradigm In Encyclopedia of Software Engineering v 1 John Wiley amp Sons 1994 p 528 532 115 BASILI V R GREEN S LAITENBERGER O LANUBILE F SHULL F SOUNGARD S ZELKOWITZ M V Th
98. Ss N EXECUTADO EXECUTA on ES NOK Dor 157 Aation Plan Check Do _ DEFINE METAS aa NT Action Pian Check Do 1 TREINA o TRABALHO Sic e FIG 1 3 1 a Ciclo PDCA de Deming b Espiral de ascens o da qualidade adaptado de FALCONI 1999 O PDCA constitui em um processo que atua sobre os demais processos dividido em 4 etapas a saber FALCONI 1999 1 Pan etapa de planejamento que consiste em estabelecer metas e m todos para alcan ar as metas propostas 2 Do etapa de execu o que consiste na realiza o das tarefas de acordo com o planejado e na coleta de dados da verifica o 3 Check etapa de verifica o onde os dados coletados s o comparados com os resultados esperados 4 Action etapa a o onde exercida uma atua o sobre o processo em si que pode ser de duas formas se as metas foram atingidas ent o o plano proposto deve ser adotado como padr o ou se as metas n o foram alcan adas a es devem ser exercidas sobre as causas do n o alcance das metas 1 4 ORGANIZA O Esta disserta o composta por cinco cap tulos No Cap tulo 1 Introdu o apresentada uma breve hist ria da inform tica desde sua cria o at os dias atuais para relatar como a qualidade e a reusabilidade de software est o inseridas dentro dos processos de engenharia de software Tamb m s o abordadas algumas defini es de qual
99. Testes de Componentes e de Sistema para assegurar a padroniza o da documenta o completude corretude rastreabilidade e qualidade do produto final SPV A2 VERIFICA O Na atividade Verifica o a partir da prontifica o do artefato asset pela equipe de desenvolvimento engenheiros de dom nio o verificador alocado verifica o do artefato asset conforme o cronograma e PGQS deve realizar uma an lise pr via do artefato asset Ap s a an lise o verificador embasado pela t cnica de Leitura baseada em 68 Perspectiva deve aplicar a lista de confer ncia checklist adequada ao artefato asset definida na atividade anterior para detec o de n o conformidades Esta atividade termina com a produ o do Relat rio de Verifica o e o envio deste ao Consultor de Qualidade alocado ao projeto Todas as n o conformidades detectadas no Relat rio de Verifica o devem ser corrigidas pelo respons vel pela elabora o do artefato verificado e suas corre es verificadas pelo verificador de qualidade respons vel As n o conformidades resolvidas e aprovadas devem constar no Relat rio de Verifica o E durante a realiza o da verifica o os problemas detectados que fogem ao escopo do respons vel pela elabora o do artefato devem ser listados no Relat rio de Verifica o assim como as a es decorrentes Os resultados das atividades de verifica o devem ser disponibilizados para a equipe de desenvolvimento m
100. a 97 T cnica Utilizada Os modelos definidos na se o 4 2 1 e os procedimentos propostos em SPR Al da se o 3 2 1 2 2 que inclui a defini o dos procedimentos para a T cnica de Leitura Horizontal e Vertical para os artefatos Modelo de Contexto do Dom nio Modelo Conceitual do Dom nio Modelo de Casos de Uso e Cen rios Modelo de Caracter sticas Modelo Tipo do Neg cio Interfaces da Camada de Neg cio Arquitetura de Dom nio Especifica o de Componentes do Dom nio e os relat rios correspondentes Tempo Despendido Cinco semanas Fatores de Influ ncia A utiliza o de um editor de texto MS Word atendeu ao prop sito da constru o dos procedimentos das t cnicas de leitura Avalia o dos Resultados e do Tempo Na elabora o dos procedimentos das t cnicas de leitura horizontal e vertical ocorreram algumas dificuldades Estas dificuldades foram quanto elabora o da sistem tica de passos para validar o Modelo de Caracter stica que por se tratar de um modelo abrangente contendo todas os requisitos os funcionais e n o funcionais necessitando de um especialista do dom nio Tamb m foi sentida a necessidade de uma verifica o quanto aos aspectos da viabilidade e padr es de projeto e interfaces e clareza para Arquitetura de Dom nio Como as inspe es individuais seguiram a proposta apresentada no Cap tulo 3 ent o foram preenchidos para cada artefato a ser revisado os modelos PGQSP Cr
101. a o Editora Marques Saraiva 1990 ISBN 85 85238 15 1 DERBY E Projetando m tricas teis utilizando observa o modelagem e mensura o na tomada de decis es Newsletter do BFPUG Janeiro 2001 Dispon vel http www bfpug com br capturado em janeiro de 2003 DOOLEAN E P Experiences with Fagan s inspection method Software Practice and Experience v 22 n 2 1992 p 173 182 D SOUZA D F WILLS A C Objects components and frameworks with UML The Catalysis Approach Massachusetts Addison Wesley Professional 1998 816 p FAGAN M E Advances in software inspections IEEE Transactions on Software Engineering v 12 n 7 July 1986 p 744 751 FALCONT V TQC controle da qualidade total 8 Edi o S o Paulo EDG 1999 224 p ISBN 85 86948 14 4 FAVARO J What price reusability A case study Ada Lett Spring 1991 p 115 124 FAVARO J A Comparison of Approaches to Reuse Investment Analysis 4th International Conference of Software Reuse Orlando April 1996 p 23 26 FEIGENBAUM A V Total Quality Control gu Editon Mc Graw Hill Jan 1991 896 p ISBN 00 70203 5 47 FENTON N E Software metrics a rigorous approach New York Chapman amp Hall 1991 360 p FICHMAN R G Incentive compatibility and systematic software reuse Journal of Systems and Software New York v 57 iss 1 April 27 2001 45 p FIORINI S T LEITE J C S P LUCENA C J P Reusing process pattern
102. a assinatura do m todo identificado no passo 2 Quando encontrado sublinhe o argumento de Discrep ncia pois um par metro de entrada n o est presente na assinatura do servi o da classe correspondente da especifica o da Interface da Camada da Aplica o 4 Para cada dado sublinhado em vermelho correspondente a a o sublinhada em verde na descri o do cen rio certifique que a assinatura do servi o da classe correspondente identificada retorna o dado com o mesmo tipo b sico Quando encontrado sublinhe em vermelho o nome da fun o e seu tipo b sico Caso contr rio preencha a Tabela de Discrep ncia pois um par metro de sa da n o est presente na assinatura do servi o da classe correspondente da especifica o da Interface da Camada da Aplica o Reveja todas as especifica es da Interface da Camada da Aplica o para assegurar que todas as classes e seus servi os est o sendo levados em considera o ENTRADAS Interface da Camada da Aplica o marcada com asterisco azul e verde sublinhada em azul verde e vermelho SA DAS Relat rio de Discrep ncias A Procure por classes de interfaces que tenham sido omitidas na especifica o da Interface da Camada da Aplica o 1 Certifique que n o exista nenhuma classe do tipo interface sem asterisco azul Caso exista alguma preencha a Tabela de Discrep ncia pois uma classe de interface n o deveria ser definida desta maneira relatando a necessidade de con
103. a Qualidade Gerente do Projeto Especifica o da Avalia o SPM A2 Pontua o requisitos gerenciais Consultor da Qualidade Plano de Medi o e Avalia o Planejamento da Avalia o Cronograma Modelo Relat rio Diagrama Mew SPM A3 A 9 Escopodaavalia o Medi o e de Causa responsabilidades Avalia o Efeito Consultor da Qualidade Avalia o com n v elde pontua o Relat rio da Avalia o Medi o e SPM A5 Avaliagao L Execu o da Medi o artefatos SPM A4 relat rios Grupo de M tricas Grupo de M tricas FIG 3 2 1 2 3 1 Diagrama de Constru o do Subprocesso de Medi o e Avalia o SPM 76 Este subprocesso inicia a An lise de Requisitos SPM A1 quando do recebimento do Manual da Qualidade pelo Comit de Qualidade para obten o dos requisitos e objetivos do projeto com o prop sito de definir os objetivos da avalia o da medi o Baseados neste manual o Consultor da Qualidade alocado ao projeto e o Gerente do Projeto devem definir os requisitos de qualidade e reusabilidade de acordo com as necessidades expl citas ou impl citas do projeto Os objetivos da avalia o devem atender a Norma ISO 9126 1 2000 e os crit rios de qualidade requeridos pelo Contrato A partir dos objetivos estabelecidos na atividade SPM A1 o Consultor da Qualidade alocado ao projeto deve selecionar m tricas definir n vel de p
104. a de qualidade ou seja o defeito encontrado no produto Portanto esta defini o est diretamente relacionada com a falta de defeito no produto Qualidade o conjunto de caracter sticas incorporadas ao produto atrav s do projeto e manufatura que determinam o grau de satisfa o do cliente FEIGENBAUM 1991 1 a Como o produto e o processo est o fortemente relacionados e n o podem ser separados quando se analisa a qualidade DEMING 1996 ABNT12207 1998 ROCHA 2001 ent o a qualidade do processo fundamental para se ter qualidade do produto software Requisitos entendidos como necessidades e expectativas do cliente 19 Qualidade o grau em que um sistema pode ser artefato ou processo de software atende aos requisitos especificados como tamb m s necessidades e expectativas mensur veis de todos os usu rios ROCHA et al 2001 A n o conformidade no processo de comunica o e transforma o da informa o no desenvolvimento de produtos de software s o enganos interpreta es err neas problemas de comunica o evolu o de requisitos defeitos ou erros que podem ocasionar o mau funcionamento do sistema ROCHA et al 2001 A n o conformidade pode ocorrer nas especifica es de requisitos projeto de sistema casos de testes ou documenta o PFLEEGER 2001 Assim as n o conformidades encontradas pelas verifica es e revis es de software referem se aos defeitos O defei
105. a de classes 3 Diagrama de Intera es representado por diagrama de segii ncia Procedimentos I Leia o Diagrama de Intera es para entender que servi os est o descritos e como estes deveriam ser implementados ENTRADAS Diagrama de Intera es SA DAS Relat rio de Discrep ncias Para cada diagrama de seqii ncia execute os seguintes passos A Encontre os atores objetos e classes e realce os de azul B Realce de verde a informa o trocada entre os objetos as setas horizontais Considere se esta informa o representa mensagens ou servi os Se a informa o trocada est muito detalhada para um n vel de mensagens devem se abstrair v rias mensagens juntas para entender que servi os elas est o fornecendo em conjunto Anote no diagrama de segii ncia descrevendo estes servi os e realce os de verde C Circule de amarelo quaisquer restri es nas mensagens e servi os tais como restri es no n mero de classes objetos que uma mensagem poderia enviar restri es nos valores globais de um atributo depend ncias entre dados ou restri es de tempo que podem afetar o estado de um objeto Tamb m circule de amarelo quaisquer condi es que determinam sob que circunst ncias uma mensagem pode ser enviada Il Identifique e inspecione os diagramas de classes Interfaces da Camada de Neg cio e de Aplica o relacionados para identificar se os objetos correspondentes est o precisamente descritos ENTRADAS Inter
106. a de passagem segura inserida a Inclui alarme de colis o b O sistema calcula rumo para passagem segura c O sistema armazena os dados calculados 174 Ator sistema externo 1 O sistema externo solicita dado a ser apresentado 2 O sistema calcula a posi o estimada da plataforma cujos dados foram solicitados 3 O sistema fornece dado solicitado Cursos Alternativos Passo 2 Trigger O dado solicitado de ambiente vento reale corrente a O sistema retorna ao passo 8 Passo 2 Trigger O dado solicitado de configura o limite do cen rio e dist ncia passagem segura a O sistema retorna ao passo 3 Passo 3 Trigger A posi o estimada da plataforma se encontra fora do cen rio t tico a O sistema cancela o acompanhamento da plataforma b Encerra o caso de uso NS Ator operador Trigger altera o da configura o dist ncia padr o para passagem segura e limite cen rio t tico Pr condi o pa e Curso Normal 1 O operador insere dist ncia para passagem segura e limite cen rio t tico 2 O sistema armazena dist ncia para passagem segura e limite cen rio t tico Cursos Alternativos Nome Acancelar acompanhamento ING Ator operador Trigger cancelamento de um acompanhamento Pr condi o j existir o acompanhamento Curso Normal 1 O operador define o acompanhamento a ser cancelado 2 O sistema cancela o acompanhamento Cursos Alternativos Nome i alarme de colis o Ator
107. a funcionalidade Favaro afirma que reuso orientado a componente reuso estreito FAVARO 1991 124 Reuso amplo o uso em massa pacotes completos como spreadsheets e sistema operacional FAVARO 1991 Reuso indireto reuso por meio de uma entidade intermedi ria O n vel indireto o n mero de entidades intermedi rias entre o item de reuso e o item sendo reusado BIEMAN et al 1993 Reuso direto reuso sem passar por uma entidade intermedi ria BIEMAN et al 1993 Reuso carry over quando uma vers o de um componente de software usado sem modifica o as is em uma vers o subseqiiente do mesmo sistema OGUSH 1992 Reuso influenciado o reuso com modifica es BIEMAN et al 1993 Escopo de dom nio refere se se o reuso ocorre dentro de uma familia de sistemas vertical ou entre fam lias de sistemas horizontal PRIETO DIAZ et al 1993 Reuso vertical Inter o reuso dentro da mesma aplica o ou dom nio Reuso horizontal Intra o reuso de partes gen ricas em diferentes dom nios de aplica o Ger ncia refere se ao grau de sistematiza o de reuso que pode ser sistem tico planejado ou ad hoc PRIETO DIAZ et al 1993 Reuso sistem tico ou planejado a pr tica sistem tica e formal de reuso como base nas ind strias de software Reuso ad hoc a sele o de componentes que n o s o projetados para reuso de uma biblioteca geral ou seja o reuso real
108. a na se o 4 2 4 1 4 DURA O DO ESTUDO CASO Ficou estabelecido o prazo de 4 quatro meses para realiza o do estudo de caso compreendendo de fevereiro a maio de 2004 A distribui o do tempo se deu conforme apresentado na FIG 4 1 4 1 Cronograma do Estudo de Caso Medi o Planejamento para Medi o Revis o Planejamento para Revis o Verifica o Planejamento paraVerifica o E Garantindo a Qualidade L__ 3 0 1 2 3 4 meses FIG 4 1 4 1 Cronograma do estudo de casos do prot tipo Controlador T tico 4 1 5 PARTICIPANTES DO ESTUDO CASO O projeto piloto teve apenas um consultor de qualidade e uma equipe acad mica com 8 oito participantes para realiza o das t cnicas de qualidade 89 4 1 6 OBJETIVO DO ESTUDO DE CASO O objetivo deste caso de uso a redu o de defeitos nos artefatos produzidos no processo de desenvolvimento de software baseado em reuso sob a tica dos desenvolvedores e clientes e o ganho dos atributos de qualidade como a reusabilidade flexibilidade e compreensibilidade 4 2 MONITORA O DO ESTUDO DE CASO 4 2 1 ETAPA GARANTINDO A QUALIDADE Para realiza o do processo de Garantia da Qualidade de Software alguns modelos foram estabelecidos antes da execu o das atividades do processo de Controle de Qualidade a saber Plano de Garantia da Qualidade de Software do Projeto PGQSP Cronograma para verifica es revis es de GQS do projeto Hist rico de
109. ablio Consultoria e Projetos Ltda Rio de Janeiro 2004 Ao vov meu marido e filhos pelo ap io e incentivo de meu aprimoramento Aos meus pais que sempre me orientaram e contribu ram para minha forma o educacional e profissional AGRADECIMENTO Agrade o a todas as pessoas que me incentivaram apoiaram e possibilitaram esta oportunidade de ampliar meus horizontes especialmente Aos meus orientadores Ulf Bergmann e Jos Ant nio Moreira Xex o por suas disponibilidades e aten es A todos os professores pelos conhecimentos transmitidos e aos funcion rios do Departamento de Engenharia de Sistemas do IME pelo apoio e aten o s amigas Claudia Hazan e Miriam Say o e minha irm Kenya pelo apoio nos momentos de d vidas Aos amigos de turma da PUC RJ e do IME pelo companheirismo e amizade bibliotec ria Rosane da PUC RJ pela aten o em todas s vezes que precisei de livros e artigos para estudo e desenvolvimento do meu trabalho Ao Centro de Ap io a Sistemas Operativos e Diretoria de Administra o da Marinha pelo apoio e incentivo Ao Instituto Militar de Engenharia IME pelo apoio e aten o Quando se pode medir o que est falando e expressar isso em n meros passa se a conhecer algo mais sobre isso mas quando n o se pode expressar em n meros seu conhecimento superficial e insatisfat rio LORD KELVIN LISTA DE ILUSTRA ES LISTA DE TABELAS LISTA DE ABREVIATURA
110. ad mica coment rios e cita es desde que sem finalidade comercial e que seja feita a refer ncia bibliogr fica completa Os conceitos expressos neste trabalho s o de responsabilidade do s autor es e do s orientador es Almeida Kleyna Moore Garantia da qualidade de software no desenvolvimento baseado em reuso uma abordagem no contexto do Minist rio da Defesa e de seus comandos subordinados Kleyna Moore Almeida Rio de Janeiro Instituto Militar de Engenharia 2004 p il tab 29 7 cm Disserta o mestrado Instituto Militar de Engenharia 2004 1 Processo de Qualidade 2 T cnica de Leitura 3 Revis o 4 Indicadores I Instituto Militar de Engenharia II T tulo CDD 625 1 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 Disserta o de Mestrado apresentada ao Curso de Mestrado em Engenharia de Software do Instituto Militar de Engenharia como requisito parcial para a obten o do t tulo de Mestre em Ci ncias da Computa o Orientador Ten Cel Ulf Bergmann D C Co orientador Jos Ant nio Moreira Xex o D C Aprovada em 06 de agosto de 2004 pela seguinte Banca Examinadora Ulf Bergmann D C do IME Presidente Jos Ant nio Moreira Xex o D C do IME Soeli Teresinha Fiorini D C da e D
111. ados Historico o gt extrairAcompanhamento in numAcomp octet idl Acompanhamento extrairAcompD adosHist DadosHistorico extrairAlarmeColisao Acompanhamento interface type lextra o x interface type A interface type xinterface type IplatMgt CalculaPosEst AlarmeColisao Componente Calcula Posi o Estimada comp esp noe CalculaPosEst A interface type IcalculaPos Est calcula in dadosHistorico DadosHistorico in dadosPlataforma Vetor DadosHistorico by interface type Iconversao 183 Componente Alarme de Colis o comp esp AlarmeColisao event alarme in numAcomp octet idl in pma PMA interface type lalarmeColis o o ComponenteConvers o comp esp Conversao o interface type calcula in segundo long idl grauMinSeg lconyersag ComponenteAtualizaPlataforma comp esp AtualPlat 5 interface type E Tee E IPI atualPlat in numAcomp short idl in posi o Posi o short idl ava ogee eee na oF ESSA Ii us CE Cp eee SO 1 interface type y lt interface type 1 jinterface type IcalculaPosEst IcalculaPMA 1 IcalculaR PS interface type interface type interface type lalarmeColisao IcalculaRV IplatMgt Componente Configura o comp esp i Configura o a type inserir in dadosConf eergura o I po et eta aoe S a Se tet interface
112. ais para adquirir prover desenvolver operar e manter produtos de software Agente respons vel por desenvolver o Processo de Engenharia de Dom nio o engenheiro de dom nio 3 Ger ncia da pr tica de reuso o processo de Ger ncia de Programa de Reuso acrescentado aos processos organizacionais da ISO IEC 12207 Administra o Infra estrutura Melhoria e Treinamento para estabelecer um processo de estrutura de programa de reuso integrado e pessoal que podem ser administrados e melhorados Agente respons vel para executar o Processo de Ger ncia de Programa de Reuso o gerente do programa de reuso 4 Ger ncia de assets este processo especifica um processo que ap ia outro processo como uma parte integrante com um prop sito distinto e contribui ao sucesso e qualidade do projeto de software A ger ncia de asset ap ia outros processos de ciclo de vida como Desenvolvimento Manuten o e Engenharia de Dom nio especificando as atividades necess rias para administrar certifica o de asset classifica o armazenamento recupera o controle de vers o e controle de altera o O Processo de Ger ncia de Asset acrescentado ao conjunto de Processos de Ap io definidos em ISO IEC 12207 ABNT12207 1998 Os processos de ap io como Documenta o Ger ncia de Configura o e Revis o Conjunta s o empregados para assegurar execu o de processos de reuso como Engenharia de Dom nio e Ger ncia de Programa de Reuso Agente res
113. al para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conform idades Ostestes de unidade t m como objetivo verificar a l gica e a implementa o da menor unidade de implementa o Neste checklist quanto mais respostas negativas forem dadas s perguntas mais alto o risco do teste de unidade para alcan ar seu devido prop sito 1 Aspecto Corretude Este aspecto deve verificar a adequa o dos par metros aos atributos dos argumentos e a correta implementa o 1 1 O n mero de entrada de par metros igual ao n mero de argumentos 1 2 Osatributos do par metro s o adequados aos atributos do argumento 3 As unidades do par metro s o iguais s unidades do argumento 4 On mero de argumentos que transmitido para a chamada dos m dulos igual a n mero de par metros Os atributos de argumentos que s o transmitidos para a chamada de m dulos s o iguais aos atributos de par metros O sistema de unidade dos argumentos que s o transmitidos para a chamada de m dulos igual ao sistema de unidades dos par metros O n mero de atributos e a ordem dos argumentos para as fun es embutidas esta corretos Os par metros por refer ncia n o est o associados aos atuais pontos de entrada 1 9 Os argumentos de entrada foram alterados 1 10 As declara es de vari veis globais s o consistentes entre os m dulos 1 11 Restri es s o passadas como argumentos 1
114. alentes de c digo ou pelo n mero de p ginas de documentos 50 As medidas de complexidade de software determinada pela complexidade estrutural e tamanho podem ser usadas para estimar densidade de defeito probabilidade de erro e manutenibilidade J as medidas de coes o e acoplamento determinam o grau de ader ncia e independ ncia de um sistema de componente ou que um componente tem dos outros Estas medidas indicam o custo de integrar o componente e tamb m de sua manutenibilidade JACOBSON et al 1997 Frakes e Terry classificam as m tricas e os modelos de reuso como FRAKESD et al 1996 Modelos de Custo Benef cio de Reuso Modelo de Avalia o da Maturidade M tricas de Quantidade de Reuso Modelo de Fracasso M tricas de Reusabilidade e M trica de Bibliotecas de Reuso Os Modelos de Custo Benef cio de Reuso incluem a an lise econ mica de custo ben fico assim como o custo da qualidade e produtividade O Modelo de Avalia o da Maturidade categoriza programas de reuso pelo quanto organiza o est avan ada na implementa o do reuso sistem tico As M tricas de Quantidade de Reuso s o usadas para avaliar e monitorar um esfor o de melhoria do reuso pelo acompanhamento do percentual de reuso de objetos do ciclo de vida O Modelo de Fracasso usado para identificar reuso e impedimentos de reuso em uma organiza o As M tricas de Reusabilidade indicam a probabilidade que um artefato reutiliz vel As M t
115. ama de Projeto gt SPR A1 T cnicas de Leituras eet T Consultor de Qualidade artefatos Treinamento paraRevis o T cnica SPR A2 Prepara o paraRevis o T cnica SPR A3 daRevisao Relat rio de N o Conf ormidadesdaRev isao Consultor de Qualidade Grupo Revisor Modelo Relat rio Revis o Relat rio de Revis o Consultor de Qualidade q Revisao Grupo Revisor T cnica SPR A4 Lider Grupo Revisor Grupo Autor Expositor Secretario FIG 3 2 1 2 2 1 Diagrama de Constru o do Subprocesso de Revis o SPR Este subprocesso inicia o Planejamento da Revis o SPR A1 quando do recebimento da Manual da Qualidade pelo Comit de Qualidade para obten o dos requisitos e objetivos do projeto com o prop sito de produzir um plano de revis o PGQSP da Revis o cronograma das atividades de revis o e elabora o dos procedimentos das T cnicas de Leitura Vertical TLV e Horizontal TLH adequados aos artefatos a serem inspecionados O Plano de Ger ncia do Projeto tamb m deve ser aderente a este plano e cronograma de revis o importante ressaltar que todos os produtos de qualidade gerados neste subprocesso devem ser incorporados no Manual da Qualidade Portanto o Gerente de Projeto deve obter os dados do plano de revis o e cronograma da revis o para o Plano de Ger ncia do Projeto via Manual da Qualidade O Consultor de Qualidade alocado ao projeto deve
116. amada de categorias baseado no m todo FORM Procedimentos I Leia o documento Necessidades do Cliente e Gloss rio para entender as funcionalidades e caracter sticas desejadas do cliente ENTRADAS Necessidades do Cliente e Gloss rio Modelo Conceitual do Dom nio SA DAS Relat rio de Discrep ncias Para cada funcionalidade e caracter stica desejada em Necessidades do Cliente execute os seguintes passos A Identifique a caracter stica correspondente e em que categoria ela pertence capacidade ambiente de opera o tecnologia de dom nio e t cnica de implementa o B Encontre a caracter stica correspondente e marque a com um asterisco azul no Modelo de Caracter stica 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois uma funcionalidade ou caracter stica desejada n o est presente no Modelo de Caracter sticas 2 Caso encontre verifique se a caracter stica est na camada adequada conforme o m todo FORM e se segue o padr o de representa o do m todo FORM Caso contr rio preencha a Tabela de Discrep ncia pois uma caracter stica est fora do padr o do m todo FORM C Verifique se o nome da caracter stica inerente ao dom nio do problema e se ela est utilizando o n vel adequado de abstra o 1 Baseado no conhecimento fornecido pelo documento Necessidades do Cliente e Gloss rio certifique se pode entender o prop sito desta caracter stica Caso contr rio preencha a Tabela de Discrep nc
117. and Report Virginia Polytechnic Institute and State University 1993 TRAVASSOS G H SHULL F CARVER J BASILI V R Reading techniques for OO design inspections Greenbelt EUA 24 Annual Software Engineering Workshop NASA SEL 1999 Dispon vel http sel gsfc nasa gov website sew 1999 topcs travassosSEW99paper pdf capturado em agosto de 2003 TRAVASSOS G H SHULL F CARVER J BASILI V R Reading techniques for OO design inspections Technical Report 2003 http www cs umd edu library TRs CS TR 4353 CS TR 4353 pdf 56 p VOTTA JR L G 1993 Does every inspection need a meeting Proceedings of the ACM SIGSOFT 1993 Symposium on Foundations of Software Engineering ACM Software Engineering Notes v 18 n 5 Dec 1993 p 107 114 WOHLIN C RUNESON P HOST M OHLSSON M C REGNELL B WESSLEN A Experimentation in software engineering an introduction Dordrecht Kluwer Academic Publishers Nov 1999 224 p WIEGERS K E Improving quality through software inspections Software Development April 1995 p 55 64 ZAHRAN S Software process improvement practical guidelines for business success 1 Edition Addison Wesley Feb 1998 480 p ISBN 02 01177 82 X 123 7 AP NDICES 7 1 AP NDICE 1 ESTUDO SOBRE OS TIPOS DE REUSO O reuso pode ser classificado em termos de Escopo de desenvolvimento refere se se os componentes reus veis s o de fonte externa p blico ou interna privado
118. ando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 1 Aspecto Estrutura Este aspecto deve verificar a estrutura do diagrama arquitetural do dominio 1 1 Aarquitetura permite implementa o de todas as necessidades funcionalidades e caracter sticas desejadas 1 2 A arquitetura foi deoomposta adequadamente 1 3 As fun es da aplica o foram alocadas adequadamente aos componentes 1 4 Aarquitetura prov uma base adequada para fase seguinte do projeto 1 5 Aarquitetura poss vel de ser implementada 1 6 O conjunto de programa pode ser integrado e testado incrementalmente s Total de itens do aspecto verificados Total de n o conformidades 2 Aspecto Corretude e Qualidade Este aspecto deve descrever a qualidade que as necessidades funcionalidades e caracter sticas desejadas devem apresentar no diagarmae a adequa o a estas necessidades P cil Aarquitetura evita redundanda desnecess ria Todas as caracteristicas desejadas de desempenho foram aplicadas Todas as considera es de seguran a foram aplicadas A arquitetura considera todas as restri es Toda a estrutura de dados necess ria esta definida A arquitetura proposta vai satisfazer todos os atributos de qualidade especificados e os objetivos de desempenho s Total de itens do as
119. anz life assurance In 2 International Software Quality Week Europe Brussels Belgium 1998 p 1 23 Disponivel http www visek de servlet is 2228 capturado em junho de 2003 BROHL A P DROSCHEL W Das V modell der standard fiir die softwareentwicklung mit praxizleitfader Oldenbourg 1995 656 p CHENG B JEFFREY R Comparing inspection strategies for software requirements specifications Proceedings of the 1996 Australian Software Engineering Conference 1996 p 203 211 CHEESMAN J DANIELS J UML Components a simple process for specifying component based software Boston Addison Wesley 2000 176 p CHERNAK Y A statistical approach to the inspection checklist formal synthesis and improvement IEEE Transactions on Software Engineering v 22 n 12 1996 p 866 874 CHIDAMBER S R KEMERER C F A metrics suite for object oriented design IEEE Transactions on Software Engineering v 20 n 6 June 1994 p 476 493 116 CROSBY P B Quality is still free making quality certain in uncertain times Mc Graw Hill 1996 264 p DAVIS T The Reuse Capability Model A Basis for Improving an Organization s Reuse Capability IEEE Transactions on Software Engineering v 20 n 6 1993 p 476 493 DEMING W E Quality productivity and competitive position Center for Advanced Engineering Study Massachusetts Institute of Technology Cambridge MA 1982 DEMING W E Qualidade a revolu o da administr
120. ao desenvolvimento de um padr o por medida de qualidade de produto de software a norma ISO IEC 9126 No AP NDICE 3 apresentada uma tabela resumida TAB 7 3 1 1 dos atributos de qualidade do produto da Norma ISO IEC 9126 ISO9126 2000 Bansiya e Davis relatam que todos os modelos de qualidade baseado em produto variam na defini o hier rquica de qualidade mas compartilham as seguintes dificuldades BANSIYA et al 2002 Os modelos s o vagos nas suas defini es e nas m tricas necess rias para atingir uma avalia o quantitativa de qualidade de produto Falta de um estudo mais detalhado para considerar a depend ncia entre atributos de qualidade pois os atributos nem sempre s o independentes entre si 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 possibilidade de alcan ar um objetivo de baixa manutenibilidade Os modelos n o incluem como considerar o grau de influ ncia dos atributos individualmente pois ao avaliar a qualidade do produto como um agregado de um conjunto de atributos de qualidade o significado de todos os atributos para a qualidade do produto n o pode ser igual e ent o a influ ncia de um atributo pode precisar ser mudada por um fator de peso Por exemplo para organiza es com redes sofisticadas e processamento em tempo real os atributos de desempenho e de confiabilidad
121. aplica o e a tecnologia adotada para constru o dos artefatos reutiliz veis 1 2 OBJETIVO O objetivo deste trabalho propor um processo de garantia de qualidade aplicado ao Processo de Desenvolvimento de Software baseado em Reuso no Minist rio da Defesa MD e de seus Comandos Subordinados proposto por GURGEL 2004 Este trabalho deve fornecer subs dios para os rg os Descentralizados de Fornecimento de Software promoverem o aumento da produtividade e a melhora da qualidade de seu processo de desenvolvimento de artefatos reus veis assets Al m disso deve possibilitar um acompanhamento eficaz de projetos de desenvolvimento de software com base em reuso para assegurar melhor planejamento e controle de projetos Processos de software s o mapas ou frameworks para desenvolver aplica es de software IEEE 1517 1999 gt Estrutura de organiza o proposta por GURGEL 2004 veja ANEXO 1 22 Para tal foram estudados os processos de garantia de qualidade de software existentes na literatura e as particularidades existentes no desenvolvimento baseado em reuso A defini o do processo foi apoiada pela condu o de um estudo de caso que permitiu avaliar a viabilidade de sua aplica o no contexto da proposta de GURGEL 2004 para MD 1 3 VIS O GERAL DO PROCESSO PROPOSTO Para que o reuso de artefatos esteja presente em todo ciclo de vida do sistema proporcionando economia de tempo e recurso redu o no retrabalho e
122. ar abstra es e desenvolver artefatos reutiliz v is com grande potencial de aplica o para uma fam lia de projetos que residem no mesmo dom nio Em geral estes artefatos s o reutilizados em futuros projetos como as is ou podem ser especializados 14 Generaliza o durante o projeto 53 Baseado no Processo de Apoio da Norma 12207 ABNT12207 1998 e no N vel 3 Definido do Modelo CMM o processo proposto consiste em prover o gerenciamento com a adequada visibilidade do processo que est sendo utilizado pelo projeto de desenvolvimento de software e dos artefatos que est o sendo constru dos Este processo inspeciona os produtos de software e atividades para verificar se est o cumprindo os procedimentos e padr es aplic veis O objetivo fornecer os resultados dessas revis es ao Gerente de Reuso e equipe de desenvolvimento montadores Al m disso com o objetivo de desenvolver e sustentar uma capacidade de medi o usada para suportar gerencialmente as necessidades de informa o no processo proposto definido um subprocesso de Medi o e Avalia o SPM baseado na rea de processo de Medi o e An lise do Nivel 2 Gerenciado do modelo CMMI SEI 2002 Esta rea envolve os seguintes aspectos Especifica o dos objetivos de medi o e an lise de forma que estes sejam alinhados com os objetivos e as necessidades de informa o identificadas Especifica o das medidas mecanismos de coleta de dados e
123. ar e integrar uma ferramenta de teste metodologia de desenvolvimento Seo sistema muda rapidamente a cada itera o do ciclo espiral de teste mais tempo ser despendido em manter a ferramenta de teste de regress o Portanto a sele o da ferramenta de teste mais adequada para o ambiente de desenvolvimento um fator cr tico para o sucesso das atividades de teste Ela deve ser empregada quando o processo manual inadequado como por exemplo uma ferramenta de teste de carga pode simular v rios usu rios virtuais em condi es controladas de estresse 31 Para apoiar a sele o de uma ferramenta de teste j que n o uma tarefa simples Lewis aborda algumas quest es por meio de um checklist em LEWIS 2000 2 1 2 INSPE ES DE SOFTWARE Embora a aplica o de testes para o controle da qualidade do software seja importante o uso exclusivo de testes pouco produtivo Mesmo sendo indispens vel realizar testes bem feitos a qualidade do software n o melhora com o aumento do investimento em testes LEWIS 2000 LAITENBERGER 2002 relata que a introdu o de inspe o de c digo reduz 39 dos custos com defeito em rela o realiza o de testes e a inser o de inspe o de projeto reduz 44 dos custos com defeito comparados aos testes Assim os artefatos devem sofrer inspe es ao longo do processo de desenvolvimento de software para garantir a qualidade interna dos artefatos produzidos Os objetivos das ins
124. ar estes assets Esta norma descreve processos de reuso como definido pela arquitetura de Basili BASILI et al 1992 para abstra o de processo Nesta arquitetura a responsabilidade por 136 cada processo atribu da a agente O agente o indiv duo ou organiza o respons vel para executar um processo ou atividade Entretanto esta norma limitada a Descrever um framework de alto n vel para processos de reuso mas n o os detalhes de como executar as atividades e tarefas inclu das nos processos Descrever as responsabilidades inerentes a v rios processos mas n o os dados detalhados ou rela es de controle entre os processos Especificar os processos de reuso do ciclo de vida de software mas n o prescreve um modelo espec fico de processo de ciclo de vida de software ou metodologia de software Visualizar processos de reuso como uma tarefa de atribuir responsabilidades a agentes mas n o como umas s ries de passos procedimentos para ser executado Especificar provis es para adquirirem assets mas n o provis es para integra o de assets comerciais off the shelf COTS que n o s o fornecidos em forma de c digo fonte Neste padr o como em ISO IEC 12207 0 1996 ABNT12207 1998 h um n mero de listas para as tarefas nenhuma delas exaustiva Cada processo de ciclo de vida dividido em um conjunto de atividades e os requisitos de cada atividade s o especificados em um conjunto de tarefas
125. ar no processo de medi o 7 Treinar os profissionais envolvidos no processo de medi o 8 Conscientizar motivar e treinar gerentes e equipes de projetos 9 Estabelecer uma refer ncia para medi o inicial 10 Estabelecer o processo de medi o 11 Integrar com ciclo de vida e processos de ger ncia 12 Monitorar e modificar o processo de medi o se necess rio Jones classifica as informa es de um processo de medi o em tr s tipos JONES 1997 hard quantificadas com pouco ou nenhuma subjetividade possuindo alto grau de precis o soft avaliadas subjetivamente possuindo baixo grau de precis o devido varia o de opini o e comportamento comum entre pessoas e de padroniza o relativas as medi es padr es usadas por prop sitos corporativos para determinar a posi o dos projetos em rela o aos padr es definidos como meta pela organiza o em termos de produtividade ou qualidade De acordo com a finalidade de uso as medi es de software podem ser estrat gicas ou t ticas As medi es estrat gicas s o aquelas que englobam fatores que influenciam diretamente no sucesso da corpora o enquanto que as t ticas influenciam nos resultados dos projetos Jones ainda relata que um programa completo de medi es deve incluir os dois tipos de medi es JONES 1997 41 2 1 3 1 MEDI ES T TICAS E HARD PARA PROJETOS 00 Os conceitos b sicos de OO encapsulamento heran a e polimorfismo
126. ara um n vel de mensagens devem se abstrair v rias mensagens juntas para entender que servi os elas est o fornecendo em conjunto Anote no diagrama de segii ncia descrevendo estes servi os e realce os de verde C Circule de amarelo quaisquer restri es nas mensagens e servi os tais como restri es no n mero de classes objetos que uma mensagem poderia enviar restri es nos valores globais de um atributo depend ncias entre dados ou restri es de tempo que podem afetar o estado de um objeto Tamb m circule de amarelo quaisquer condi es que determinam sob que circunst ncias uma mensagem pode ser enviada II Identifique e inspecione os diagramas de classes Interfaces da Camada de Neg cio e de Aplica o relacionados para identificar se os objetos correspondentes est o precisamente descritos ENTRADAS Interfaces da Camada de Neg cio Interfaces da Camada de Aplica o Diagrama de Intera es com objetos servi os e restri es marcados SA DAS Relat rio de Discrep ncias A Verifique que todo objeto classe e ator usado no diagrama de segii ncia est o representados por uma classe concreta nos diagramas de classes Para as classes e atores encontre o nome nos diagramas de classes Para os objetos encontre a nome da classe da qual o objeto foi instanciado Verifique as seguintes discrep ncias e caso encontre as preencha a Tabela de Discrep ncia 1 Se uma classe ou objeto n o pode ser encontrada nos diagram
127. artes a serem modificadas 5 2 Modificabilidade Evidencia o esfor o necess rio para modific lo remover seus defeitos ou adapt lo a mudan as ambientais 5 3 Estabilidade Evidencia o risco de efeitos inesperados ocasionados por modifica es 5 4 Testabilidade Evidencia o esfor o necess rio para validar o software modificado 5 5 Conformidade 6 Portabilidade Evidencia o quanto o software est de acordo com as normas ou conven es relacionadas manutenibilidade da aplica o Conjunto de atributos que evidenciam a facilidade do software ser transferido de um ambiente para outro O ambiente pode incluir o ambiente organizacional de hardware ou de software 6 1 Adaptabilidade Evidencia sua capacidade de ser adaptado a diferentes ambientes especificados sem a necessidade de aplica o de outras a es ou meios al m daqueles fornecidos para essa finalidade pelo software considerado 6 2 Capacidade para Evidencia o esfor o necess rio para sua instala o em um ambiente ser instalado especificado 6 3 Capacidade de Evidencia sua capacidade de co existir com outros softwares independentes em coexistir um ambiente comum compartilhando os mesmos recursos 6 4 Capacidade para Evidencia o esfor o necess rio de utiliza o do software desenvolvido no lugar substituir de outro software e no ambiente estabelecido para esse outro software espec fico
128. as de classes isto significa que a informa o est inconsistente entre os diagramas de classes e o diagrama de seqii ncia est presente em um e ausente em outro 2 Se um ator n o pode ser encontrado determine se o ator precisa ser apresentado como uma classe para executar algum comportamento necess rio Se sim ent o informa o que est presente no diagrama de seqii ncia est faltando nos diagramas de classes B Verifique se para todo servi o ou mensagem marcado em verde no diagrama de sequ ncia existe um comportamento correspondente no diagrama de classes Verifique se existem comportamentos de classes nos diagramas de classes que encapsulam os servi os de mais alto n vel fornecidos pelo diagrama de seqii ncia Ou seja esteja certo que a classe ou objeto que recebe a mensagem no diagrama de segii ncia ou que deveria ser respons vel pelo servi o possui um comportamento associado nos diagramas de classes Tamb m esteja certo que existe algum tipo de associa o nos diagramas de classes entre as classes que a mensagem conecta no diagrama de segii ncia Lembre que em ambos os casos pode se precisar procurar na rvore de heran a a que classe pertence para encontrar as caracter sticas necess rias Restrito Instituto Militar de Engenharia P gina 1 2 160 Garantia da Qualidade de Software Leitura Horizontal 5 Vers o 1 2 RELHS501 03 Data da vers o 03 03 2004 A Encontre o componente correspondente na
129. as e datas types inerentes modelagem do neg cio representada pelo Modelo Tipo do Neg cio Entrada para o processo 1 Modelo Tipo do Neg cio representado pelo diagrama de classes 2 Interface da Camada de Neg cio representado pelo diagrama de classes Procedimentos I Analise o Modelo Tipo do Neg cio para entender as classes de neg cio e seus relacionamentos ENTRADAS Modelo Tipo do Neg cio Interface da Camada de Neg cio SA DAS Relat rio de Discrep ncias Para cada classe do diagrama do Modelo Tipo do Neg cio execute os seguintes passos A Encontre a classe de neg cio correspondente na Interface da Camada de Neg cio e marque com um asterisco azul esta classe 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois uma classe de neg cio n o est presente na Interface da Camada de Neg cio 2 Certifique que o nome da classe de neg cio o mesmo utilizado na classe correspondente da Interface da Camada de Neg cio Caso n o tenha o mesmo nome preencha a Tabela de Discrep ncia pois pode haver ambigiiidade relatando a necessidade de conhecimento adicional para compreens o 3 Certifique que o estere tipo da classe esteja referenciado corretamente como core Caso contr rio preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsist ncia entre os dois B Verifique se no Modelo Tipo do Neg cio especifica algum mecanismo de h
130. bilizar os m todos que podem ter comportamento polimorfo 11 Tamanho do Projeto uma medida do n mero de classes usadas em um projeto Tamanho do Projeto em Classes esta m trica consiste em contabilizar o n mero total de classes no projeto 8 az a Hai a Be E 3 3 S o conceitos quantific veis que podem ser avaliados diretamente ao examinar a estrutura interna e externa relacionamento e funcionalidade dos componentes de projeto atributos m todos e classes 43 Baseado nas propriedades de projeto TAB 2 1 3 1 2 para os atributos de qualidade TAB 2 1 3 1 1 Bansiya e Davis elaboram as fun es de medi o para estes atributos TAB 2 1 3 1 3 Os ndices das parcelas das fun es de medi o apresentadas na TAB 2 1 3 1 3 revelam a influencia positiva ou negativa relativa s propriedades de projeto nos atributos de qualidade de forma que os valores calculados de todos os atributos de qualidade tenham a mesma abrang ncia de O a 1 BANSIYA et al 2002 TAB 2 1 3 1 3 Parcelas das fun es de medi o de BANSIYA et al 2002 ndices das Parcelas das Fun es de Medi o dos Atributos de Qualidade Atributos de Qualidade Abstra o Acoplamento Complexidade Composi o Encapsulamento Hierarquia Mensagem Polimorfismo Tamanho do Projeto o w 2 w o o w o Compreensibilidade Efetividade Extensibilidade Flexibilidade Funcionalidade
131. cas de processo produtividade do trabalhador efic cia em termos de tempo custo de produ o taxa de defeitos detectados volume de mudan as de uma vers o para outra M tricas de biblioteca ou reposit rio frequ ncia de acesso tamanho do reposit rio custo de certifica o qualidade e quantidade de componentes M tricas de arquitetura estabilidade M tricas do artefato tamanho do componente complexidade da interface coes o do sistema de componente e interface n vel de usabilidade do componente e interface qualidade custo dos sistemas padr es de componente dificuldades em integrar componentes M tricas da aplica o volume de reuso qualidade volume de defeitos e suas causas perfil da falta A quantidade de reuso est relacionada com o volume de reuso ou taxa de reuso JACOBSON et al 1997 A taxa de reuso definida como a raz o da soma dos tamanhos dos artefatos reutilizados dividido pelo tamanho total da aplica o A taxa de reuso usada para monitorar o reuso e tamb m para estimar como o reuso vai incidir nas medidas de qualidade tempo e custo Algumas organiza es medem o tamanho do software utilizando os m todos recomendados pela SEI PARK 1992 LOC linhas de c digo Outras utilizam a t cnica de An lise por Ponto de Fun o APF IFPUG 2000 ou An lise por Pontos de Caso de Uso KARNER 1993 O tamanho dos artefatos n o c digos podem ser medidos em termos de linhas equiv
132. cia entre as equipes de desenvolvimento e engenheiros de dom nio O Grupo de M tricas deve fornecer os resultados da an lise ao Comit de Qualidade para divulga o dos resultados s ger ncias do rg o Descentralizado de Fornecimento de Software e ao Grupo de GQS Corporativo Este ltimo deve analisar os pontos fortes e fracos dos processos empregados Estas avalia es devem ser utilizadas para recomendar altera es nas diretrizes dos futuros projetos e para determinar avan os tecnol gicos As cinco atividades do Subprocesso de Medi o e Avalia o s o detalhadas a abaixo SPM A1 AN LISE DE REQUISITOS A atividade An lise de Requisitos deve descrever as especifica es dos requisitos de qualidade e reusabilidade definindo os objetivos da avalia o de acordo do ponto de vista dos diferentes usu rios do produto Os requisitos a serem avaliados devem estar em conformidade com a norma ISO 9126 1 2000 e devem atender as necessidades expl citas e impl citas do usu rio SPM A2 ESPECIFICA O DA AVALIA O A atividade Especifica o da Avalia o estabelece o escopo da avalia o as medi es a serem realizadas no produto artefato a defini o do n vel de pontua o e do crit rio de avalia o os m todos utilizados e as responsabilidades de todos envolvidos no processo de 78 avalia o Esta atividade deve procurar selecionar os objetivos que facilmente podem prover medidas mais do tipo hard menos subj
133. cia entre os artefatos de projeto e os requisitos do sistema TRAVASSOS et al 2003 A vantagem em utilizar esta t cnica est na sele o de apenas um subconjunto de t cnicas correspondentes aos artefatos que devem ser inspecionados ou que s o importantes em um determinado momento no processo de desenvolvimento de projeto OO ROCHA et al 2001 2 1 3 PROGRAMA DE MEDI O DE SOFTWARE A implanta o de um processo de medi o de software visa fornecer ao Gerente de Reuso um conjunto de dados teis para planejar e controlar os projetos de software com rigor e precis o PRESSMAN 2001 Para isto necess ria a motiva o de todos os profissionais que atuam no processo de desenvolvimento de software Tamb m necess rio que a ger ncia de reuso estabele a um programa de medi o corretamente planejado e implementado para avaliar o progresso do programa de qualidade e de reuso como tamb m assegurar que os objetivos de qualidade e de reusabilidade est o sendo cumpridos IEEE1517 1999 O Gerente de Reuso deve determinar os atributos de qualidade apropriados para a avalia o do projeto de forma a este atingir seus objetivos Al m disso os dados obtidos da avalia o devem ser armazenados de forma consistente para sua utiliza o em projetos futuros JACOBSON et al 1997 IEEE 1517 1999 O processo de coleta de dados deve ser simples e ferramentas autom ticas para extra o destes dados devem ser utilizadas j que a q
134. cio SAIDAS Relat rio de Discrep ncias Para cada cen rio da Descri o dos Cen rios dos Casos de Uso do Dom nio execute os seguintes passos A Leia atentamente os cursos normal e alternativos para identificar os dados a serem armazenados Sublinhe em azul os dados provenientes da intera o e de verde os dados calculados pelo sistema B Encontre a s classe s correspondentes no Modelo Tipo de Neg cio e marque com asterisco azul Verifique para cada dado sublinhado em verde se tem atributo correspondente nesta s classe s e sublinhe em verde o atributo correspondente 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois ocorre aus ncia de atributo s na s classe s correspondente s do Modelo Tipo do Neg cio 2 Certifique que cada atributo tenha o mesmo nome do dado correspondente na Descri o do Cen rio e seu tipo b sico definido Caso contr rio preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsistente entre os dois Restrito Instituto Militar de Engenharia P gina 1 2 164 Garantia da Qualidade de Software Leitura Vertical 3 Vers o 1 2 RELV301 03 Data da vers o 03 03 2004 A Encontre a s classe s correspondentes no Modelo Tipo de Neg cio Verifique para cada dado sublinhado em azul se tem atributo correspondente nesta s classe s e sublinhe em azul o atributo correspondente 1 Caso n o consiga encontrar certif
135. cionamentos para ter certeza que todo o conjunto de classe e seus relacionamentos aparecem na descri o textual do Modelo de Contexto do Dom nio 1 Certifique que n o exista nenhuma classe sem asterisco e relacionamento sem estar real ado em amarelo Caso exista algum preencha a Tabela de Discrep ncia pois uma classe ou relacionamento no Modelo Conceitual do Dom nio n o est presente no Modelo de Contexto do Dom nio Restrito Instituto Militar de Engenharia P gina 2 2 153 Garantia da Qualidade de Software Leitura Horizontal 2 Vers o 1 2 RELH201 03 Data da vers o 03 03 2004 TLH 2 Modelo Conceitual do Dom nio X Modelo de Casos de Uso do Dominio e Cen rios Objetivo Verificar se um modelo de intera o de usu rio com o sistema Modelo de Casos de Uso juntamente com a descri o dos cen rios projetam todas as necessidades do sistema em termos de intera es que devem ocorrer atrav s dos limites do sistema Pr requisito Nenhum Entrada para o processo 1 Modelo Conceitual do Dom nio representado pelo diagrama de classes 2 Modelo de Casos de Uso do Dom nio 3 Descri o dos Cen rios dos Casos de Uso do Dom nio Procedimentos I Analise o Modelo Conceitual do Dom nio para entender as classes conceituais e seus relacionamentos ENTRADAS Modelo Conceitual do Dom nio Modelo de Casos de Uso do Dom nio Descri o dos Cen rios dos Casos de Uso do Dom nio SA DAS Relat rio de Discrep ncia
136. consiga encontrar preencha a Tabela de Discrep ncia pois uma classe de sistema n o est presente na especifica o da Interface da Camada da Aplica o 2 Certifique que o nome da classe de interface do sistema inicia pela vogal em mai scula I concatenado com o nome do caso de uso quando poss vel Caso n o tenha o padr o preencha a Tabela de Discrep ncia pois pode haver falta de padr o ou ambigiiidade relatando a necessidade de conhecimento adicional para compreens o 3 Certifique que o estere tipo da classe esteja referenciado corretamente como interface Caso contr rio preencha a Tabela de Discrep ncia pois pode haver falta de padr o ou ambigiiidade relatando a necessidade de conhecimento adicional para compreens o III Compare as Descri es dos Cen rios do Dominio s assinaturas das interfaces do sistema correspondente para verificar se os servi os das interfaces foram capturados adequadamente com os dados necess rios de entrada e sa da ENTRADAS Descri o dos Cen rios dos Casos de Uso do Dom nio sublinhado em verde Interface da Camada da Aplica o SA DAS Relat rio de Discrep ncias Para cada descri o de caso de uso do Modelo de Casos de Uso do Dom nio execute os seguintes passos A Encontre a classe de interface correspondente na especifica o da Interface da Camada da Aplica o B Para cada descri o de a o sublinhada em verde na descri o do cen rio tente encontrar u
137. contexto das opera es atuais da janela 16 Cada fun o do menu executada conforme a especifica o 17 Asopera es com mouse s o corretamente reconhecidas pelas intera es 18 Se varias sele es s o requeridas elas s o corretamente reconhecidas 19 Se o mouse tiver v rios bot es eles s o corretamente reconhecidos 1 200 cursor muda corretamente quando outra opera o for requerida 1 21 Os dados de entrada alfanum ricos s o corretamente introduzidos no sistema e apresentados s 1 22 Todas as fun es relacionadas janela est o disponibilizadas quando necess rias s Total de itens do aspecto verificados Total de n o conformidades Restrito Instituto Militar de Engenharia P gina 1 4 149 Garantia da Qualdade de Software ChecKHist Teste de Interface Gre fica Vers o 1 2 VETG001 03 Data da vers o 01 03 2004 Checklist Teste de Interface Grafica Artefato Verificado CTTG 001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos oserros detectados devem ser identificados e comentados na parte de N
138. da Marinha para aplica o do processo de desenvolvimento de software baseado em reuso de GURGEL 2004 e do processo de Garantia da Qualidade de Software proposto neta disserta o com o objetivo de criar artefatos reutiliz veis no dom nio de controle t tico de plataformas e tamb m de 87 assegurar a qualidade destes artefatos de forma que estes possam ser efetivamente reutiliz veis pelos montadores Este projeto piloto adequado por ser t pico ao contexto das Tr s For as Armadas Marinha Ex rcito e Aeron utica e tamb m por ser adequado ao reuso A reusabilidade deste projeto relatada em GURGEL 2004 devido estabilidade do dom nio e grande aplicabilidade nas mais diversas plataformas das Tr s For as N s nos apoiamos nos produtos de software de BRAGA et al 1999 CHEESMAN et al 2000 para gerar os artefatos dos processos de Engenharia de Dom nio e Desenvolvimento do Controlador T tico que s o os artefatos de entrada para o processo proposto por esta disserta o Ficou estabelecido que todas as fases dos processos de Engenharia de Dom nio e de Desenvolvimento da proposta de GURGEL 2004 seriam realizadas de forma a definir primeiramente todos os modelos e diagramas do projeto piloto necess rios por cada atividade e posteriormente realizaria os artefatos de qualidade adequados a estes modelos e diagramas Esta decis o foi tomada por dois motivos aproxima o do t rmino do tempo para o estudo de caso
139. da vers o 03 03 2004 TLV 5 Modelo de Caracter sticas X Arquitetura do Dominio Objetivo Verificar a generalidade arquitetural de dom nio baseado em camadas para facilitar o re so com o expl cito prop sito de atender ao maior n mero de sele es identificadas no Modelo de Caracter sticas Pr requisito Esta leitura requer que o diagrama do Modelo de Caracter sticas tenha sido aprovado pelo Processo Controle de Qualidade Entrada para o processo 1 Modelo de Caracter sticas baseado no m todo FORM representado pelo diagrama de caracter sticas em camada de categorias 2 Arquitetura do Dom nio representado pelo diagrama de classes em camada Procedimentos I Leia as caracter sticas de cada categoria do Modelo de Caracter sticas para verificar se a estrutura arquitetural do dom nio atende ao maior n mero de possibilidades de sele o Il Leia os componentes de cada camada da Arquitetura de Dom nio para identificar o padr o arquitetural definido e os padr es utilizados ENTRADAS Modelo de Caracter sticas Arquitetura de Dom nio SA DAS Relat rio de Discrep ncias Para cada possibilidade de sele o de caracter stica do Modelo de Caracter stica execute os seguintes passos A Identifique a camada arquitetural de dom nio adequada e encontre a s classe s correspondente s no diagrama de classes da Arquitetura de Dom nio Utilize dicas sint ticas o nome da caracter stica seja similar ao nome da classe para ajuda
140. dades do Cliente e Gloss rio Hist rico de Revis es do Checklist para Necessidades do Cliente e Gloss rio BE ca Ea eed e por Eles RS Elabora o do checklist com os aspectos ELE YNA e quest es eoa ee checklist 1 2 Planilha para suporte KLEYNA 1 3 Inser o de espa o para coment rio e ELEY NA identifica o de cada defeito detectado ell i 6 12 2003 9 12 2003 23 12 2003 1 Altera o das colunas de respostas verso ELEY NA do checkiist e an lise da verifica o Coment rios sobre as vers es FIG 4 2 2 1 1 c Hist rico de Vers es do checklist para Necessidades do Cliente e Gloss rio Checklist Necessidades do Cliente e Gloss rio Artefato Verificado CTNC001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecer a resposta adequada 5 Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 1 Aspecto Apresenta o do Documento Este aspecto deve analisar as quest es gerais de apresenta o do documento P C 1 1 1 O documento est de acordo com o template padr o
141. dar cada fun o do software Os sripts de teste foram desenvolvidos para validar todas as estruturas de dados Os sripts de teste foram desenvolvidos para avaliar o desempenho do software Os sripts de teste foram desenvolvidos para testar o comportamento do software Os sripts de teste foram desenvolvidos para exercitar completamente a interface do usu rio Os sripts de teste foram desenvolvidos para verificar to do o erro controlado Oscasos de uso disponibilizados s o para realizar cen rios de teste Testes estat sticos s o utilizado s como um elemento de valida o Foram desenvolvidos testes para verificar os procedimentos definidos no Manual do Usu rio e no Manual de Instala o do softw are Existem mecanismos de registro e de corre o dos erros verificados Uma rela o de erros detectados foi produzida voava U 1 2 3 4 5 6 7 8 9 Total de itens do aspecto verificados Total de n o conformidades Restrito Instituto Militar de Engenharia P gina 1 2 151 7 4 2 ARTEFATOS T CNICAS DE LEITURA HORIZONTAL Garantia da Qualidade de Software Leitura Horizontal 1 Vers o 1 2 RELH1 01 03 Data da vers o 03 03 2004 TLH 1 Modelo de Contexto do Dom nio X Modelo Conceitual do Dom nio Objetivo Verificar se um modelo conceitual de dom nio representado por um diagrama de classes da UML captura todos os conceitos e identifica todos os relacionamentos especificados no Modelo de Contexto do Dom nio man
142. de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o 2 Certifique que o nome da classe inicie sempre por letra mai scula Caso contr rio preencha a Tabela de Discrep ncia pois o nome da classe est fora do padr o C Verifique se todos os poss veis atributos explicitamente descritos nas funcionalidades estejam descritos na classe 1 Certifique que o mesmo conjunto de atributos esteja presente em ambos os documentos Caso contr rio preencha a Tabela de Discrep ncia pois informa o est presente em um documento mas ausente no outro 2 Certifique que os nomes dos atributos nas classes iniciem sempre por letra min scula Caso contr rio preencha a Tabela de Discrep ncia pois o nome da classe est fora do padr o D Verifique se existi associa o da classe que represente a funcionalidade ou restri o considerada Realce em amarelo a associa o correspondente 1 Certifique que o mesmo conjunto de associa o e restri es esteja presente em ambos documentos Caso contr rio h informa o em um documento que n o est presente em outro ou h inconsistente entre os dois E Seo diagrama de classe do modelo conceitual de dom nio especifica algum mecanismo de heran a para esta classe verifique se eles est o corretamente descritos 1 Certifique que o relacionamento de heran a esteja inclu do na descri o do Modelo de Contexto do Dom nio Caso contr rio preencha a Tabela de Di
143. de reuso baseado de como um processo pode falhar Os modos de fracasso s o nenhuma tentativa para reuso parte inexistente parte indisponivel parte n o encontrada parte n o entendida parte inv lida e parte n o pode ser integrada Avalia o da reusabilidade Medi o de reusabilidade para Ada Basili Rombach Bailey Delis BASILI et al 1990 Dois estudos focalizam reuso para sistemas Ada O primeiro mede liga es de dados para caracterizar e identificar componentes reus veis O segundo define uma medi o abstrata de reusabilidade de componente de software por identificar software reus vel e medir a dist ncia daquele ideal Predi es de reuso para objetos do ciclo de vida Frakes Fox FRAKES et al Modelos permitem a predi o de n veis de reuso para um objeto do ciclo de vida baseado em n veis de reuso para outros objetos do ciclo de vida M tricas de bibliotecas de reuso Indexa o de custo busca pela efetividade e efici ncia Frakes Pole FRAKES et al 1994 Indexar custos inclui o custo de criar manter e atualizar o esquema de classifica o de asset Para encontrar medidas de efetividade incluem revoga o precis o sobreposi o e entendimento Para encontrar medidas de efici ncia incluem utiliza o overhead de indexa o e tempo de recupera o M tricas de qualidade de asset Frakes Nejmeh FRAKES et al 1987 Indicadores da qualidade dos
144. de reuso e reuso baseado em partes A t cnica de gerador requer que um dom nio de conhecimento seja Dispon vel gratuitamente no site do PSM www psmsc com 45 codificado em um gerador de aplica o ou uma linguagem de programa o para que os componentes sejam selecionados e integrados automaticamente O reuso baseado em partes conhecido tamb m como reuso de componentes requer que um programador humano integre componentes de software em uma aplica o Para atender o objetivo deste trabalho o reuso de software abordado o baseado em partes de acordo com um processo bem definido e repet vel reuso sistem tico de assets A abordagem de reuso baseado em partes mais abrangente do que o gerador IEEE1517 1999 pois os artefatos ao serem constru dos como assets aumentam a reusabilidade O reuso de software pode ser aplicado a qualquer produto do ciclo de vida e n o apenas a fragmentos de c digo fonte Desta forma a equipe de desenvolvimento pode procurar reuso de documentos de requisitos especifica es de sistemas estruturas de projetos e qualquer outro artefato BARNES et al 1991 O fato de estar reutilizando artefatos tem todos os benef cios conhecidos da tecnologia de reutiliza o sendo poss vel fazer uso do conhecimento e da experi ncia adquiridos em processos de projetos da empresa ou estabelecidos por outras organiza es ou pesquisadores FIORINI et al 2000 HENNINGER 1999 RISING 1999 Entretan
145. de software de outros artefatos n o c digo fonte BASILI et al 1996 FUSARO 1997 PORTER et al 1995 ZAHRAN 1998 As principais t cnicas de leituras e suas caracter sticas s o apresentadas em LAITENBERGER 2002 Na TAB 2 1 2 2 1 s o apresentadas as duas t cnicas de inspe o 34 mais utilizadas na ind stria ad hoc e checklist e duas variantes da t cnica de leitura baseada em cen rio em atual difus o Leitura baseada em Defeito e em Perspectiva TAB 2 1 2 2 1 T cnicas de inspe o de software e suas caracter sticas Caracter sticas T cnicas Contexto Usabilidade Repetibilidade Adaptabilidade Necessidade da de aplica o treinamento de Leitura Valida o Ad Hoc Todos os N o N o N o N o Pr tica produtos industrial Checklist Todos os N o N o i Depende N o Pr tica produtos do caso industrial Leitura Todos os i Depende do i Alto i Valida o baseada em produtos caso experimental Defeito Leitura Todos os i Sim i Alto i Valida o baseada em produtos experimental e Perspectiva iniciado uso industrial O m todo ad hoc uma t cnica n o sistem tica onde todos os revisores desempenham as mesmas tarefas utilizando seus pr prios conhecimentos O m todo checklist similar ao m todo ad hoc mas uma lista de defeitos fornecida J no m todo cen rio os revisores t m responsabilidades fragmentadas e coordenadas LAITENBERGER 2002
146. do a necessidade de conhecimento adicional para compreens o Reveja na Arquitetura de Dom nio cada componente para ter certeza que todas as suas depend ncias aparecem 1 Certifique que n o existe nenhuma intera o sem estar real ada em amarelo Caso exista alguma preencha a Tabela de Discrep ncia pois uma depend ncia n o deveria ser definida desta maneira relatando a necessidade de conhecimento adicional para compreens o Instituto Militar de Engenharia P gina 2 2 161 7 4 3 ARTEFATOS T CNICAS DE LEITURA VERTICAL Garantia da Qualidade de Software Leitura Vertical 1 Versao 1 2 RELV 101 03 Data da vers o 03 03 2004 TLV 1 Necessidades do Cliente e Gloss rio X Modelo de Contexto Objetivo Verificar se um Modelo de Contexto do Dom nio e sua descri o est o capturando todos os relacionamentos entre o dominio do problema com os outros dom nios externos de forma a estabelecer as entidades externas suas interfaces de aplica o e requisitos de dados o ambiente de opera o e as restri es ao dom nio do problema Pr requisito Esta leitura requer que o documento Necessidades do Cliente tenha sido aprovado pelo Processo Controle de Qualidade Entrada para o processo 1 Descri o das Necessidades do Cliente e Gloss rio com as descri es detalhadas das funcionalidades 2 Modelo de Contexto do Dom nio representado pelo diagrama de contexto baseado no m todo FORM 3 Descri o textual do Model
147. dores respons veis por diferentes partes da lista As perguntas da lista de confer ncia devem ser frases t o precisas quanto poss veis A lista de confer ncia deve ser estruturada de forma que o requisito de qualidade esteja claro para o verificador e a pergunta forne a sugest es de como assegurar o requisito de qualidade A lista de confer ncia deve ser utilizada em artefatos que o Comit de Qualidade tenha conhecimento adequado e experi ncia suficiente para realiza o das listas de perguntas de forma a abranger maior n mero de classes de defeitos Durante o processo de preenchimento da lista de confer ncia checklist o verificador embasado pela t cnica de Leitura baseada em Perspectiva deve assumir uma perspectiva espec fica com o objetivo de inspecionar e validar o artefato O checklist deve ser formado por um conjunto de aspectos e cada um destes aspectos deve ser composto por um conjunto de quest es que devem obter o maior n mero poss vel de respostas adequadas para assegurar o objetivo proposto de cada aspecto Para obter esse conjunto de aspectos deve ser considerado o tipo de produto a ser verificado e a necessidade de se obter um artefato adequado ao objeto de trabalho 67 As duas atividades do Subprocesso de Verifica o s o detalhadas a seguir SPV A1 PLANEJAMENTO Na atividade Planejamento a partir do Plano de Ger ncia de Projeto o Consultor de Qualidade alocado ao projeto deve definir um Plano d
148. dores devem aplicar a t cnica de leitura baseada em perspectiva que possibilita a verifica o do asset sob a perspectiva de diferentes reutilizadores Para cada perspectiva tanto um como v rios cen rios devem ser definidos consistindo de atividades repet veis que um verificador deve executar e de perguntas que um verificador deve responder Para essas verifica es devem ser reutilizados modelos aplic veis se existirem A documenta o de cada asset deve conter as seguintes caracter sticas apontadas por BRAUN 1994 KARLSSON 1995 KRUEGER 1992 MEYER 1994 Geral cont m informa o geral sobre o asset e a partir desta informa o deve ser poss vel decidir se o asset candidato para um certo cen rio Entretanto esta documenta o n o pode ser muito detalhada para evitar que o processo de sele o de candidato seja demorado Por m este processo de sele o pode requerer busca de mais informa o que deve estar documentada em algumas das caracter sticas apresentadas a seguir De Reutiliza o cont m todas as informa es necess rias de instala o uso e adapta o do asset Administrativa cont m informa es administrativas como restri es legais e suporte dispon vel De Avalia o cont m informa es mais detalhes para a avalia o de um asset como problemas conhecidos restri es e declara es de qualidade importante ressaltar que para 82 aumentar o ganho em reuso o asset deve
149. dos conforme o Plano de Medi o e Avalia o Os dados obtidos da medi o devem ser coletados e armazenados O Grupo de M tricas diante dos resultados coletados deve registrar no Relat rio da Avalia o o n vel de pontua o referente a cada m trica de acordo com a pontua o estabelecida na atividade Especifica o da Avalia o SPM A2 Al m disso o grupo deve verificar o produto artefato se est em conformidade com os requisitos a especifica o e o Plano de Medi o e Avalia o Finalmente deve gerar o Relat rio da 79 Avalia o que dever ser divulgado dentro da organiza o e tamb m para o Grupo de GQS Corporativo A segii ncia de tarefas da atividade Execu o da Medi o consiste em Coletar dados que medem as m tricas identificadas na atividade Especifica o da Avalia o Armazenar os dados Analisar os dados para fornecer o n vel de pontua o Verificar o produto artefato est de acordo com os requisitos especifica es e Planejamento da Avalia o Pontuar a avalia o SPM A5 AVALIA O O Grupo de M tricas deve analisar os resultados para avaliar o desempenho a estabilidade e capacidade do processo prever custos e desempenhos futuros identificar tend ncias identificar oportunidades de melhoria da qualidade e de reusabilidade do produto artefato Este grupo deve produzir o Relat rio de Medi o e Avalia o e disponibilizar os dados resultantes da mes
150. e Codifica o ou Montagem Etapa do planejamento de te ste Bapa de execu o de te ste FIG 2 1 1 1 Diagrama de relacionamento das etapas de desenvolvimento de projeto e os tipos de testes aplicados a cada etapa As t cnicas de teste quanto origem da informa o utilizada para estabelecer os requisitos de teste podem ser funcional ou caixa preta PRESSMAN 2001 estrutural ou caixa branca PRESSMAN 2001 com base em erros DEMING 1990 e com base em m quinas de estado finito FUJIWARA 1991 Basicamente h quatro tipos de teste LEWIS 2000 ROCHA et al 2001 teste de unidade teste de integra o teste de sistema e teste de aceita o Os testes de unidade testam a l gica do c digo independentemente do ambiente testes de caixa branca e os testes de integra o focam na integra o destas unidades testadas com ambiente do projeto ROCHA et al 2001 Tanto os testes de unidade como de integra o devem ser escritos pelos programadores por ambos requerem conhecimento espec fico das tecnologias envolvidas tais como linguagens de programa e par metros de integra o entre as unidades LEWIS 2000 O teste de integra o deve envolver todos os n veis de detalhes de implementa o de base de dados e linguagens componentes externos ou protocolos de comunica o utilizados para a constru o do sistema LEWIS 2000 O teste de sistema visa identificar erros de fun es e atributos de qualidade que n o e
151. e da Camada de Neg cio o relacionamento e restri o equivalente Realce em amarelo o relacionamento equivalente na classe correspondente da Interface da Camada de Neg cio 1 Caso contr rio os relacionamentos ou restri es n o deveriam ser definidos desta maneira ent o preencha a Tabela de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o Restrito Instituto Militar de Engenharia P gina 1 2 156 Garantia da Qualidade de Software Leitura Horizontal 3 Vers o 1 2 RELH301 03 Data da vers o 03 03 2004 A Para cada relacionamento da classe de neg cio verifique se a navegabilidade est correta na classe correspondente da Interface da Camada de Neg cio 1 Caso contr rio preencha a Tabela de Discrep ncia pois a navegabilidade pode estar amb gua relatando a necessidade de conhecimento adicional para compreens o Verifique se existe uma classe de interface cujo estere tipo interface que tenha um relacionamento de composi o com a classe de neg cio correspondente Marque com asterisco verde a classe de interface Caso contr rio preencha a Tabela de Discrep ncia pois uma interface n o est presente na Interface da Camada de Neg cio 1 Caso contr rio preencha a Tabela de Discrep ncia pois um m todo de uma interface n o est presente na Interface da Camada de Neg cio 2 Certifique que o nome da classe de interface do neg cio inicia pela vogal em mai sc
152. e Verifica o conforme o PGQSP usando um modelo e cronograma adequado ao projeto de desenvolvimento do software cuja verifica o deve ser realizada pelo Grupo de GQS do rg o Descentralizado de Fornecimento de Software contratado A sequ ncia de tarefas da atividade Planejamento consiste em SPV Al 1 Analisar as necessidades e caracter sticas desejadas do projeto em fun o dos recursos e riscos associados que podem causar a n o atingir os objetivos SPV A1 2 Estabelecer checklists para verificar os artefatos baseados em aspecto e selecionar respons veis qualificados para realiza o das verifica es Para cada aspecto um ou mais objetivos s o definidos e um conjunto de perguntas que o verificador deve responder estabelecido dentro do contexto dos objetivos Para estes checklists devem ser reutilizados modelos aplic veis se existirem SPV A1 3 Determinar os recursos respons veis e cronogramas para as verifica es dos seguintes artefatos Necessidades do Cliente e Gloss rio Processo de Aquisi o para assegurar padroniza o da documenta o qualidade completude rastreabilidade e corretude das necessidades e caracter sticas desejadas do projeto pelo cliente Arquitetura Engenharia de Dom nio para garantir corretude rastreabilidade clareza e padr es de estrutura c digo fonte Processo de Desenvolvimento para garantir codifica o adequada aos padr es e requisitos estabelecidos no Contrato e Casos de
153. e aplica o Jacobson ainda relata que alguns componentes podem ser mais reusados do que outros O AP NDICE 2 apresenta uma tabela resumida das principais m tricas e modelos apontados pela literatura utilizando a classifica o de Frakes 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 dos artefatos gerados para compor os assets no ciclo de vida do desenvolvimento de projeto baseado em reuso apresentado por GURGEL 2004 este trabalho apresenta uma proposta de um Processo de Garantia de Qualidade de Software GQS Este processo estabelece um framework para auxiliar no desenvolvimento do ciclo de vida do software baseado em reuso sistem tico de assets com o expl cito prop sito de contribuir para a qualidade e produtividade do projeto de software dentro do contexto do Minist rio da Defesa e de seus Comandos Subordinados FIG 3 1 Processo de Garantia da Qualidade de Software PCQ Processo de Controle da Qualidade EE de SPM Subprocesso de PAL Processo de EE Medi o e Avalia o Aprova o de Asset SPR Subprocesso de Revis o Contexto do Minist rio da Defesa e de seus Comandos Subordinados rg o Descentralizado de Fornecimento de Software Processo ao a do Projeto ERA de EEE Engenharia de Dom nios ennaria de Dom nios Processo de Opera o rg o C
154. e armazenamento dos mesmos Ampliar a estrat gia proposta para tratar de aspectos humanos das reuni es das revis es quanto s abordagens para melhoria dos conflitos humanos t cnica de prepara o para revis es t cnicas neste trabalho foi feita uma abordagem superficial Aprofundar na valida o da documenta o classifica o e ger ncia de assets de acordo com as normas ISO 12207 e IEEE 1517 Portanto dever o ser estabelecidas atividades de auditoria padroniza o da documenta o e ger ncia de assets Realizar novos estudos de casos para verificar o grau de facilidade de aplica o da estrat gia proposta 114 6 REFER NCIAS BIBLIOGR FICAS ABNT9000 ASSOCIA O BRASILEIRA DE NORMAS T CNICAS ABNT NBR ISO 9000 Sistemas de gest o da qualidade ABNT CB 25 Comit Brasileiro da Qualidade 2001 ABNT9001 ASSOCIA O BRASILEIRA DE NORMAS T CNICAS ABNT NBR ISO 9001 Sistemas de gest o da qualidade Requisitos 2001 ABNT12207 ASSOCIA O BRASILEIRA DE NORMAS T CNICAS ABNT NBR ISO IEC 12207 Tecnologia da Informa o Processo de ciclo de vida de software Out 1998 AGRESTI W EVANCO W Projecting software defects in analyzing Ada designs IEEE Transactions on Software Engineering v 18 n 11 1992 p 988 997 ALMEIDA K M STAA A V Avalia o da qualidade em um modelo de ciclo de vida orientado a reuso III Simp sio de Desenvolvimento e Manuten o de Software
155. e de interface n o deveria ser definida desta maneira relatando a necessidade de conhecimento adicional para compreens o 3 Certifique que n o existe nenhum data type sem asterisco azul e nenhum atributo sem estar sublinhado em azul Caso exista algum data type ou atributo preencha a Tabela de Discrep ncia pois um data type na Interface da Camada de Neg cio n o est sendo referenciado relatando que um atributo de classe da Interface da Camada de Neg cio n o est presente na classe correspondente do Modelo Tipo de Neg cio 4 Certifique que n o exista nenhum relacionamento sem estar realgado em amarelo Caso exista algum preencha a Tabela de Discrep ncia pois um relacionamento na Interface da Camada de Neg cio n o est presente no Modelo Tipo do Neg cio Instituto Militar de Engenharia P gina 2 2 157 Garantia da Qualidade de Software Leitura Horizontal 4 Vers o 1 2 RELH401 03 Data da vers o 03 03 2004 TLH 4 Interfaces da Camada de Neg cio e de Aplica o X Diagrama de Intera es Objetivo Verificar se o diagrama de intera es descreve a din mica dos servi os das classes de interfaces da Camada de Neg cio e da Camada de Aplica o de forma que os comportamentos especificados no Diagrama de Intera o est o capturados corretamente Entrada para o processo 1 Interfaces da Camada de Aplica o representada por diagrama de classes 2 Interfaces da Camada de Neg cio representada por diagram
156. e empirical investigation of perspective based reading Empirical Software Engineering Journal I 1996 38 p Dispon vel http www cs umd edu mvz handouts emp_pbr pdf capturado em junho de 2003 BASILI V R CALDIERA G ROMBACH H D The experience factory Maryland EUA Institute for Advanced Computer Studies Department of Computer Science University of Maryland amp FB Informatik Universit t Kaiserlautern German 2000 19 p Dispon vel http wwwagse informatik uni kl de pubs repository basili94c encyclo ef pdf capturado em abril de 2003 BIEMAN J KARUNANITHI S Candidate Reuse Metrics for Object Oriented and Ada Software In Proceedings of IEEE CS First International Software Metrics Symposium May 1993 p 120 128 BOEHM B W PAPACCIO F N Understanding and controlling software costs IEEE Transactions on Software Engineering v 14 n 10 Oct 1988 BRAGA R M M WERNER C M L Processo de engenharia de dominio do ambiente Odyssey Relat rio t cnico do projeto Odyssey 4 99 Rio de Janeiro COPPE UFRJ 1999 Dispon vel http www cos ufrj br odyssey pt relatorios htm capturado em janeiro de 2004 BRAUN C Reuse In Encyclopedia of Software Engineering by Marciniak John J Editor in Chief v 1 John Wiley amp Sons 1994 p 1055 1069 BRIAND L C FREIMUT B LAITENBERGER O RUBE G KLEIN B Quality assurance technologies for the EURO conversion industrial experience at Alli
157. e horizontais respectivamente Abaixo segue uma descri o mais detalhada dos tr s tipos de m tricas apresentadas na TAB 4 2 4 1 2 que tratam do esfor o previsto e realizado pelo Grupo de GQS nas atividades de verifica o revis o do artefato a saber Esfor o Previsto o esfor o previsto do Grupo de GQS para a realiza o da verifica o e revis o individual em homem hora Esfor o Realizado o esfor o despendido do Grupo de GQS para a realiza o da verifica o e revis o individual em homem hora Taxa de Esfor o Realizado o esfor o realizado pelo Grupo de GQS para execu o da verifica o revis o individual em rela o ao esfor o do processo de desenvolvimento 104 TAB 4 2 4 1 2 Os principais objetivos perguntas e m tricas relativos previsibilidade de esfor o associado verifica o e revis o dos artefatos Objetivo controlar o esfor o associado aos processos de Verifica o e Revis o Quest es M tricas 1 Quantidade de esfor o estimado para a e Esfor o previsto realiza o das atividades verifica o e revis o 2 Quantidade de esfor o realizado para a e Esfor o realizado execu o das atividades verifica o e revis o 3 Qual a rela o entre esfor o previsto e esfor o e Taxa de esfor o realizado realizado 4 2 4 1 3 INDICADORES DE QUALIDADE DO PROJETO OO BASEADO EM REUSO IQPOOR Foi utilizado o Modelo de Hierarquia para Avalia
158. e podem ser os atributos mais importantes KAN 1995 ao passo que para as organiza es com v rias plataformas os principais atributos s o a portabilidade e extensibilidade A identifica o de um conjunto de atributos de qualidade que completamente representa avalia o de qualidade n o uma tarefa trivial Em geral estes atributos est o relacionados aos objetivos gerenciais metas empresariais competi o economias e tempo alocado para o desenvolvimento do produto Por isso geralmente as organiza es realizam um processo de 39 medi o com um alto risco de insucesso As dificuldades mais comuns na implanta o de um processo de medi es s o as seguintes DERBY 2001 SINGER et al 2002 Muitos programas de medi o s o iniciados com a medi o de atributos que s o convenientes e f ceis de se medir ao inv s de se medir os dados que s o realmente necess rios para uma tomada de decis o Como resultado tem se uma grande quantidade de dados sem utilidade Considerando que h uma demanda de esfor o para obten o e consolida o desses dados in teis o programa de medi o acaba tornando se muito custoso em rela o aos benef cios e termina sendo descontinuado muito comum nas organiza es que a m trica se transforme em um objetivo ao inv s de uma informa o til O segredo para manter a medi o til colocar a aten o em seu significado Muitas organiza es n o t m uma clara no
159. ec fico proposto 2 6 Revis o Conjunta Define as atividades para avaliar a situa o e produtos de uma atividade de um projeto se apropriadas 2 7 Auditoria Determinar adequa o aos requisitos planos e contrato quando apropriado 2 8 Resolu o de Problemas 3 Processos Analisar e solucionar os problemas de qualquer natureza ou fonte descobertos durante a execu o do desenvolvimento opera o manuten o ou outros processos Processos que estabelece e implementam uma estrutura subjacente constitu da de processos de ciclo de vida e pessoal associados melhorando continuamente a 135 Organizacionais estrutura e os processos S o tipicamente empregados fora do dom nio de projetos e contratos espec ficos 3 1 Ger ncia Gerenciamento de processos 3 2 Infra Fornecimento de recursos para outros processos Inclui hardware software estrutura ferramentas t cnicas padr es de desenvolvimento opera o ou manuten o 3 3 Melhoria Atividades para estabelecer avaliar medir controlar e melhorar um processo de ciclo de vida de software 3 4 Treinamento Atividades prover e manter pessoal treinado A ISO IEC 12207 ABNT12207 1998 define como os processos podem ser usados de diferentes maneiras por diferentes organiza es ou por parte destas representando diversos pontos de vista para esta utiliza o Existem cinco vis es diferentes contrato gerenciamento
160. ecto verificados Total de n o conformidades Verificador Tempo de prepara o Hr N vel de conhecimento do dom nio Tempo de realiza o da verifica o Hr 0 baixo 1 m dio 2 alto Qtde linhas de c digo n o coment rio Data da Verifica o Assinatura Restrito Instituto Militar de Engenharia Pagina 3 8 144 Garantia da Qualdade de Software Checklist C digo Fonte em Java Vers o 1 5 VECF001 03 Data da vers o 01 03 2004 Checklist C digo Fonte em JAVA Artefato Verificado pacote CTCF001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecera resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Confor midades 7 Aspecto Defeito de C lculo Num rico Este aspecto deve verificar os defeitos de computa o 7 1 Na express o com mais de um operador a ordem de preced ncia das opera es est correta 7 2 Os par nteses usados s o para evitar ambiguidade 7 3 Existe algum c lculo que est com diferentes tipos de dados 7 4 Existe algum c lculo que os mesmos tipos de dados
161. eja um relacionamento de composi o utilizado ao inv s de uma associa o Se n o encontrou um fato incorreto que contradiz o conhecimento do dom nio Instituto Militar de Engenharia P gina 2 2 159 Garantia da Qualidade de Software Leitura Horizontal 4 Vers o 1 2 RELH401 03 Data da vers o 03 03 2004 TLH 4 Interfaces da Camada de Neg cio e de Aplica o X Diagrama de Intera es Objetivo Verificar se o diagrama de intera es descreve a din mica dos servi os das classes de interfaces da Camada de Neg cio e da Camada de Aplica o de forma que os comportamentos especificados no Diagrama de Intera o est o capturados corretamente Entrada para o processo 1 Interfaces da Camada de Aplica o representada por diagrama de classes 2 Interfaces da Camada de Neg cio representada por diagrama de classes 3 Diagrama de Intera es representado por diagrama de segii ncia Procedimentos I Leia o Diagrama de Intera es para entender que servi os est o descritos e como estes deveriam ser implementados ENTRADAS Diagrama de Intera es SA DAS Relat rio de Discrep ncias Para cada diagrama de seqii ncia execute os seguintes passos A Encontre os atores objetos e classes e realce os de azul B Realce de verde a informa o trocada entre os objetos as setas horizontais Considere se esta informa o representa mensagens ou servi os Se a informa o trocada est muito detalhada p
162. ente no outro II Reveja o Modelo Conceitual do Dom nio para assegurar que todas as entidades externas e seus relacionamentos est o sendo levados em considera o ENTRA DAS Entidades externas marcadas com asterisco azul Relacionamentos real ados em amarelo SA D AS Relat rio de Discrep ncias A Reveja as entidades externas e seus relacionamentos para ter certeza que todo o conjunto de entidades e seus relacionamentos aparecem descritos no documento de Necessidades do Cliente e Gloss rio 1 Certifique que n o exista nenhuma entidade externa sem asterisco e relacionamento sem estar real ado em amarelo Caso exista algum preencha a Tabela de Discrep ncia pois uma entidade externa ou relacionamento no Modelo de Contexto do Dominio n o est presente no documento Necessidades do Cliente e Gloss rio Restrito Instituto Militar de Engenharia P gina 2 2 FIG 4 2 3 1 1 a T cnica de Leitura Vertical TLV1 Relat rio da Revis o icas de Leitura Id Projeto Data da revisao Revisores Dura o da revis o Papel Nome Rubrica N vel de Conhecimento O baixo 1 m dio 2 alto T rmino hr L der Expositor Secret rio Autor es Revisor es M dia do conhencimento Nome e tipo dos documentos revisados Doc1 Total de discrep ncias C Doc2 Resultado da Revis o Jaceito JN o Aceito
163. entes identificar se as segii ncias executam a mesma fun o O programa pode apresentar um resultado correto para um dado de entrada espec fico satisfazendo um requisito de teste e n o revelando a presen a de um erro Inviabilidade de testar todas as possibilidades pois o dominio dos dados de entrada normalmente infinito ou muito grande teste exaustivo Limita o do tempo e recursos Indisponibilidade de ferramentas adequadas para a realiza o dos testes Uma maneira de minimizar as limita es estabelecer crit rios de teste que devem ser estabelecidos no Plano de Teste A princ pio devem ser definidos os crit rios de teste de aceita o que v o servir de base para os crit rios de testes de sistema integra o e de unidade Na etapa de execu o do teste o processo deve ser inverso ao do plano de teste come ando pelo teste de unidade Na FIG 2 1 1 1 apresentado um diagrama que relaciona as fases de desenvolvimento de projeto e os tipos de testes correspondentes Ao estruturar o processo de teste em cada fase do processo de desenvolvimento do software diferentes tipos de defeitos e aspectos do software s o abordados resultando em maior cobertura e minimizando a complexidade da atividade MYERS 1979 MALDONADO 1991 29 Necessidades do Cliente Teste de Aceita o r lise do de Sistema Projeto do Domi zo Me de Integra o Especifica o do Componente q Teste de Unidad
164. ento de software ao passo que o Grupo de M tricas deve ser respons vel por medir e analisar os dados coletados e armazenados para avalia o do processo de desenvolvimento e do produto de software Esta organiza o estrutural aplicada ao contexto do Minist rio da Defesa apresentada na FIG 3 1 2 onde um Grupo de GQS Corporativo deve estar ligado ao Minist rio da Defesa via rg o Central de Ger ncia de Reuso Departamento de Ci ncia e Tecnologia Cada rg o 55 Descentralizado de Fornecimento de Software deve ter seu Comit de Qualidade formado por Consultores da Qualidade e um Grupo de GQS e um Grupo de M tricas devem estar subordinados a este comit MINIST RIO DA DEFESA Legenda Grupo de GQS Corporativo alocado ao rg o Central de Ger ncia de Re so __ SECRETARIA DE LOGISTICA E MOBILIZA O Comit de Qualidade com os Grupos de GQS e Grupo de M tricas alocado em cada Org o Descentralizado de Fornecimento de Software Leio COMANDO DA MARINHA COMANDO DO EXERCITO AERON UTICA Estado Maior da Centro de Apoio Sistemas Navais I l I Comando de Opera es Diretoria Geral de Diretoria Geral de Secretaria de Tecnologia Secretaria de Ci ncia e Departamento de Servi o Geral da Marinha Departamento de Ensino 1 I Centro Tecnol gico Sub Departamen
165. entral de Ger ncia de Re so Processo de Aquisi o Processo de Ger ncia de Assets Processo de Desenvolvimento FIG 3 1 Escopo do Processo de Garantia da Qualidade de Software Gurgel descreve sobre o contexto do Minist rio da Defesa desde sua cria o em 1999 forma o do Departamento de Ci ncia e Tecnologia nas For as Armadas e tamb m apresenta a atual estrutura dos Comandos da Marinha Ex rcito e Aeron utica GURGEL 52 2004 O Minist rio da Defesa uma institui o de grande porte hierarquizada e com n cleos de desenvolvimento descentralizados conforme apresentado em GURGEL 2004 O modelo de produ o de reuso utilizado por GURGEL 2004 para reuso sistem tico de software para o contexto do MD consiste na combina o da an lise de dom nio pre project e da generaliza o em in project FICHMAN 2001 de forma a identificar artefatos reutiliz veis no dom nio do projeto antes do desenvolvimento do projeto e sempre gerar produtos de software gen ricos o mais poss vel e reutiliz veis A proposta de GURGEL 2004 est apoiada na arquitetura da Norma ISO IEC 12207 ABNT12207 1998 que estendida pela Norma IEEE 1517 1999 para atender um modelo de ciclo de vida de software com reusabilidade veja ANEXO 1 Esta arquitetura foi empregada por utilizar uma terminologia bem definida composta de processos atividades e tarefas para Aquisi o Forneci
166. envolvidos Uma estrat gia de integra o apropriada foi escolhida baseada nas necessidades do cliente Se uma estrat gia top down foi escolhida os stubs est o dispon veis de forma que os m dulos de mais alto n vel possam ser testados adequadamente Ou se uma estrat gia bottom up foi escolhida os drivers est o dispon veis de forma que os clusters dos m dulos de mais baixo n vel possam ser adequadamente testados O teste de regress o desenvolvido como novos m dulos est o integrados Os componentes foram integrados de forma a demonstrar logo a sua devida funcionalidade Existem mecanismos de registro e de corre o dos erros verificados Total de itens do aspecto verificados Total de n o conformidades Restrito Instituto Militar de Engenharia P gina 1 2 148 Garantia da Qualdade de Software ChecKHist Teste de Interface Gre fica Vers o 1 2 VETG001 03 Data da vers o 01 03 2004 Checklist Teste de Interface Grafica Artefato Verificado CTTG001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com numero sequencial para identifica o do erro detectado Todos os erros detectado
167. er que o processo n o esteja adequado para a organiza o Para tirar o papel de fiscaliza o da qualidade os dados s o reportados sempre de forma consolidada para n o se enfatizar um culpado 3 2 GARANTINDO A QUALIDADE O processo de Garantia da Qualidade de Software GQS tem como prop sito estabelecer um conjunto de diretrizes para o planejamento e a execu o de um processo de avalia o de um produto de software ao definir as atividades que devem ser executadas O processo de Garantia da Qualidade de Software GQS se inicia juntamente com o Plano de Aquisi o pelo Grupo de Garantia da Qualidade de Software Corporativo atrav s do artefato Necessidades do Cliente e Gloss rio fornecido pelo Cliente no Processo de Aquisi o veja FIG 3 2 1 A partir deste artefato o Grupo de GQS Corporativo deve criar e documentar um Manual da Qualidade de Projeto onde devem ser especificados os objetivos para assegurar a qualidade dos assets e processos utilizados para desenvolver os produtos de software artefatos que v o compor estes assets al m dos objetivos para garantir a satisfa o do cliente Neste manual tamb m deve estar especificado o escopo da avalia o das verifica es revis es e medi es a serem realizadas no produto os m todos utilizados e as responsabilidades de todos envolvidos no processo de avalia o Na FIG 3 2 1 s o apresentadas as intera es do Processo de Garantia da Qualidade de Software P
168. erador 5 4 C lculo do Vento real Calcular o vento real baseado nos dados de rumo e velocidade reais da plataforma prim ria e nos dados de dire o e intensidade do vento relativo existentes no sistema 5 5 C lculo da Corrente Calcular a corrente baseado nos dados de rumo e velocidade reais da plataforma prim ria e os fornecidos pela agulha girosc pica e hod metro 5 6 Abertura de Acompanhamento Atrav s da inser o de dados de posi o de uma plataforma e da correla o destes com um acompanhamento 5 7 Atualiza o de Acompanhamento Quando da inser o de dados de posi o de uma plataforma j acompanhada pelo sistema Devem ser atualizados o rumo e velocidade da mesma e efetuado o c lculo dos dados t ticos desta em rela o plataforma prim ria 5 8 Extra o de Dados do Acom panhamento Atrav s da sele o de um acompanhamento deve ser calculada a posi o estimada deste e apresentado os dados atualizados do mesmo 5 9 Extra o de Dados do Ambiente Atrav s da sele o para extra o de dados do ambiente o sistema apresenta os dados atualizados do ambiente vento reale corrente 5 10 C lculo de Dados do Acompanhamento Calcular ap s cada atualiza o dos dados do acompanhamento rumo velocidade rumo de passagem segura ponto de maior aproxima o 5 11 C lculo do Rumo e Velocidade da Plataforma Calcular rumo e velocidade reais da plataforma baseado na posi o atuale anterior do mesmo 5 12 C lculo
169. eran a para esta classe e verifique ainda se ele est corretamente representado na Interface da Camada de Neg cio 1 Caso contr rio preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsist ncia entre os dois C Verifique para cada atributo se existe o mesmo atributo especificado com seu tipo b sico na classe correspondente Sublinhe em azul o atributo correspondente na classe da Interface da Camada de Neg cio 1 Caso n o consiga encontrar verifique se existe um data type correspondente ao atributo Caso encontre marque com asterisco azul a classe data type e sublinhe em azul os atributos correspondentes com o mesmo tipo b sico da classe de neg cio em quest o na classe data type e tamb m sublinhe em azul o atributo correspondente ao data type na classe core correspondente Caso n o exista preencha a Tabela de Discrep ncia pois um atributo da classe de neg cio n o est presente na classe correspondente da Interface da Camada de Neg cio 2 Certifique que o nome do atributo utilizado na classe correspondente da Interface da Camada de Neg cio o mesmo da classe de neg cio Caso n o tenha o mesmo nome preencha a Tabela de Discrep ncia pois a descri o pode estar amb gua relatando a necessidade de conhecimento adicional para compreens o D Para cada relacionamento e restri o da classe de neg cio verifique na classe correspondente da Interfac
170. es e gr ficos ou interfaces gr ficas 3 5 Conformidade Evidencia o quanto o software est de acordo com as normas conven es guia de estilo ou regulamenta es relacionadas usabilidade da aplica o Efici ncia Conjunto de atributos que evidenciam o relacionamento entre o n vel de desempenho do software e a quantidade de recursos utilizados sob condi es estabelecidas Recursos podem incluir outros produtos de software facilidades de hardware materiais como papel de impressora discos flex veis e servi os de opera o manuten o e suporte 4 1 Comportamento em Evidencia seu tempo de resposta tempo de processamento e velocidade na rela o ao tempo execu o de suas fun es 4 2 Comportamento em Evidencia a quantidade de recursos usados e a dura o de seu uso na rela o aos execu o de suas fun es recursos 4 3 Conformidade Evidencia o quanto o software est de acordo com as normas ou conven es relacionadas efici ncia da aplica o 133 Manutenibilidade Conjunto de atributos que evidenciam o esfor o necess rio para fazer modifica es especificadas no software Modifica es podem incluir corre es melhorias ou adapta es do software mudan as no ambiente e nos requisitos e especifica es funcionais 5 1 Analisabilidade Evidencia o esfor o necess rio para diagnosticar defici ncias ou causas de falhas ou para identificar p
171. esentar falhas em menos de sete dias 6 2 3 Tempo para reparos MTTR Mean Time to repair O tempo para reiniciar reparar o sistema n o deve ser superior a dez minutos 6 2 4 Persist ncia de dados Os dados do acompanhamento devem ser persistidos de forma que uma queda de energia ou a reinicializa o do sistema n o gere perda de dados 6 2 5 Precis o Tempo 30 segundos Dist ncia 10 jardas ou 10 metros Marca o 1 um grau 6 3 Performance 6 3 1 Tempo de resposta da transa o m dia m ximo Dois segundos dez segundos ap s a inser o de dados 6 3 2 Transa es por segundo Cem transa es segundo 6 3 3 Capacidade usu rios transa es simult neas Tr s usu rios cingienta transa es 6 3 4 Recursos RAM 256 MB Disco R gido 2GB Comunica o placa de conex o com o Link Yb 14 interface para GPS interface para agulha girosc pica interface para hod metro e interface para anem metro 6 4 Suporte 6 4 1 Manual de Apoio O sistema deve possuir um manual de apoio para utiliza o gloss rio e procedimento de reinicializa o 6 5 Regras de tecnologia e limita es 6 5 1 Linguagem de software N o determinada 6 5 2 Plataforma de opera o Multiplataforma linux windows 6 5 3 Plataforma de Midddleware N o determinada 6 5 4 Portabilidade Sistema port vel 6 5 5 Sistemas legados N o determinada 6 5 6 Sistemas correlacionados Sistema de Armas Sistema de Navega o Sat lite Sistema Radar sen
172. esso de revis o desde sua cria o mas todas s o influenciadas pelas id ias iniciais de Fagan e Gilb FAGAN 1986 GILB 1993 a realiza o de uma revis o criteriosa do artefato para identificar as poss veis n o conformidades defeitos Essas varia es incluem a modifica o na estrutura da reuni o de revis o ou do n mero de revisores que devem participar da reuni o ou na elimina o da reuni o de revis o FAGAN 1986 GILB 1993 PORTER et al 1995 VOTTA 1993 Um exemplo dessas varia es a realiza o da revis o por uma equipe na qual cada membro tem 33 papel preestabelecido onde o autor do artefato a ser revisado participa mas n o coordena a reuni o LATTENBERGER 2002 Para Fagan e Gilb FAGAN 1986 GILB 1993 o m todo de revis o identifica as fases de planejamento detec o coleta e corre o de n o conformidades Entretanto este m todo n o fornece para o revisor uma diretriz de como as n o conformidades devem ser encontradas na fase de detec o Ambos tamb m admitem que a revis o individual de artefatos pode ser feita satisfat ria e eficientemente apenas com o conhecimento do revisor abordagem ad hoc A revis o deve ser realizada atrav s da inspe o individual pelo revisor que pode ser desenvolvedor montador desde que n o seja o pr prio autor do artefato inspecionado para identificar as poss veis n o conformidades defeitos atrav s da t cnica de leitura adequada ao artefa
173. este relat rio tamb m deve conter os nomes dos revisores data da reuni o material avaliado e a es decorrentes Essas revis es devem ser realizadas nos marcos do Plano de Ger ncia do Projeto de acordo com os t rminos das atividades de elabora o dos documentos acima descritos do Processo ao Longo do Projeto para avalia o dos artefatos produzidos de forma a garantir aos usu rios internos e externos deste artefato uma utiliza o de produtos pelo 72 menos com a qualidade m nima especificada Esta revis o de responsabilidade do Gerente de Projeto Engenheiros de Dom nio Consultor da Qualidade e Cliente Em geral as reuni es podem gerar conflitos humanos portanto fundamental que algumas abordagens para melhoria destes confrontos sejam tratadas TAVARES 2002 antes da reuni o principalmente na atividade Treinamento para Revis o T cnica descrita mais adiante tais como O grupo revisor e grupo autor do artefato devem entender que o objeto da revis o um artefato est tico naquele ponto e n o seus autores As pessoas envolvidas em uma revis o devem exercer outros pap is nas revis es de outros artefatos havendo um rod zio de pap is agindo ora como revisores ora como autores ora como moderadores Os grupos autor e revisor devem entender que cr ticas reincidentes a alguns aspectos do artefato examinado n o significa cr ticas reincidentes ao grupo autor do artefato em inspe o As quatro ati
174. etiva e mais objetiva e que melhor atendem s necessidades de verifica o Baseado no modelo de BASILI et al 2000 devem ser identificados e definidos objetivos quest es e m tricas Goal Question Metric para processos por exemplo tempo de an lise tempo de codifica o tempo de teste e para produtos artefatos por exemplo linhas de c digo n mero de assets reus veis de maneira objetiva SPM A3 PLANEJAMENTO DA AVALIA O O Consultor de Qualidade deve criar e documentar um Plano para a Medi o e Avalia o da qualidade e reusabilidade adequado ao projeto de desenvolvimento com todas as atividades de implanta o e administra o do processo reusando um modelo aplic vel de plano de administra o de medi o e avalia o se existir para definir os recursos cronograma os procedimentos 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 os seguintes aspectos Recursos cronograma responsabilidades e procedimentos para realiza o da medi o e an lise do processo e produtos Prover infra estrutura m todos ferramentas pr ticas recursos humanos treinamento para assegurar a execu o do processo SPM A4 EXECU O DA MEDI O O Grupo de M tricas deve medir o produto artefato mediante as m tricas selecionadas na atividade Especifica o da Avalia o SPM A2 e os recursos e a metodologia estabeleci
175. etividade do Projeto 1 32 Extensibilidade do Projeto 0 Flexibilidade do Projeto 0 5 Funcionalidade do Projeto 8 04 Reusabilidade do Projeto 17 4 3 AVALIA O DO ESTUDO DE CASO Atrav s dos resultados obtidos na aplica o dos processos na execu o do projeto piloto Controlador T tico tanto a viabilidade dos processos e a hip tese formulada s o v lidas Os artefatos de qualidade levantaram n o conformidades que nos testes realizados para detec o de erros n o foram capturados Estas n o conformidades interferem n o somente na padroniza o e corretude dos assets gerados para o projeto mas para o entendimento claro e preciso dos assets quando estes forem reutilizados em outros dom nios Os indicadores estabelecidos nesta proposta fornecem subs dios ao gerente de reuso verificar nos projetos futuros desenvolvidos dentro do contexto do Minist rio da Defesa e de seus Comandos Subordinados via o processo baseado em reuso sistem tico de GURGEL 2004 quanto melhora da produtividade e do processo de Verifica o e Revis o e a qualidade do projeto desenvolvido sob a tica da reusabilidade extensibilidade e compreensibilidade 5 CONCLUS ES O processo sistem tico de Garantia da Qualidade de Software GQS desenvolvido neste trabalho atingiu seu objetivo de apoiar o Processo de Desenvolvimento de Software baseado em Reuso de GURGEL 2004 elaborado para o contexto da MD visando capacitar os 111
176. etos relacionados Caso contr rio os relacionamentos n o deveriam ser definidos desta maneira ent o preencha a Tabela de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o II Reveja o Modelo de Casos de Uso do Dominio para assegurar que todos os casos de uso e atores est o sendo levados em considera o ENTRADAS Casos de uso marcados com asterisco azul Itera es e associa es de extens o ou inclus o real adas em amarelo SA DAS Relat rio de Discrep ncias A Reveja os casos de uso e suas itera es e associa es para ter certeza que todo o conjunto de caso de uso e suas itera es e associa es aparecem representados no Modelo Conceitual de Dom nio 1 Certifique que n o exista nenhum caso de uso sem asterisco e itera o e associa o sem estar real ado em amarelo Caso exista algum preencha a Tabela de Discrep ncia pois um caso de uso ou itera o ou associa o no Modelo de Casos de Uso do Dom nio n o est presente no Modelo Conceitual do Dom nio Restrito Instituto Militar de Engenharia P gina 2 2 155 Garantia da Qualidade de Software Leitura Horizontal 3 Vers o 1 2 RELH301 03 Data da vers o 03 03 2004 TLH 3 Modelo Tipo do Neg cio X Interface da Camada de Neg cio Objetivo Verificar se a Interface da Camada de Neg cio cont m todos os tipos de interface do neg cio seus atributos com os tipos b sicos suas regras de associa o suas assinatur
177. everia ser respons vel pelo servi o possui um comportamento associado nos diagramas de classes Tamb m esteja certo que existe algum tipo de associa o nos diagramas de classes entre as classes que a mensagem conecta no diagrama de segii ncia Lembre que em ambos os casos pode se precisar procurar na rvore de heran a a que classe pertence para encontrar as caracter sticas necess rias Restrito Instituto Militar de Engenharia P gina 1 2 158 Garantia da Qualidade de Software Leitura Horizontal 4 Vers o 1 2 RELH401 03 Data da vers o 03 03 2004 Restrito Verifique ainda que para cada servi o as mensagens descritas pelo diagrama de seqii ncia s o suficientes para executar aquele servi o Verifique as seguintes discrep ncias e caso encontre as preencha a Tabela de Discrep ncia 1 Esteja certo que para cada mensagem no diagrama de seqii ncia a classe recebedora cont m um comportamento apropriado no diagrama de classe correspondente Caso contr rio isto significa que existe uma inconsist ncia entre os diagramas Um comportamento est presente no diagrama de segii ncia mas faltando no diagrama de classes 2 Esteja certo que existem comportamentos apropriados aos servi os Se n o existe um servi o presente no diagrama de sequ ncia que n o est representado no diagrama de classe correspondente 3 Esteja certo que existe uma associa o no diagrama de classes correspondente entre as duas classes a
178. expositor O l der deve ser o Consultor de Qualidade alocado ao projeto A dura o da reuni o n o deve ultrapassar a duas horas A sequ ncia de tarefas da atividade Revis o T cnica consiste em SPR A4 1 A reuni o se inicia pelo expositor apresentando o documento a ser examinado e em seguida pela exposi o do n vel de adeqiiabilidade e se existir das n o conformidades encontradas por cada revisor Durante o debate dos grupos revisor e autor pode haver interven es do l der como mediador SPR A4 2 Durante toda a reuni o o secret rio preenche o Relat rio de Revis o com os nomes dos membros da reuni o data hora local recursos utilizados como tamb m registra os problemas detectados e as a es decorrentes inclui os resultados da revis o as n o conformidades detectadas pelo revisor atrav s da leitura individual e registra o n vel de adegiiabilidade aprovado desaprovado ou aprovado com pend ncias SPR A4 3 Das n o conformidades detectadas o grupo autor pode apresentar justificativas dos motivos que levam a alguns deles n o representarem problemas reais Esta Justificativa deve constar no Relat rio de Revis o SPR A4 4 Os problemas detectados que fogem ao escopo do respons vel pela elabora o do artefato devem ser listados no Relat rio de Revis o assim como as a es decorrentes 75 O grupo autor deve corrigir as n o conformidades descritas no Relat rio da Revis o e o Gerente do Projet
179. faces da Camada de Neg cio Interfaces da Camada de Aplica o Diagrama de Intera es com objetos servi os e restri es marcados SA DAS Relat rio de Discrep ncias A Verifique que todo objeto classe e ator usado no diagrama de segii ncia est o representados por uma classe concreta nos diagramas de classes Para as classes e atores encontre o nome nos diagramas de classes Para os objetos encontre a nome da classe da qual o objeto foi instanciado Verifique as seguintes discrep ncias e caso encontre as preencha a Tabela de Discrep ncia 1 Se uma classe ou objeto n o pode ser encontrada nos diagramas de classes isto significa que a informa o est inconsistente entre os diagramas de classes e o diagrama de seqii ncia est presente em um e ausente em outro 2 Se um ator n o pode ser encontrado determine se o ator precisa ser apresentado como uma classe para executar algum comportamento necess rio Se sim ent o informa o que est presente no diagrama de seqii ncia est faltando nos diagramas de classes B Verifique se para todo servi o ou mensagem marcado em verde no diagrama de sequ ncia existe um comportamento correspondente no diagrama de classes Verifique se existem comportamentos de classes nos diagramas de classes que encapsulam os servi os de mais alto n vel fornecidos pelo diagrama de seqii ncia Ou seja esteja certo que a classe ou objeto que recebe a mensagem no diagrama de segii ncia ou que d
180. grama Casos de Uso e Cen rios Doc2 DCO1003 Diagrama de Classes ND N mero seqiiencial da discrep ncia TC Tipo de Conceito ATO ator COM comportamento HER heran a PAP papel ATR atributo CON condi o MEN mensagem REL relacionamento CAR cardinalidade DAD dado OBJ objeto classe RES restri o OUT outros tipos identificar em coment rios TD Tipo de Discrep ncia Omiss o de funcionalidade ou conceito Projeto incorreto em rela o s necessidades Informa o de projeto n o est mencionada nas necessidades Implementa o das necessidades est amb gua ou n o complemente especificada Outro tipo de problema de projeto explique Sev Severidade A Nao s rio mas precisa verificar este documento B Esta discrep ncia invalida esta parte do documento Verifique ambos documentos c s rio N o poss vel continuar a leitura deste documento Ele deve ser reorganizado Todas as discrep ncias com severidade C e do tipo 5 devem ser explicadas na parte de Detalhamento assim como outras discrep ncias consideradas importantes TD Sev Coment rios ATR Extrair Dados lextra o 2 B M todo n o confere com a interface ATR Extrair Dados 2 B Vento n o definido Caso seja necess rio utilize a tabela adicional e ou detalhamento adicional T mino da revis o 10 hr S preencher se N O for utilizar a tabela adicional FIG 4 2 3 2 1 a Tabela de Discrep ncia para T cnica de Leitura Vertical Tabe
181. hecimento adicional para compreens o B Procure por descri o de servi os nos cen rios que tenham sido omitidos na especifica o da Interface da Camada da Aplica o 1 Certifique que n o existem verbos n o marcados com asterisco verde Caso exista verifique se ele deveria ser inclu do na especifica o da Interface da Camada da Aplica o ou n o por estar descrito apenas para melhorar a legibilidade da fun o do cen rio Se devesse estar inclu do preencha a Tabela de Discrep ncia pois servi o foi omitido na especifica o da Interface da Camada da Aplica o C Para cada classe de interface da especifica o da Interface da Camada da Aplica o procure por servi os que n o tenham sido referenciadas 1 Certifique que n o existem assinaturas n o marcadas com asterisco verde Caso exista preencha a Tabela de Discrep ncia pois um servi o n o deveria ser definido desta maneira relatando a necessidade de conhecimento adicional para compreens o 2 Certifique que n o exista nenhum argumento do servi o sem estar sublinhado em azul ou vermelho Caso exista alguma preencha a Tabela de Discrep ncia pois um argumento de entrada ou sa da da classe de interface n o deveria ser definido desta maneira relatando a necessidade de conhecimento adicional para compreens o Instituto Militar de Engenharia P gina 2 2 167 Garantia da Qualidade de Software Leitura Vertical 5 Vers o 1 2 RELV501 03 Data
182. i o e melhoria de um processo de software resultando no surgimento de v rios modelos e normas para a defini o de processos e garantia de qualidade Os modelos mais utilizados para definir processos de software s 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 Commission 12207 ABNT12207 1998 O CMM classifica as organiza es quanto ao n vel de maturidade e a Norma ISO IEC 12207 est baseada em framework para processos de ciclo de vida processos fundamentais processos de apoio e processos organizacionais veja AP NDICE 3 A Norma ISO IEC 12207 e sua vers o brasileira s o conhecidas por 67 das empresas pesquisadas pela Secretaria da Pol tica de Inform tica do Minist rio da Ci ncia e Tecnologia SEPIN 2002 mas somente 12 das empresas utilizam na 18 Os produtos de software comumente denominados de artefatos s o um conjunto de informa es em diferentes n veis de abstra o e um conjunto de transforma es e decis es A aplica o de um programa de controle de qualidade na produ o de software garante maior qualidade no processo de desenvolvimento do projeto de software HAZAN 1999 ROCHA et al 2001 Existem diferentes defini es de qualidade e a seguir s o apresentadas algumas destas defini es pesquisadas na literatura a saber Qualidade a satisfa o total do
183. ia do Projeto Ferramentas informa a ferramenta caso haja que deve ser utilizada para registro e acompanhamento das atividades de GQS Esta ferramenta deve fornecer o apoio necess rio para a documenta o e o rastreamento dos itens de n o conformidade at sua conclus o Treinamento necessidade de algum treinamento espec fico em GQS requerido por alguma circunst ncia no contexto do projeto Esse item opcional Hist rico de vers es informa dados de hist rico das vers es anteriores e da atual do artefato tais como data da vers o n mero segiiencial da vers o breve descri o do motivo da vers o autor respons vel pela vers o o nome do revisor e por quem foi aprovado Cronograma de verifica es revis es informa o cronograma para as verifica es revis es de GQS no projeto e o esfor o em homens hora empregado pelo consultor de GQS e pela equipe de desenvolvimento que participam dessas atividades As n o conformidades s necessidades do cliente detectadas no Processo de Controle da Qualidade devem ser registradas nos Relat rios de Verifica o ou Revis o para an lise e avalia o Al m disso ap s a elabora o de cada relat rio um question rio de solicita o de sugest es de melhoria da qualidade deve ser respondido e comentado para capturar e aplicar as li es aprendidas no controle da qualidade de forma a contribuir para melhorar este processo O preenchimento deste question rio pelo executor
184. ia relatando a necessidade de conhecimento adicional para compreens o Restrito Instituto Militar de Engenharia P gina 1 1 163 Garantia da Qualidade de Software Leitura Vertical 3 Vers o 1 2 RELV301 03 Data da vers o 03 03 2004 TLV 3 Modelo Conceitual do Dom nio X Modelo Tipo do Neg cio Objetivo Verificar se um modelo de especifica o Modelo Tipo do Neg cio representado pelo diagrama de classes da UML modela efetivamente toda a informa o pertinente ao escopo do neg cio Pr requisito Esta leitura requer que o diagrama do Modelo Conceitual de Dom nio e Modelo de Casos de Uso do Dom nio tenham sido aprovado pelo Processo Controle de Qualidade Entrada para o processo 1 Modelo Conceitual do Dom nio representado pelo diagrama de classes 2 Modelo de Casos de Uso do Dom nio 3 Descri o dos Cen rios dos Casos de Uso do Dom nio 4 Modelo Tipo do Neg cio representado pelo diagrama de classes Procedimentos I Analise o Modelo Conceitual do Dom nio para entender as classes conceituais e seus relacionamentos ENTRADAS Modelo Conceitual do Dom nio Modelo de Casos de Uso do Dom nio Modelo Tipo do Neg cio SA DAS Relat rio de Discrep ncias Para cada classe do diagrama do Modelo Conceitual do Dom nio execute os seguintes passos A Para cada relacionamento da classe tente encontrar uma associa o agrega o ou composi o no Modelo Tipo do Neg cio Realce em amarelo o relacionamento
185. ical and Eletronics Engineers 1517 recomenda que os processos de software devem prover frameworks para praticar reuso Nestes frameworks as atividades de reuso devem estar integradas ao ciclo de vida do software de forma que o reuso se torne um modo natural e normal de trabalhar veja AP NDICE 3 Portanto algumas considera es devem ser abordadas como o reuso muda o ciclo de vida do software exatamente onde ajustar reuso no processo de desenvolvimento de software e especificamente quais s o os processos as atividades e as tarefas de reuso que devem ser inclu dos no ciclo de vida do software TEEE1517 1999 Para viabilizar a reutiliza o de artefatos necess rio construir uma arquitetura pr pria uma arquitetura orientada a reuso que permita a organiza o de artefatos Atrav s do uso em conjunto da organiza o e estrutura o das informa es procura se facilitar o acesso e o reaproveitamento efetivo dos artefatos JACOBSON et al 1997 Para esta arquitetura a defini o dos requisitos de qualidade uma parte significativa no processo de desenvolvimento de software JACOBSON et al 1997 Pois baseados nestes requisitos o controle de qualidade deve assegurar aos reutilizadores o n vel de qualidade desejada nos assets para que eles possam ter confian a em reutilizar Desta forma o controle de qualidade deve especificar um processo de avalia o adequado ao m todo de desenvolvimento escolhido para o dom nio da
186. idade apontadas pela literatura e estabelecidos os princ pios da qualidade adotados para esta disserta o O Cap tulo 2 Fundamentos Te ricos s o abordados conceitos gerais da engenharia de qualidade garantia da qualidade t cnicas aplicadas ao controle e melhoria da qualidade do 25 processo de desenvolvimento de software Al m disso s o apresentados conceitos e tipos de reuso problemas relacionados a reuso identificados na literatura e os principais modelos e m tricas voltados a reusabilidade A proposta da disserta o detalhada no Cap tulo 3 Processo da Garantia da Qualidade de Software baseado em Reuso Sistem tico Neste cap tulo definida uma metodologia para assegurar a qualidade e validar os assets produzidos pelo rg o Descentralizado de Fornecimento de Software proposto por GURGEL 2004 Para isso estabelecida uma estrutura organizacional do Grupo de Garantia da Qualidade de Software No Cap tulo 4 Estudo de Caso apresentado um estudo de caso realizado para avaliar a viabilidade da proposta definida no cap tulo anterior e aplicar as t cnicas especificadas definir templates e analisar os resultados obtidos deste trabalho No Cap tulo 5 Conclus es s o apresentados as conclus es e os principais benef cios desta disserta o assim como sugere poss veis trabalhos futuros 2 FUNDAMENTOS TE RICOS 2 1 ENGENHARIA DE QUALIDADE A Engenharia de Qualidade respons vel pela determina
187. idos PAA A2 AVALIA O A partir da qualidade aprovada do asset pelo Relat rio de Verifica o correspondente o Comit de Qualidade deve estabelecer credencial de prote o de acesso ao asset conforme Contrato e liberar o asset e o Relat rio de Aprova o do asset para o Processo de Ger ncia de Assets catalogar armazenar divulgar e administrar o controle de acesso no reposit rio de assets reutiliz veis 4 ESTUDO DE CASO Nesta disserta o utilizada a estrat gia de um estudo de caso por ser um m todo que consiste na observa o de um projeto em andamento que pode prover subs dios para verificar os pr s e contra da implanta o de um processo espec fico em um determinado contexto WOHLIN et al 1999 86 Jacobson et al descrevem casos reais de organiza es como AT amp T HP e outras que sentiram a necessidade de uma estrat gia para implementa o de um processo de reuso JACOBSON et al 1997 Estas organiza es adotaram uma metodologia incremental desenvolver a partir de um processo gradativo ou seja a partir de um projeto piloto Pois esta estrat gia possibilita aumento em experi ncias e uma migra o cultural passo a passo minimizando riscos e reduzindo conflitos sociais entre as equipes de desenvolvimento Desta forma uma experi ncia inicial de implanta o da proposta desta disserta o foi realizada com o intuito de viabilizar o processo de Garantia da Qualidade de Software para o process
188. iente Sistema utiliz vel Necessidades do desenvolvedor 4 Sistema execut vel R x Arquitetura Wa Subsistemas execut veis gt Inspecionado contra Ne R Bases para Projeto M dulos execut veis mi integrado em bS e Testado contra k C digo FIG 2 1 2 2 Diagrama de rela o dos artefatos produzidos e a inspe es de software 2 1 2 1 REVIS ES A revis o formal uma t cnica de revis o do software ou de alguns de seus artefatos executada sistematicamente ao final de cada fase do processo de desenvolvimento de software com o objetivo nico de encontrar n o conformidades Esta t cnica executada por uma equipe na qual cada membro tem papel preestabelecido O desenvolvedor autor do artefato em inspe o participa mas n o coordena a reuni o TAVARES 2002 As revis es podem ser implementadas via inspe es ou walkthroughs reuni o conjunta para listar problemas encontrados e a es decorrentes A inspe o de software pode utilizar t cnicas de avalia o formal onde os artefatos s o examinados de maneira criteriosa por uma pessoa sem a participa o do autor para detectar faltas viola es de padr es de desenvolvimento e outras n o conformidades As inspe es tamb m podem ser usadas para obten o de conhecimento ou como base para tomada de decis es REGNELL et al 1999 Muitas varia es t m sido propostas para o proc
189. inclui onze propriedades de projeto identificadas e definidas na TAB 2 1 3 1 2 e a m trica correspondente usada por BANSIYA et al 2002 TAB 2 1 3 1 2 As m tricas de projeto para avaliar as propriedades de projeto Propriedades de Projeto M tricas de Projeto 1 Abstra o uma medida dos aspectos de especializa o generaliza o do projeto N mero M dio de Antecessores esta m trica consiste em contabilizar o n mero m dio das classes que herdam informa o 2 Acoplamento define a interdepend ncia entre objetos em um projeto Acoplamento Direto da Classe esta m trica consiste em contabilizar o n mero de classes que s o diretamente relacionadas pelas declara es dos atributos e passagens de par metros dos m todos 3 Coes o avalia o relacionamento dos m todos e atributos em uma classe Coes o entre M todos na Classe esta m trica calcula a rela o entre os m todos de uma classe baseada por uma lista de par metros 4 Complexidade uma medida do grau de dificuldade no entendimento e compreens o da estrutura interna e externa das classes e de seus relacionamentos N mero de M todos esta m trica consiste em contabilizar todos os m todos definidos em uma classe 5 Composi o medidas de relacionamentos do tipo parte de tem consiste de ou parte do todo que s o os relacionamentos de agrega es em um projeto OO Medida
190. iniciativas de melhoria do processo e conseqiientemente promovendo sua melhoria cont nua Neste trabalho foram abordadas atividades espec ficas para assegurar a qualidade da Ger ncia da Qualidade que est o em conformidade s normas de qualidade da ISO 9000 2000 ABNT9000 2001 Estas atividades s o as atividades de feedbacks ao pr prio processo de GQS realizadas atrav s dos indicadores de qualidade e produtividade dos processos de Verifica o e Revis o como tamb m atrav s do QSMGQ Question rio de Sugest es para Melhoria da Garantia da Qualidade Na literatura foram poucos trabalhos 2 Frutos de um estudo baseado na ISO 9126 por BANSIYA 2002 118 encontrados que se prop em um tratamento expl cito para garantir a qualidade da Ger ncia da Qualidade Al m disso com a disponibilidade das TLH e TLV s equipes de desenvolvimento conforme mencionado na se o 3 2 1 2 2 os procedimentos definidos nas T cnicas de Leitura podem contribuir aos desenvolvedores como suporte na elabora o dos artefatos das atividades de An lise e Projeto de Dom nio do processo de Engenharia de Dom nio de GURGEL 2004 5 2 TRABALHOS FUTUROS Os futuros trabalhos que podem ser realizados para melhoria do processo de GQS s o Implementar uma ferramenta de qualidade que gerencie o processo de medi o integrado aos processos Verifica o e Revis o para facilitar o trabalho de coleta de dados e evitar erros de computa o e d
191. ipal objetivo facilitar a coleta de dados que v o ser analisados posteriormente PALADINI 1994 O Diagrama de Pareto representado por barras de frequ ncia utilizado para classificar as causas de defeitos que atuam em um processo espec fico de acordo com seu grau de import ncia PALADINI 1994 A an lise de Pareto retrata o princ pio 80 20 20 das causas s o respons veis por 80 dos defeitos Este diagrama bastante aplicado na Qualidade de Software porque os defeitos do software ou densidade dos defeitos n o seguem uma distribui o uniforme HAZAN 1999 2 1 1 TESTES Os testes s o atividades de valida o e verifica o que consistem na an lise din mica do software ou seja na execu o do produto de software com o objetivo de verificar a presen a de n o conformidades cometidas ao longo do processo de desenvolvimento do software Para tal deve se construir e aplicar planos de teste capazes de identificar n o conformidades nos artefatos ROCHA et al 2001 O Plano de Teste um documento que descreve o planejamento das atividades e tarefas de teste ou seja define os objetivos do teste escopo estrat gia procedimentos do teste ambiente de teste casos de teste itens a serem testados tipos de testes a serem executados escala de teste recursos humanos relato de procedimentos crit rio de an lise riscos e plano de conting ncia Ele deve ser iniciado logo na fase de elicita o das necessidades do c
192. ique nas descri es dos outros cen rios a necessidade de armazenar o dado obtido pela intera o Caso haja necessidade preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ocorrendo aus ncia de atributo s na s classe s correspondente s do Modelo Tipo do Neg cio 2 Certifique que cada atributo tenha o mesmo nome do dado correspondente na Descri o do Cen rio e seu tipo b sico definido Caso contr rio preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsistente entre os dois II Compare os diagramas de classes para verificar se as informa es foram capturadas adequadamente ENTRADAS Modelo Conceitual do Dom nio Modelo Tipo do Neg cio SA DAS Relat rio de Discrep ncias Para cada classe do diagrama do Modelo Tipo do Neg cio execute os seguintes passos A Verifique se o nome da classe existe no Modelo Conceitual do Dom nio e se ela est utilizando o n vel adequado de abstra o 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o HI Reveja o Modelo Tipo do Neg cio para assegurar que todos os atributos relacionamentos e classes est o sendo levados em considera o ENTRADAS Modelo Tipo do Neg cio marcados com asterisco azul real ado em amarelo e sublinhado em azule verde SA DAS Relat rio de Discrep
193. itos de software de mais alto n vel por exemplo requisitos de sistema casos de uso Total de itens do aspecto verificados Total de n o conformidades 5 Aspecto Corretude Este aspecto deve analisar a corretude das funcionalidades e caracter sticas desejadas P C I 5 1 Cada necessidade verific vel por teste de qualifica o inspe o ou revis o 5 2 Cada caracter stica desejada verific vel por teste de qualifica o inspe o ou revis o 5 3 As funcionalidades evitam conflitos entre si e com todas as caracter sticas desejadas 5 4 As caracter sticas desejadas evitam conflitos entre si 5 5 As necessidades est o escritas em uma linguagem simples e concisa sem ambig idade possibilitando o completo entendimento 5 6 Cada necessidade est dentro do escopo do projeto 5 7 Cada necessidade est livre de erros de conte do e gramaticais 5 8 Todainforma o necess ria para as funcionalidades e caracter sticas desejadas est o devidamente especificadas Em caso negativo identificar no verso 5 9 Todas as necessidades podem ser implementadas dentro das restri es conhecidas 5 10 Todas as funcionalidades s o de fato funcionalidades e n o solu es de projeto ou de implementa o 5 11 As mensagens de erros especificadas s o nicas e significativas Total de itens do aspecto verificados Total de n o conformidades Restrito Instituto Militar de Engenharia P gina 3 4 140 Garantia da
194. ive based inspection PhD Thesis University of Kaiserslautern ISBN 38 16755 83 6 2000 LAITENBERGER O A survey of software inspection technologies Handbook on Software Engineering and Knowledge Engineering v 2 World Scientific Publishing 2002 LEWIS W E Software testing and continuous quality improvement 2 Edition Texas Auerbach 2000 656 p LI W HENRY S Object oriented metrics that predict maintainability The Journal of Systems and Software v 23 Nov 1993 p 111 122 MALDONADO J C Crit rios potenciais usos uma contribui o ao teste estrutural de software Campinas S o Paulo Tese de Doutorado DCA FEE UNICAMP July 1991 MCCALL J A RICHARDS P K WALTERS G F Factors in software quality v 1 2 e 3 AD A 049 014 015 055 Nat l Tech Information Service Springfield Va 1977 MCGREGOR J D SYKES D A Object oriented software development engineering software for reuse New York Van Nostrand Reinhold 1992 MCGARRY J CARD D JONES C LAYMAN B CLARK E DEAN J HALL F Practical software measurement objective information for decision makers 1 Edition Boston Addison Wesley 2001 304 p ISBN 02 01715 16 3 MEYER B Reusable Software the base object oriented component libraries Prentice Hall 1994 514 p ISBN 01 32454 99 8 120 MILLER J ROPER M WOOD M Further experiences with scenarios and checklist Journal of Empirical Software Engineering v 3 n
195. izado por um indiv duo de maneira informal Entidade reusada refere se ao tipo de objeto reusado que pode ser customizado gen rico c digo fonte de n vel abstrato e n vel de inst ncia Reuso customizado o uso de heran a de orienta o a objeto para suportar desenvolvimento incremental Uma nova aplica o pode herdar informa o de uma classe existente anular certos m todos e adicionar novos comportamentos MCGREGOR et al 1992 Reuso gen rico reuso de pacotes gen ricos como templates para pacotes ou subprogramas BIEMAN et al 1993 Reuso de c digo fonte a modifica o de baixo n vel de uma classe existente de orienta o a objeto para mudar suas caracter sticas de desempenho 125 Reuso de n vel abstrato o reuso de abstra es de n veis mais alto dentro da estrutura de heran a de orienta o a objeto como base para novas id ias ou esquemas adicionais de classifica o MCGREGOR et al 1992 Reuso de n vel de inst ncia a forma mais comum de reuso em um ambiente orientado a objeto O reuso definido como criar simplesmente uma inst ncia de uma classe existente MCGREGOR et al 1992 O reuso de uma organiza o pode ser definido por selecionar adequadamente pares ou grupos de termos Por exemplo uma organiza o pode optar por reuso sistem tico de c digo interno permitindo apenas a utiliza o da t cnica de caixa preta como parte de uma abordagem de composi o c
196. jetos OO 21 321 ve 22 Zal PERSE de Rol O e OEL TETTE ETR N N Modelos e M tricas oerirriiiiirrieiiiebiiiriiari tist ta titika N EANNA ADIA DIAS OD ain 50 3 PROCESSO DE GARANTIA DA QUALIDADE DE SOFTWARE BASEADO EM REUSO SISTEM TICO DE ASSETS sssssseseersesesesesssssossssssescecececteroreesrsrsss 52 Estrutura Organizacional do Grupo de Garantia da Qualidade de Software 55 atantindo Qualidade saite RT ar EEE A Eea Er EEE 57 Processo de Controle da Qualidade PCU cisien 60 Nivel de Ee NR as ie ld GU 60 l gico ee eo a a ESSA RODE RIA 9 UR wee ee MORRER ERR SO 62 Subpr cesso de Veritica g SE o cise cnscsdsnindsawestionsoniswonnoinsdastaandeedeconsbeastedsnesnenn 65 Subproc sso de Revis o SPR uccisioni ie EE aE 69 Subprocesso de Medi o e Avalia o SPM ssssssssssesssessseserssressrersreeseressresseee 76 Processo de Aprova o de ASSETS ie iccisicsstesessanensasienedeseaons taasaieudassdunnsassansdvacnavnsses 80 ESTUDO DE CASO vss scescesscasnonscedsdeasswssdavadececsssssedsocessknconcuvacsesscascaeseiwscascssnescses 86 Planejamento do Estudo de Caso cscs csnseecacsinga ioncd cna adcespaesixedsaeudesangoceuctesqoniiavessoaes 87 Defini o do Contexto do Estudo de CO aaa q add 87 Hip tese do Estudo ce coca ias NOIS aa asa DEAD a iai 88 Condu o do Estudo de CASO siscisinsceiasitapintiancadsadicnentadasadsag aber dastosadesdeocesedasnndedens 89 Dura
197. l e ou detalhamento adicional T mino da revis o 10 hr S preencher se N O for utilizar a tabela adicional FIG 4 2 3 2 1 b Tabela de Discrep ncia para T cnica de Leitura Horizontal 101 Detalhamento de Discrep ncia para Leitura Horizontal Projeto CT001 03 TLH TLH1 Data revis o 10 3 2003 Detalhar as discrep ncias s rias e dos tipos 5 e 6 conforme a estrutura a sequir ND Descri o Detalhada 4 Sem descri o textual do Modelo Contexto dificulta o entendimento FIG 4 2 3 2 1 c Detalhamento de Discrep ncia para T cnica de Leitura Garantia da Qualidade de Software Question rio de Sugest es para Melhoria da Garantia da Qualidade Vers o 1 0 GQQS001 04 Data da vers o 01 03 2004 QUESTION RIO DE SUGEST ES PARA MELHORIA DA GARANTIA DA QUALIDADE O Question rio de Sugest es para Melhoria da Garantia da Qualidade tem como objetivo capturar li es aprendidas nas atividades de revis es e verifica es dos artefatos e ou assets O preenchimento deste question rio n o deve ultrapassar a quinze minutos e deve ser realizado pelo verificador lider da equipe de revis o Lembre se sua contribui o muito importante 1 A verifica o revis o atingiu os objetivos dos consultores da N o pois o Modelo de Contexto n o possui uma descri o qualidade Se n o por qu textual fazendo com que n o tenha dados suficientes para valida o 2 A equipe de consultores da
198. l os testes devem ser executados por uma equipe diferente da que faz a programa o exceto os testes de unidade CROSBY 1996 LEWIS 2000 A equipe de teste testadores respons vel pela execu o dos testes e deve assegurar que o teste seja executado conforme o plano de teste ROCHA et al 2001 Cada n o conformidade detectada durante os testes deve ser documentada Assim para cada teste deve ser gerado um Relat rio de Teste e verificado o atendimento aos requisitos especificados nos casos de testes LEWIS 2000 ROCHA et al 2001 O Relat rio de Teste deve conter local e hora recursos utilizados hardware software e pessoal os resultados obtidos problemas e n o conformidades detectadas al m do n vel de adeqiiabilidade aprovado desaprovado ou aprovado com pend ncias LEWIS 2000 Atualmente no mercado existem muitas ferramentas para testes conforme apresentado em LEWIS 2000 Elas prov em rapidez na execu o execu o sem interfer ncia humana program vel repet vel reus vel e fornece an lise de cobertura de c digo depois da execu o do teste Mas os principais fatores que limitam a ferramenta de teste s o LEWIS 2000 Seo teste for executado apenas uma vez uma ferramenta de teste pode n o valer o tempo exigido e despesa Se existe press o para terminar os testes dentro de um prazo de tempo determinado uma ferramenta de teste pode n o ser apropriada pois demanda tempo para aprender configur
199. la de Discrep ncia para Leitura Horizontal Projeto c7o01 03 Tipo Leitura Horizontal TLH TLH1 Data da revis o 10 3 2003 In cio da revis o 9 hr Nome e tipo dos documentos inspecionados Doct DC010 03 Diagrama de Classe Doc2 DS01003 Diagrama de Sequ ncia ND N mero seqiiencial da discrep ncia TC Tipo de Conceito ATO ator COM comportamento HER heran a PAP papel ATR atributo CON condi o MEN mensagem REL relacionamento CAR cardinalidade DAD dado OBJ objeto classe RES restri o OUT outros tipos identificar em coment rios TD Tipo de Discrepancia 1 Presente no Doc1 e ausente no Doc2 Presente no Doc2 e ausente no Doc1 Presente em ambos documentos mas inconsistente ou amb guo Presente em ambos documentos mas usando nota o ou representa o incorreta Presente em ambos documentos mas representa informa o estranha 6 Ausente em ambos documentos Sev Severidade A N o s rio mas precisa verificar este documento B Esta discrep ncia invalida esta parte do documento Verifique ambos documentos C Es rio N o poss vel continuar a leitura deste documento Ele deve ser reorganizado Todas as discrep ncias com severidade C e do tipo 5 ou 6 devem ser explicadas na parte de Detalhamento assim como outras discrep ncias consideradas importantes ND TC Nome Sev Coment rios TD OBJ DOC 2 3 A Classe operador usu rio Nome n o OK RS Caso seja necess rio utilize a tabela adiciona
200. lado e armazenado realmente usado 13 3 Asestruturas de dados usadas podem ser melhoradas ou os algoritmos usados serem mais eficientes 13 4 O usto de recalcular um valor pode ser reduzido por um nico c lculo e armazenamento dos resultados 13 5 Existe algum c lculo que pode ser retirado de dentro de um loop 13 6 Existem testes dentro de uma oop que n o precisam ser feitos 13 7 Um pequeno loop pode ser evitado 13 8 Existem dois loops sobre os mesmos dados que podem ser combinados em um n Total de itens do aspecto verificados Total de n o conformidades Verificador Tempo de preparacao Hr Nivel de conhecimento do dominio Tempo de realiza o da verifica o Hr 0 baixo 1 m dio 2 alto Qtde linhas de c digo n o comentario Data da Verifica o ____ Assinatura Restrito Instituto Militar de Engenharia P gina 7 8 146 Garantia da Qualdade de Software Checklist Teste de Unidade Vers o 1 2 VETU001 03 Data da vers o 01 03 2004 Checklist Teste de Unidade Artefato Verificado CTTU001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero seguenci
201. lho de 2003 PAULK M C CURTIS B CHRISSIS M B WEBER C V Capability maturity model for software Version 1 1 Technical Report CMU SEI 93 TR 24 ESC TR 93 177 Software Engineering Institute Carnegie Mellon University Feb 1993 Disponivel http www sei cmu edu pub documents 93 reports pdf tr24 93 pdf capturado em fevereiro de 2003 PERRY W Effective methods for software testing as Edition New York John Wiley amp Sons Inc Oct 1999 704 p ISBN 04 71354 18 X PFLEEGER S L Software engineering theory and practice 2 Edition Nova Jersey Prentice Hall Feb 2001 659 p ISBN 01 30290 49 1 PORTER A A VOTTA L G BASILI V R Comparing detection methods for software requirements inspections a replicated experiment IEEE Transactions on Software Engineering v 21 n 6 June 1995 p 563 575 121 PORTER A A VOTTA L Comparing detection methods for software requirements inspection a replication using professional subjects Journal of Empirical Software Engineering v 3 n 4 1998 p 355 378 POULIN J S Measuring software reuse principles practices and economic models Massachusetts Addison Wesley Jan 1997 224 p ISBN 02 01634 13 9 PRESSMAN R S Software engineering a practitioner s approach 5 Edition New York McGraw Hill Nov 2001 860 p ISBN 00 72496 68 1 PRIETO DIAZ R FRAKES W B Advances in software reuse Selected papers from the Second International Wo
202. liente pois ajuda a melhorar as intera es das atividades de an lise do dom nio projeto de dom nio e codifica o ou montagem de componentes Nas fases posteriores o plano deve ser refinado com mais detalhes LEWIS 2000 A falta de um planejamento das atividades de desenvolvimento uma das causas da crise do software PRESSMAN 2001 O planejamento da atividade de teste deve estar inserido 28 dentro do planejamento do projeto onde s o estimados os recursos e definidos estrat gias m todos e t cnicas de teste para formar um crit rio de aceita o do software em desenvolvimento LEWIS 2001 Um caso de teste um conjunto espec fico de dados de teste e scripts de teste ROCHA et al 2001 O script de teste um guia para o testador na realiza o do teste e assegura consist ncia entre as partes de execu es do teste Um teste tamb m inclui resultados esperados para verificar se o teste encontrou o objetivo corretamente Durante a fase de codifica o os scripts de teste e os dados de teste devem ser gerados Na fase de aplica o de teste os scripts de teste devem ser executados e os resultados devem ser analisados Um ou mais planos de testes podem ser usados para cada tipo de teste LEWIS 2000 Segundo HARROLD 2000 a atividade de teste possui algumas limita es Dado uma segii ncia de comando identificar se executada ou n o Dados duas sequ ncias de comandos de um programa ou de programas difer
203. lificada n Total de itens do aspecto verificados Total de n o conformidades Verificador Tempo de prepara o N vel de conhecimento do dom nio Tempo de realiza o da verifica o 0 baixo 1 m dio 2 alto Qtde linhas de c digo n o coment rio Data da Verifica o Assinatura Restrito Instituto Militar de Engenharia Pagina 1 8 143 Garantia da Qualdade de Software Checklist C digo Fonte em Java Vers o 1 5 VECF001 03 Data da vers o 01 03 2004 Checklist C digo Fonte em JAVA Artefato Verificado pacote CTCF001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferende da coluna P exoeto quando n o se aplica NA a coluna Identifica o deve ser preenchida com numero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 4 Aspecto Defeito de Refer ncia de Dados Este aspecto deve verificar os defeitos de refer ncia de dados P C I 4 1 Em todos os objetos ou refer ncias de array o valor diferente de nulo s 4 2 Em todas as refer ncias de array cada valor est dentro dos limites definidos s Total de itens do aspecto verificados Total de n o c
204. localiza o espec fica durante a verifica o s Total de itens do aspecto veri ficados Total de nao confomidades 2 Aspecto Qualidade Este aspecto descreve a qualidade que as necessidades isto as fundonalidades e as caracter sticas desejadas devem apresentar no documento 2 1 As necessidades apresentam n vel de detalhamento adequado 2 2 Todas as caracter sticas de desempenho est o corretamente especificadas 2 3 Toda as considera es de seguran a est o corretamente especificadas 2 4 Outras caracter sticas desejadas de qualidade pertinentes est o explicitamente documentadas e quantificadas de acordo como objetivo espedficado s Total de itens do aspecto verificados Total de n o confomidades 3 Aspecto Completude Este aspecto descreve o que o documento deve apresentar com rela o consist ncia das necessidades e a completude destes documentos 3 1 As funcionalidades e caracter sticas desejadas prov em uma base adequada para an lise de requisitos da engenharia de dominio 3 2 O documento Necessidades do Cliente inclui todas as funcionalidades do sistema 3 3 O documento Necessidades do Cliente inclui todas as caracter sticas desejadas que o sistema precisa ter 3 4 Todas as refer ndas internas das necessidades est o corretas 3 5 As necessidades fornecem uma base adequada para o projeto 3 6 A prioridade de implementa o das necessidades est definida 3 7 Todo hardware software e inte
205. m comportamento associado ou combina o de comportamentos nas assinaturas da classe de interface correspondente identificada no passo anterior A Utilize dicas sint ticas ou seja nome de comportamento que similar ou sin nimo para uma descri o de a o para ajudar na busca Quando encontrado Restrito Instituto Militar de Engenharia P gina 1 2 166 Garantia da Qualidade de Software Leitura RELV4 II Restrito Vertical 4 Vers o 1 2 01 03 Data da vers o 03 03 2004 marque com um asterisco verde ambos os nomes do servi o na especifica o das Interfaces da Camada da Aplica o e do cen rio na Descri o dos Cen rios dos Casos de Uso do Dom nio 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois um servi o n o est presente na classe correspondente da especifica o da Interface da Camada da Aplica o 2 Certifique que o nome do servi o utilizado na classe correspondente da especifica o da Camada da Aplica o similar ou sin nimo descri o da a o sublinhada em verde e com m todo de acesso p blico Caso n o tenha um nome similar preencha a Tabela de Discrep ncia pois a descri o pode estar amb gua relatando a necessidade de conhecimento adicional para compreens o 3 Para cada dado sublinhado em azul correspondente a a o sublinhada em verde na descri o do cen rio certifique que tenha um argumento de entrada correspondente com seu tipo b sico n
206. m medidas deve ser desvinculado dos projetos subordinado rea de ger ncia de reuso e do projeto podendo estar ligado ao grupo de defini o de padr es SEI 2002 necess rio que todos tenham confian a que o uso dos dados n o ser feito contra as pessoas e para isso preciso estabelecer um protocolo claro e p blico com o compromisso da ger ncia que trang ilize a equipe e a fa a colaborar com os coletores de dados BRIAND et al 1998 Os dados coletados do trabalho de uma pessoa s 40 podem ser usados em benef cio desta pessoa Os dados que forem negativos ao desempenho profissional de uma pessoa s poder o ser tratados em car ter sigiloso com esta pessoa Os dados de erros que poder o ser divulgados s o exclusivamente aqueles dados globais consolidados ndices de erros e valores de desperd cio da equipe do desenvolvimento ou da organiza o como um todo Uma forma de aumentar a seguran a dos empregados organizar a coleta de modo que a ger ncia s observe dados agregados nunca os resultados associados a um s empregado LEWIS 2000 Segundo Jones e a Norma ISO IEC 14598 5 os procedimentos de um processo de medi o de software s o JONES 1997 PAIVA et al 2001 1 Obter apoio da alta administra o 2 Definir objetivos da medi o 3 Desenvolver um plano de implanta o 4 Definir m todos de medi o 5 Definir a coleta de dados de medi o 6 Designar profissionais que v o atu
207. ma inclusive as anomalias do processo encontradas Para identificar as causas das anomalias do processo o Grupo de M tricas pode utilizar o Diagrama de Causa Efeito PALMER 1997 Uma vez diagnosticada as causas efetivas do problema detectado elas devem ser documentadas no Relat rio de Medi o e Avalia o para que o Gerente de Reuso possa verificar e quantificar a viabilidade da mudan a do processo 3 2 2 PROCESSO DE APROVA O DE ASSETS O Processo de Aprova o de Assets consiste na aprova o dos tipos e da documenta o dos assets para que estes possam ser posteriormente classificados e armazenados nos reposit rios da biblioteca pelo Processo de Ger ncia de Assets do Processo de Desenvolvimento de Software baseado em Reuso na MD de GURGEL 2004 A documenta o do asset deve propiciar o completo entendimento aos reutilizadores do asset de forma concisa e clara Este processo inicia quando do recebimento ap s a cada vers o definida do projeto no Plano de Ger ncia do Projeto de todos os artefatos que comp e o asset com qualidade 80 aprovada pelo Processo de Controle de Qualidade e a documenta o do asset veja FIG 3 2 2 1 De posse do asset e de sua documenta o o Comit de Qualidade deve identificar o tipo de asset de acordo com a TAB 3 2 2 1 e especificar os requisitos do asset para o Subprocesso de Verifica o SPV do Processo de Controle de Qualidade PCQ validar via checklist caracter sticas de reu
208. mas n o de indicadores Al m disso a aplica o do GQM pode gerar muitas m tricas sem muita relev ncia para os respons veis pelas decis es 2 1 3 2 2 PRACTICAL SOFTWARE MEASUREMENT PSM O PSM Practical Software Measurement de MCGARRY et al 2001 um modelo para a estrutura o da medi o em um projeto de software Este modelo composto pelo Modelo de Informa o de Medi o e Modelo de Processo de Medi o O primeiro um guia de como especificar formalmente os indicadores a serem usados e o segundo um guia de como conduzir o processo de medi o O Modelo de Informa o de Medi o do PSM fornece um apoio para a defini o da Necessidade de Informa o o Goal do GQM e um guia para a partir desta chegar na especifica o da m trica Assim este modelo serve como um guia para o planejamento e implementa o das atividades de an lise e coleta de dados O Modelo de Processo 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 Este modelo foi automatizado pelo software PSM Insight O software fornece facilidades para a cria o de indicadores armazenamento de dados hist ricos e a gera o de gr ficos e relat rios para a an lise 2 2 LIDANDO COM REUSO Existem v rias abordagens para reuso veja APENDICE 1 dentre elas as duas abordagens t cnicas que mais tem se destacados nas pesquisas s o gerador
209. mento Desenvolvimento Opera o Engenharia de Dom nio e Ger ncia de Assets O trabalho aqui proposto consiste em estabelecer um embri o de um processo est vel de garantia da qualidade do software dentro desta nova abordagem reusabilidade aplicado estrutura organizacional do Minist rio da Defesa e ao Processo de Desenvolvimento de Software baseado em Reuso para MD de GURGEL 2004 Este trabalho est baseado nas defini es de padr es de processos mais utilizados atualmente pelas industrias e organiza es tais como CMM CMMI ISO 9000 ISO 12207 e ISO 15504 al m da Norma IEE1517 Os processos estabelecidos neste trabalho abrangem diferentes n veis de maturidade do CMM e CMMI Al m disso este trabalho se destina a propor um modelo de gest o de qualidade baseado na metodologia PDCA Plan Do Check Action Ciclo de Deming DEMING 1982 que inclui t cnicas e procedimentos que devem ser incorporados por todas as pessoas dos rg os de Fornecimento de Software De acordo com o N vel 3 Definido do CMM PAULK et al 1993 e o processo de apoio da Norma 12207 ABNT12207 1998 o Processo de Garantia da Qualidade de Software GQS proposto estabelece pontos de revis o e checklists nas diversas fases do Processo de Desenvolvimento de Software baseado em Reuso para MD de GURGEL 2004 atrav s de subprocessos de Revis o SPR e Verifica o SPV respectivamente veja FIG 3 1 13 Neste modelo tenta se identific
210. mento ou pela rela o no diagrama de classes 4 Seo diagrama de seqii ncia cont m restri es de tempo que poderiam afetar o estado de um objeto esteja certa que esta informa o est inclu da como uma restri o em uma classe ou rela o do diagrama de classes correspondente Para cada classe mensagem e dado identificado acima analise com base em experi ncias pr vias se este Diagrama de Intera es vi vel Por exemplo se os atributos de qualidade do projeto como coes o todos os comportamentos e atributos de uma classe realmente pertencem a esta classe acoplamento os relacionamentos entre as classes s o apropriados Verifique as seguintes discrep ncias e caso encontre as preencha a Tabela de Discrep ncia 1 Esteja certo que l gico para a classe receber esta mensagem com estes dados 2 Esteja certo que se pode verificar que as restri es s o vi veis 3 Esteja certo que todos os atributos necess rios est o definidos Se n o os diagramas podem conter fatos incorretos 4 Para as classes especificadas no diagrama de seqii ncia esteja certo que os comportamentos e atributos especificados para ela no diagrama de classes correspondente fazem sentido 5 Esteja certo que o nome da classe apropriado para o dom nio e para seus atributos e comportamentos 6 Esteja certo que os relacionamentos com outras classes s o apropriados 7 Esteja certo que os relacionamentos s o do tipo correto ou s
211. mo as reuni es poderiam melhorar 10 H necessidade de ajuda para realizar efetivamente checklist t cnica de leitura 11 H alguma outra sugest o para melhorar o Processo de Garantia da Qualidade FIG 4 2 1 4 Question rio de Sugest es para Melhoria da Garantia da Qualidade 4 2 2 ETAPA SUBPROCESSO DE VERIFICA O 4 2 2 1 PLANEJAMENTO DA VERIFICA O O Planejamento do processo de Verifica o foi realizado da seguinte forma 92 T cnica Utilizada Os modelos definidos na se o 4 2 1 e os procedimentos propostos em SPV Al da se o 3 2 1 2 1 que inclui a defini o dos checklists baseado em aspectos para os artefatos Necessidades do Cliente e Gloss rio Arquitetura de Dom nio C digo fonte e Casos de Testes de Qualifica o e os relat rios correspondentes Tempo Despendido Quatro semanas Fatores de Influ ncia Foi utilizado uma planilha de texto Microsoft Excel que atendeu inteiramente ao prop sito das listas de confer ncia checklists Avalia o dos Resultados e do Tempo Apesar da facilidade da utiliza o de uma planilha de texto a elabora o das listas de confer ncia demandou um tempo acima do estimado uma semana a mais Como as listas de confer ncias seguiram a proposta apresentada no Cap tulo 3 ent o foram preenchidos para cada artefato a ser verificado os modelos PGQSP Cronograma e Hist rico de Vers es Al m disso foram elaborados os checklists veja na se
212. n rios do Dom nio Ator sensor de navega o recebimento de dados de ambiente 1 O sensor de detec o insere dados de ambiente vento relativo velocidade relativa 2 O sistema calcula o vento real e corrente a partir dos dados de ambiente inseridos e do rumo e velocidade da plataforma prim ria 3 O sistema armazena dados calculados Cursos Alternativos Nome Tabriracompanhamento N 2 Ator sensordedetec o Trigger inser o de dados de um novo acompanhamento Pr condi o o Curso Normal 1 O sensor de detec o insere latitude e longitude da plataforma definida 2 O sistema cria novo acompanhamento e atribui n mero de acompanhamento 3 O sistema armazena os dados hist ricos de posi o 4 O sistema associa os dados ao novo acompanhamento Cursos Alternativos Nome atualizar dados da plataforma N 3 Trigger recebimento de novos dados hist ricos de posi o da plataforma j existir a plataforma 1 Osensor de detec o define a plataforma a ser atualizada 2 O sensor de detec o insere latitude e longitude da plataforma definida 3 O sistema armazena os dados hist ricos de posi o 4 O sistema calcula rumo velocidade e PMA 5 O sistema armazena os dados calculados Cursos Alternativos Passo 4 Trigger Os dados inseridos s o da plataforma prim ria a O sistema calcula rumo e velocidade b O sistema retorna ao passo 5 Passo 5 Trigger O PMA inferior dist nci
213. nejamento por revisores verificadores ou testadores treinados e sem v nculo operativo no artefato examinado PAULK et al 1993 CROSBY 1996 ABNT12207 1998 ISO15504 1998 ROCHA et al 2001 SEI 2002 As Normas CMM CMMI ABNT 12207 e ISO 15504 recomendam que os executores das atividades de verifica o e valida o n o devem ter participa o na elabora o do artefato a ser examinado PAULK et al 1993 SEI 2002 ABNT12207 1998 ISO15504 1998 As tens es entre autores e revisores dos artefatos s o apontadas na abordagem da Ger ncia pela Qualidade Total GQT como grandes fontes geradoras de conflitos que comprometem a qualidade do produto KAN 1995 Esta fonte geradora de conflito deve ser minimizada atrav s de esclarecimentos durante a etapa de treinamento da revis o e tamb m com a introdu o de um l der que exerce o papel de moderador nas reuni es de forma a eliminar ou reduzir o n mero de conflitos WIEGERS 1995 Cada atividade de verifica o e valida o deve apresentar dois resultados produto de software aceito ou rejeitado e o registro de n o conformidades e de c lculos ABNT12207 1998 Acumulando os resultados dos c lculos e analisando os o Comit de Qualidade pode determinar exatamente o estado do produto de software Ele re ne os dados provenientes das atividades de verifica o e valida o e os registra de maneira a ser de utilidade pr tica para todos os interessados A ger ncia de reu
214. nios Finalmente os 128 processos instanciados devem ser novamente instanciados para um projeto espec fico resultando no plano de desenvolvimento conforme ilustrado na FIG 7 3 1 ISOMEC 12207 IEEE 1517 CMM CMMI Caracter dicas do Desenvolvimento de Software na Organiza o Defiri o do Processo Padr o E speciali za o do Processo Padr o Tipo de Software Sidemas Especializados de Informa o a Paradigma de Desensoly mento O ou Estruturado M todo de Desenvolvimento Caracter ticas do De ensolvim ento Processos Instance iados Catactet di cas do Projeto aonograma cugo Caractet sicasda E cuipe Instancia o de Projetos Caracteri dicas da Qualidade do Desenvolvimento Especificados do Modelo de Cido de Vida Feranentas Recursos Co upa C Produto FIG 7 3 1 Modelo para defini o de processo de software Entre as normas existe a fam lia ISO IEC 9000 2000 ISO International Standart for Organizations ABNT9000 2001 ABNT9001 2001 para garantia da qualidade de software e a ISO IEC 12207 ABNT12207 1998 para estabelecimento de estrutura comum de processos de ciclo de vida de software Dentre os modelos de melhoria de processos destacam o modelo CMM Capability Maturity Model PAULK et al 1993 CMMI Capability Maturity Model Integration SEI 2002 e ISO IEC 15504 SPICE Software Process Improvement and Capability dEtermination ISO15504 1998 A vers o ISO IEC 9000 200
215. nterface da Camada de Neg cio e Tipos de Dados do Controle T tico interface IplatM gt getPrim short id criar in Posicao Posi o short idl inserirPos in Posicao Posi o short idl getPos in num Acomp short idl DadosHistorico cancelar in num Acomp short idl short idl ge tAcomp in numAcomp short idl Acompanhamento get in numAcomp short idl Vetor set in num Acomp short id in dadosPlata forma DadosPlataforma short idl ge tDa dos T ticos in numAcomp shont idl Dado sT ticos setDadosT ticos in num Acomp shori id in dadosT ticos DadosT ticos shori id getDadosConf DadosCont setDadosConf in dadosC onf DadosCont ge tDa dos Amb Dado sAm biente setDadosAmb in dados Amb DadosAm biente core Plataforma interface lhistPosMgt criar in num Acomp short idl in posicao Posi o cancelar in num Acomp short id get in numA comp short idl DadosHistorico core Hist rico Posi o numAcomp short idl dadosPlataforma Vetor Acompanhamento Plataforma Prim ria dado sC onf DadosConf dado sA mbiente Dados de Ambiente data type DadosCont imite Cen short id data type Dados os data type Data hora ano shori idl dia short idl m s short id hora short idl minuto short idl segundo short idl ma PMA ps Ve
216. o FAVARO 1996 FICHMAN 2001 JACOBSON et al 1999 POULIN 1997 SAMETINGER 1996 A utiliza o de um processo definido e gerenciado constitui um elemento fundamental para o desenvolvimento efetivo de aplica es de software Assim o processo o principal fator determinante para custo qualidade e reusabilidade Mesmo o melhor desenvolvedor n o pode ter um bom desempenho se o processo n o for bem compreendido ou seja n o estiver bem definido STAA 2002 O processo deve assegurar a utiliza o de procedimentos definidos de acordo com os crit rios de qualidade e de reusabilidade requeridos pela organiza o Desta forma o processo deve considerar a sua adequa o s tecnologias envolvidas ao tipo de software em quest o ao dom nio de aplica o ao grau de maturidade ou capacita o da equipe em engenharia de software s caracter sticas pr prias da organiza o s caracter sticas do projeto e da equipe aos pap is dos interessados stakeholders s principais atividades aos tipos e pontos de controle da qualidade Assim em geral os problemas relativos qualidade devem residir na defini o do processo e no controle dos artefatos produzidos durante o processo PAULK et al 1993 PRESSMAN 2001 SOMMERVILLE 2000 ABNT12207 1998 Asset um artefato ou conjunto de artefatos criados com o prop sito expl cito de ser reutilizado em outros esfor os de desenvolvimento 21 A Norma IEEE Institute of Electr
217. o de Contexto do Dom nio Procedimentos I Leia o documento Necessidades do Cliente e Gloss rio para entender o contexto do problema atrav s das funcionalidades e caracter sticas desejadas do cliente ENTRADAS Necessidades do Cliente e Gloss rio Modelo de Contexto do Dom nio Descri o textual do Modelo de Contexto do Dom nio SA DAS Relat rio de Discrep ncias Para cada funcionalidade ou restri o em Necessidades do Cliente execute os seguintes passos A Encontre a entidade externa que se deve relacionar e o fluxo de dados do dom nio com esta entidade Marque com um asterisco azul a entidade externa correspondente no diagrama de contexto quando encontrar 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois uma entidade externa n o est presente no modelo de contexto 2 Caso encontre baseado no conhecimento dos dom nios existentes para re so verifique se o nome da entidade externa inerente ao dom nio externo correspondente e se ela est utilizando o n vel adequado de abstra o Caso contr rio preencha a Tabela de Discrep ncia nome da entidade externa n o est adequado 3 Caso encontre verifique se todos os fluxos de dados do dom nio com esta entidade externa est o capturados Realce em amarelo os fluxos de dados e certifique que esta entidade externa com os fluxos de dados esteja devidamente documentada na descri o do Modelo de Contexto do Dom nio Caso contr rio preencha a Tabela
218. o de Fornecimento de Software para fornecer suporte na an lise dos dados consolidados Os registros de informa es data hora usu rio requerente revisores de entradas e sa das dos artefatos nos reposit rios da biblioteca e a base de dados onde s o armazenadas informa es hist ricas e vers es dos artefatos v o servir de informa o de entrada para o Processo de Medi o e Avalia o al m dos Relat rios de Testes Verifica o e Revis o 77 Estas informa es de entrada podem ser utilizadas para obten o do tamanho do artefato quantidade de reuso de assets por dom nio o n mero de altera es em um projeto quantidade de defeitos detectados economia de tempo e benef cios derivados do reuso de asset O Gerente do Projeto deve incluir requisitos de reusabilidade para assets nas especifica es de atributos de qualidade para assegurar a qualidade dos assets selecionados para reuso no desenvolvimento do produto Os crit rios para avaliar a qualidade de reusabilidade s o a confian a obtida com a experi ncia de assets reusados em projetos semelhantes os defeitos detectados como resultados de inspe o dos assets e os resultados dos testes dos componentes diante os requisitos do componente e do sistema IEEE1517 1999 Os dados coletados e armazenados durante as verifica es testes e revis es devem promover o acompanhamento da qualidade e da reusabilidade na produ o de assets como tamb m a troca de experi n
219. o de como analisar e interpretar os dados coletados deixando de utilizar suas medi es fundamental que a organiza o aloque um grupo de m tricas com conhecimento estat stico respons vel pela an lise dos dados coletados Tamb m desej vel a utiliza o de ferramentas para apoiar a an lise E ainda os dados coletados e os resultados de suas an lises devem ser armazenados em um Banco de Dados Hist rico o qual dever ser utilizado para o controle da melhoria do processo Na maioria das vezes a coleta n o pode ser completamente automatizada o que pode viabilizar a coleta de dados irreais e sem utilidade Estes dados podem levar a interpreta es err neas m s decis es e a es de melhoria inadequadas As pessoas envolvidas precisam entender por que se est coletando dados e como os dados ser o utilizados importante que as pessoas conhe am o prop sito para o qual os dados est o sendo coletados e que os dados realmente sejam utilizados para o prop sito informado importante que os profissionais entendam que o sucesso do processo de medi o depende das equipes para coletar dados e estes dados devem ser acurados eles n o ser o avaliados com base nestes dados e se eles reportarem dados viciados dados que destor am o real desempenho para este parecer melhor ser obtido um banco de dados baseado em dados distorcidos e isto pode ser pior do que n o ter nenhum dado O Grupo de M tricas especializado e
220. o deve atualizar o Plano de Ger ncia do Projeto conforme o resultado da revis o O Consultor de Qualidade deve acompanhar as corre es apontadas no Relat rio de Revis o se est o sendo realizadas eficazmente e conforme a data estabelecida no Relat rio de Revis o realizar nova revis o se necess rio para verificar as corre es e se defeitos secund rios n o foram introduzidos As n o conformidades resolvidas e aprovadas devem constar no Relat rio de Revis o E os resultados das atividades de revis o devem ser disponibilizados para a equipe de desenvolvimento montadores engenheiros de dom nio cliente e gerente de projeto 3 2 1 2 3 SUBPROCESSO DE MEDI O E AVALIA O SPM O Processo de Medi o e Avalia o tem o prop sito de definir procedimentos para medir e julgar al m do n vel de reusabilidade a qualidade do produto ou artefato quanto aos requisitos e satisfa o do cliente Este subprocesso abrange cinco atividades que s o apresentados no diagrama da FIG 3 1 2 3 1 ALMEIDA et al 2003 An lise de Requisitos Especifica o da Avalia o Planejamento da Avalia o Execu o da Medi o e Avalia o SPR SUBPROCESSO MEDI O E AVALIA O 1509126 1 2000 Crit rios de reusabilidade Necessidades explicitase implicitas An lise de Requisitos alia Manual da SEAI objetiv osda Qualidade avalia o Crit rios de avalia o M tricas Consultor d
221. o do Interfaces da Camada de Neg cio e Tipos de Processo ao Longo do Projeto Dados Interfaces da Camada de Aplica o Arquitetura de Dom nio Diagrama de Intera es Especifica o de Componente de Dom nio T rmino da atividade Projeto de Dom nio do Interfaces dos Componentes de Dom nio Processo ao Longo do Projeto Ap s um dia til do recebimento o expositor alocado ao conjunto de artefatos a ser revisado deve treinar o grupo revisor Em seguida este grupo juntamente com o grupo autor devem se preparar para revis o t cnica conforme as respectivas atividades SPR A2 e SPR A3 especificadas mais adiante Durante esta prepara o aplicada a T cnica de Leitura Vertical TLV e Horizontal TLH para inspecionar os artefatos conforme s o apresentados na FIG 3 2 1 2 2 2 A inspe o de cada artefato n o deve ultrapassar mais de uma hora A reuni o da revis o deve ser realizada no dia seguinte da execu o das inspe es do conjunto de artefatos recebidos para ser revisado Esta reuni o n o deve demorar mais do que duas horas A equipe de revis o deve ser composta pelo grupo revisor grupo autor um l der um secret rio e um expositor conforme estabelecido na atividade de Planejamento SPR A1 11 Descri o das Necessidades do Cliente Gloss rio An lise de Dom nio Modelode Modelo Modelo de Casos de Uso Modelode Contextodo Concei
222. o e o planejamento do trabalho Ela deve zelar pela qualidade em termos de determinar o que fazer para que o todo alcance os resultados propostos CROSBY 1996 Para isto um Comit de Qualidade deve ser formado por consultores da qualidade para apoiar as equipes de desenvolvedores montadores de projetos nas avalia es da qualidade dos artefatos produzidos durante todo processo de ciclo de vida do projeto determinando de que modo o produto deve ser verificado inspecionado testado e controlado no decorrer de sua vida dentro e fora da organiza o ROCHA et al 2001 Este comit deve tamb m ajudar na identifica o dos atributos de qualidade necess rios para que cada um dos projetos alcance seus objetivos e a equipe de desenvolvedores montadores enfoque no desenvolvimento de software baseado no reuso IEEE 1517 1999 A garantia da qualidade somente pode ser assegurada se existir um padr o de especifica o confi vel e seguido e tamb m controlado de forma sistem tica O grupo de garantia da qualidade de software deve utilizar t cnicas ferramentas m todos padr es 26 normas processos e bases de dados para apoiar os diversos projetos de software Ele deve apoiar a equipe de desenvolvimento de software por meio de verifica es e valida es que permitem avaliar os artefatos produzidos ABNT12207 1998 ISO15504 1998 ROCHA et al 2001 FIORINI et al 1998 A avalia o deve ser planejada e realizada conforme o pla
223. o na se o 3 2 1 2 3 E o c lculo das fun es de medi o relativo aos indicadores foi realizado conforme definidas no Planejamento da Medi o Tempo Despendido Uma semana Fatores de Influ ncia Como os artefatos Plano de Teste e Testes Teste de Unidade Teste de Integra o Teste de Interface Gr fica e Teste de Valida o n o foram elaborados formalmente estes n o puderam ser avaliados pelo Grupo de GQS Avalia o dos Resultados e do Tempo Na aplica o do indicador IQPVR Indicador de Qualidade do Processo de Verifica o e Revis o ocorreu uma dificuldade quanto medi o da quantidade de n o conformidades resolvidas no prazo pois o cronograma do projeto piloto estava muito alto n vel de forma que n o se pode distinguir quantidade de n o conformidades resolvidas no prazo ou fora do prazo Na TAB 4 2 4 2 1 apresentada resumidamente os resultados da coleta de dados para os indicadores IQPVR e IPPVR TAB 4 2 4 2 1 Resultados da Coleta de Dados dos Checklits e T cnicas de Leitura Checklists Necessidades do Cliente C digo fonte Arquitetura e Gloss rio 2 quantidade de n o conformidade severidade 7 7 7 21 Dura o 45 minutos 40 minutos 35 minutos 120 minutos 109 T cnica de Leitura Horizontal 2 quantidade de n o conformidade severidade 6 11 4 2 0 23 Dura o 40 minutos 45 minutos 65 minutos 35 minutos 40 minutos
224. o projeto FxP Objetivo controlar a capacidade do projeto de ser adaptado para fornecer funcionalmente uma capacidade espec fica Quest es M tricas 1 Qual a capacidade do projeto de adapta o a Acoplamento direto da classe uma necessidade espec fica Medida de agrega o Medida de acesso aos dados N mero de m todos polimorfos e Funcionalidade do projeto FuP objetivo controlar a capacidade funcional do projeto l Quest es M tricas 1 Qual o percentual de servi os do projeto que Coes o entre m todos na classe est o dispon veis atrav s de suas interfaces N mero de hierarquia p blicas Tamanho da interface da classe N mero de m todos polimorfos Tamanho do projeto em classes f Reusabilidade do projeto RP Objetivo controlar a capacidade do projeto de ser reutilizado em outros dom nios Quest es M tricas 1 Qual o percentual do projeto ser reaplicado para Acoplamento direto da classe um novo dom nio de problema Coes o entre m todos na classe Tamanho da interface da classe Tamanho do projeto em classes De acordo com a TAB 2 2 3 1 2 e TAB 2 2 3 1 3 na TAB 4 2 4 1 3 s o apresentadas as m tricas que medem as propriedades de projeto que atuam diretamente nas fun es de c lculo da medi o para cada um dos objetivos que se encontram definidas na TAB 4 2 4 1 4 A seguir uma descri o mais detalhada das m tricas apresentadas na TAB 4 2 4 1
225. o proposto em GURGEL 2004 Para tal foi desenvolvido um projeto piloto Controlador T tico para possibilitar na medida do poss vel a avalia o do processo de desenvolvimento baseado em reuso de GURGEL 2004 e os poss veis ganhos na qualidade e reusabilidade advindos da utiliza o da estrat gia aqui proposta Baseado no guia para estudo de caso de Kitchenham et al o estudo de caso apresentado neste cap tulo segue as etapas de Planejamento Monitora o e Avalia o KITCHENHAM et al 1995 O Planejamento consiste nas seguintes defini es para o estudo de caso contexto hip tese condu o dura o participante e objetivos a serem atingidos J a Monitora o o acompanhamento da realiza o das atividades de cada processo que comp e o processo de Garantia da Qualidade de Software proposto Al m de uma breve informa o sobre o acompanhamento apresentado um quadro de monitora o contendo a t cnica utilizada o tempo despendido os fatores de influ ncia condi es facilidades dificuldades e ou limita es encontradas e an lise dos resultados obtidos e do tempo A ltima etapa Avalia o consiste na an lise e interpreta o dos resultados obtidos na etapa anterior 4 1 PLANEJAMENTO DO ESTUDO DE CASO 4 1 1 DEFINI O DO CONTEXTO DO ESTUDO DE CASO O projeto piloto Controlador T tico foi realizado baseado no projeto real TTI Terminal T tico Inteligente do IPqM Instituto de Pesquisa
226. o tenha para cada relacionamento encontre a interface correspondente que deve estar representada na especifica o do componente identificado no passo anterior em nota o lollipop Realce em verde o nome desta s interface s na especifica o do componente Caso n o consiga encontrar a s depend ncia s desta s interface no componente em quest o preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsist ncia entre os dois Il Reveja as especifica es dos componentes para assegurar que todas as classes e seus relacionamentos especificados no diagrama arquitetural do dom nio est o sendo levados em considera o ENTRADAS Especifica o de Especifica o de Componentes marcado com asterisco azul e real ado em verde Arquitetura do Dom nio SA DAS Relat rio de Discrep ncias A Reveja os componentes para ter certeza que todas as classes e seus relacionamentos da Arquitetura do Dom nio est o corretamente capturados na Especifica o de Componente 1 Certifique que n o existe nenhuma classe de especifica o de componente sem asterisco azul Caso exista alguma preencha a Tabela de Discrep ncia pois uma especifica o de componente n o est presente na Especifica o de Especifica o de Componentes Restrito Instituto Militar de Engenharia P gina 1 1 169 8 ANEXOS 8 1 ANEXO 1 PROPOSTA DO PROCESSO DE CICLO DE VIDA DO SOFTWARE BASEADO EM REUS
227. om reuso focado dentro de seus dom nios vertical 126 7 2 AP NDICE 2 RESUMO DOS PRINCIPAIS MODELOS E M TRICAS TAB 7 2 1 Resumo das principais m tricas e modelos de reuso de software M tricaModelo Fonte Descri o An lise de custo e benef cio Modelo de Custo Produtividade Gaffney Durek GAFFNEY 1989 Modelo simples C custo de desenvolvimento de software R propor o de c digo de reuso no produto b custo relativo a todo novo c digo de incorporar c digo reusado no produto C b 1 R 1 para todo b gt 1 e produtividade P 1 C Modelo de desenvolvimento de custo E custo de desenvolver um componente reus vel relativo ao custo de produzir um componente que n o seja reusado n n mero de uso em que o custo do c digo ser amortizado Custo C b E n 1 R 1 para todo n gt 1 Qualidade de Barnes Bollinger Qualidade de investimento Q a raz o dos benef cios B sobre investimento BARNES et al investimento de reuso R Q B R 1991 Se Q lt 1 ent o o esfor o de reuso resultou em perda Se Q gt 1 ent o o investimento forneceu bom retorno Modelo esfor o e Jacobson Custo custo JACOBSON et al Fuso Custo de reuso de um componente varia de 0 10 a 0 25 1997 em geral usa se a m dia aproximada 0 2 como padr o Fcriar Custo de criar e gerir um componente reus vel ROI Retorno de investimento com reuso de componentes ROI n 1 Fuso Feria
228. onformidades 5 Aspecto Defeito de O peradores Relacionais Este aspecto deve verificar os defeitos de express es l gicas CI 5 1 Em todos os testes booleanos a condi o correta checada 5 2 Os operadores de compara o est o corretos 5 3 Cada express o booleana foi simplificada resultante de procedimento de nega o 5 4 Cada express o booleana est correta 5 5 Existem efeitos colaterais impr prios de uma compara o 5 6 T m um amp inadvertidamente trocado por um amp amp ou um por um n Total de itens do aspecto verificados Total de n o conformidades 6 Aspecto Defeito de Fluxo de Controle Este aspecto deve verificar os defeitos de controle de estruturas de la o de repeti o e condicionais 6 1 Cada loop utiliza a melhor escolha de la o de repeti o 6 2 Todos loops terminam 6 3 Quando h v rias sa das de um 00p cada sa da necess ria e controlada corretamente 6 4 Cada estrutura switch case tem um caso default 6 5 Afaltadadeclara o break na estrutura switch case est correta e comentada 6 6 As declara es break desviam o controle para o local coreto 6 7 Oaninhamento de v rias estruturas if else est coreto As estruturas nulas de controle est o corretas e comentadas 6 9 Todas as exce es s o controladas adequadamente 6 10 Todos os m todos terminam 6 11 Oaninhamento de estruturas if else pode ser convertido em uma estrutura switch case n Total de itens do asp
229. onograma e Hist rico de Vers es Al m disso foram elaborados as T cnicas de Leitura Horizontais e Verticais de acordo com o artefato a ser inspecionado veja se es 7 4 2 e 7 4 3 do AP NDICE 4 e o modelo de Relat rio da Revis o Na FIG 4 2 3 1 1 a apresentado um dos modelos da T cnica de Leitura Vertical TLV1 e em b o modelo de Relat rio da Revis o 98 Garantia da Qualidade de Software Leitura Vertical 1 Vers o 1 2 RELV101 03 Data da versao 03 03 2004 1 Caso encontre verifique se todos os fluxos de dados do dominio com esta entidade externa est o capturados Realce em amarelo os fluxos de dados e certifique que esta entidade externa com os fluxos de dados esteja devidamente documentada na descri o do Modelo de Contexto do Dom nio Caso contr rio preencha a Tabela de Discrep ncia falta ou est incom pleta fluxo de dados no modelo de contexto ou sua descri o Para cada fluxo de dado identificado verificar seo nome est no padr o todo em min sculo e o mesmo utilizado pela entidade externa Caso contr rio preencha a Tabela de Discrep ncia nome do fluxo de dados n o est adequado B Verifique se todas as necessidades est o sendo encapsuladas dentro do escopo do dom nio 1 Certifique que o mesmo conjunto de necessidades esteja presente na descri o do contexto do dom nio Caso contr rio preencha a Tabela de Discrep ncia pois informa o est presente em um documento mas aus
230. ontadores engenheiros de dom nio cliente e gerente de projeto 3 2 1 2 2 SUBPROCESSO DE REVIS O SPR O Subprocesso de Revis o tem o prop sito de estabelecer as atividades voltadas para o Controle da Qualidade que devem ser aplicadas medida que um conjunto de artefatos de especifica o de requisitos e de projeto de arquitetura produzido na Engenharia de Dom nio para avaliar tecnicamente os artefatos das atividades de An lise e Projeto de Dom nio proposto em GURGEL 2004 As atividades deste subprocesso devem implementar reuni es conjuntas com inspe es individuais baseadas na T cnica de Leitura Horizontal e Vertical Os artefatos inspecionados s o Modelo de Contexto do Dom nio Modelo Conceitual do Dom nio Modelo de Casos de Uso do Dom nio e Descri o dos Cen rios Modelo de Caracter sticas Modelo de Neg cio Interfaces da Camada de Neg cio Interfaces da Camada de Aplica o Diagrama de Intera es Arquitetura de Dom nio e Especifica o de Componentes do Dom nio Este subprocesso abrange quatro atividades que s o apresentadas no diagrama da FIG 3 2 1 2 2 1 Planejamento SPR Al Treinamento para Revis o T cnica SPR A2 Prepara o para Revis o T cnica SPR A3 e Revis o T cnica SPR A4 69 SPR SUBPROCESSOREVIS O Modelo Modelo Modelo PGQSP TLH e TLV Relat rio N o Conformidades Manual da Qualidade Plano de Revis o Plano de Ger ncia Planejamento Cronogr
231. ontua o e crit rios de avalia o A cada nova vers o do projeto conforme o Plano de Ger ncia do Projeto o Consultor de Qualidade alocado ao projeto deve enviar todos os relat rios de Verifica o e Revis o realizados no per odo da vers o anterior correspondente para o Grupo de M tricas Este grupo deve medir e analisar os dados coletados destes relat rios e dos artefatos produzidos e deve enviar um Relat rio de Medi o e Avalia o juntamente com todos os Relat rios de Verifica es e Revis es aos Gerentes de Reuso e do Projeto uma semana ap s da prontifica o da vers o importante ressaltar que todos os produtos de qualidade gerados neste subprocesso devem ser incorporados no Manual da Qualidade Portanto o Gerente de Projeto deve obter os dados do plano de medi o e avalia o e cronograma da revis o para o Plano de Ger ncia do Projeto via Manual da Qualidade Neste processo deve ser adotada a abordagem GQM Goal Question Metric de BASILI et al 1994 para definir um processo de coleta e an lise de dados Primeiro deve se estabelecer uma refer ncia para avaliar o progresso em termos dos objetivos e atrav s de compara o com esta refer ncia Assim ap s a cada nova refer ncia no reposit rio da biblioteca deve ser avaliada a qualidade e a reusabilidade do produto pelo Grupo de M tricas O Grupo de M tricas deve ser formado por especialistas em estat sticas que perten am ao rg o Descentralizad
232. organization for business success 1 Edition Boston Addison Wesley 1997 528 p JACOBSON I BOOCH G RUMBAUGH J The unified software development process 1 Edition Boston Addison Wesley 1999 463 p JONES C Assessment and control of software risks 1 Edition New York Prentice Hall 1994 464 p JONES C Applied software measurement assuring productivity and quality 2 Edition New York Prentice Hall 1997 618 p JURAN J M Planejando para a qualidade 2 Edi o S o Paulo Editora Pioneira 1990 394 p 119 KAN S H Metrics and models in software quality engineering Addison Wesley 1995 361 p KARLSSON E A Software reuse a holistic approach 1 Edition John Wiley amp Sons Jan 1995 528 p ISBN 04 71958 19 0 KARNER G Metrics for objectory Master Thesis Report LiTH IDA Ex 9344 Link ping Sweden 1993 KITCHENHAM B PICKARD L PFLEEGER S L Case studies for method and tool evaluation IEEE Software Los Angeles v 12 n 4 Jul 1995 p 52 62 KOLTUN P HUDSON A A reuse maturity model In Fourth Annual Workshop on Software Reuse Herndon VA 1991 KRUEGER C W Software reuse Computing Surveys v 24 n 2 June 1992 p 131 183 LAITENBERGER O DEBAUD J M Perspective based reading of code documents at Robert Bosch GmbH Information and Software Technology v 39 1997 p 781 791 LAITENBERGER O Cost effective detection of software defects with perspect
233. ormidade IEEE610 12 1990 GARANTIA DA QUALIDADE Conjunto de atividades planejadas e sistem ticas implementadas no sistema da qualidade e demonstradas como necess rias para prover confian a adequada de que uma entidade atender os requisitos para a qualidade ISO8402 1994 MODELO DE DOM NIO Um produto da an lise de dom nio que prove uma representa o dos requisitos do dom nio O modelo de dom nio identifica e descreve a estrutura dos dados fluxo de informa es fun es restri es e controles do dom nio que s o inclu dos no sistema de software dentro do dom nio O modelo de dom nio descreve as semelhan as e varia es entre os requisitos dos sistemas de software no dom nio NIST 1994 NAO CONFORMIDADE N o atendimento de um requisito ABNT9000 2001 PROCEDIMENTO s m Forma espec fica de executar uma atividade ou um processo ISO9000 2001 PROCESSO DE SOFTWARE Conjunto de atividades m todos pr ticas e transforma es que as pessoas empregam para desenvolver e manter software e os produtos 186 associados por exemplo planos de projeto documentos de projeto c digo casos de teste manual do usu rio ISO8402 1994 QUALIDADE s f Grau no qual um conjunto de caracter sticas inerentes satisfaz a requisitos ISO9000 2001 RASTREABILIDADE s f Capacidade de recuperar o hist rico a aplica o ou a localiza o daquilo que est sendo considerado ABNT9000 2001 RE
234. p 39 57 GAFFNEY J E Jr DUREK T A Software reuse key to enhanced productivity some quantitative models Information Software Technology German v 31 n 5 1989 p 258 267 GILB T GRAHAM D Software inspection 1 Edition Massachusetts Addison Wesley 1993 496 p GIORARDI R Main approaches to software classification and retrieval em Cursos Complementares 1998 Ingenier a de Software y Reutilizaci n Aspectos Din micos y Generaci n Autom tica Universidade de Vigo Santiago 1998 GURGEL M S Estudo do desenvolvimento de software baseado em reuso no contexto do Minist rio da Defesa e de seus comandos subordinados Disserta o de Mestrado Instituto Militar de Engenharia IME 2004 HARROLD M J Testing a roadmap In The Future of Software Engineering Finkelstein A ed 22 International Conference on Software Engineering 2000 10 p HAZAN C Metodologia para o uso de indicadores na ger ncia de projetos de desenvolvimento de software Tese de Mestrado Instituto Militar de Engenharia IME 1999 HEINEMAN G T COUNCIL W T Component based software engineering putting the pieces together 1 Edition Addison Wesley May 2001 416 p 118 HENNINGER S Using software process to support learning organizations In Proceedings of the Workshop on Learning Software Organizations Kaiserslaurten Germany 1999 HITZ M MONTAZERI B Chidamber and Kemerer s metrics suite a measurement
235. pe es s o Verificar se o artefato examinado satisfaz as suas especifica es e se est em conformidade com os padr es aplic veis Identificar desvios de padr es e especifica es Coletar dados de engenharia de software como dados de esfor o e defeitos A inspe o de software possibilita a detec o e a remo o de defeitos em artefatos assim que estes s o criados LAITENBERGER 2002 FAGAN 1986 DOOLEAN 1992 Na FIG 2 1 2 1 apresentada curvas de desenvolvimento de software em rela o a escala de tempo com e sem inspe o FAGAN 1986 EM P Inspe es 1 R We a E O aig cai n a 8 OM Recurso H hspe es Humano i e i e t Ea O ep 7 do Design mp oditicato te Testes dede ren a Escala de Tempo de Desenvolvimento FIG 2 1 2 1 Compara o de desenvolvimento de software com e sem inspe es As inspe es de software precisam estar integradas ao processo de desenvolvimento de software Assim a inspe o deve ser adequada para cada etapa de desenvolvimento do 32 projeto Na FIG 2 1 2 2 apresentado o Modelo V de Vorgehens Modelo de Produto que relaciona o produto desenvolvido e a inspe o de software BROHL 1995 aplic vel a qualquer tipo de desenvolvimento de software sequencial em paralelo ou de modo incremental Descri o de problema W Sistema usado R Necessidades do cl
236. pecto verificados Total de n o conformidades 3 Aspecto Padr es e Rastreabilidade Este aspecto deve verificar as quest es de adequa o aos padr es de design e arquiteturais rastreabilidade das necessidades e caracter sticas desejadas 3 1 Todos os padr es de arquitetura foram seguidos 3 2 De qualquer parte da arquitetura as necessidades podem ser rastreadas 3 3 Os padr es de componentes est o sendo usados sempre que poss veis s Total de itens do aspecto verificados Total de n o conformidades 4 Aspecto L gica Este aspecto descreve o que o documento deve apresentar com rela o consist ncia das necessidades e a completude destes documentos P C I 4 1 H alguma l gica perdida ou incompleta s 4 2 Todos os poss veis casos est o sendo considerados s Total de itens do aspecto verificados Total de n o conformidades 5 Aspecto Interface e Clareza Este aspecto deve verificar as interfaces de cada componente das camadas e inter camadas ea objetividade e clareza do diagrama arquitetural Todas as interfaces est o claras e bem definidas Os m nimos dados s o passados a cada interface Os m nimos dados globais de sistema s o inclu dos A arquitetura est claramente representada inclusive o fluxo de dados controle de dados e interfaces As representa es do projeto est o consistentes entre si Todas as decis es de pend ncias e suposi es para este projeto est o devidamente documentadas
237. pons vel para executar o Processo de Ger ncia de Asset o gerente de asset 138 7 4 AP NDICE 4 CHECKLISTS E T CNICAS DE LEITURA 7 4 1 ARTEFATOS CHECKLISTS Garantia da Qualdade de Software Checkist Necessidades do Cliente e Gloss rio Vers o 1 5 VENC001 03 Data da vers o 01 03 2004 Checklist Necessidades do Cliente e Gloss rio Artefato Verificado CTNC001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 1 Aspecto Apresenta o do Documento Este aspecto deve analisar as quest es gerais de apresenta o do documento 1 1 O documento est de acordo como template padr o 1 2 O documento teve ortografia e gram tica checada 1 3 O documento est livre de erros de layout 1 4 O gloss rio disp e de todas as defini es e explica es que o revisor necessita para o completo entendimento das necessidades e caracter sticas desejadas 1 5 Os n meros das linhas do texto do documento est o impressos para facilitar a refer ncia de
238. prop e de acordo com a abordagem estabelecida em GURGEL 2004 uma estrutura organizacional para o Grupo da Garantia da Qualidade de Software GQS Comit de Qualidade do rg o Descentralizado de Fornecimento de Software 1 Grupo da Garantia da Qualidade de Software GGQS 1 Legenda Grupo de M tricas 1 Alocado no rg o Central de Ger ncia de Re so Comit de Qualidade do rg o Descentralizado de Fornecimento de Software n Alocado em cada rg o Descentralizado de Fornecimento de Software Grupo da Garantia da Qualidade de Software GGQS n Lo Grupo de M tricas n FIG 3 1 1 Estrutura da rea do Grupo da Garantia da Qualidade de Software GGQS Na FIG 3 1 1 est representada uma organiza o estrutural do Grupo da GQS Garantia da Qualidade de Software onde um Grupo de GQS Corporativo deve ser centralizador para ser os olhos e ouvidos da Ger ncia de Reuso e a este grupo v rios Comit s de Qualidade devem estar subordinados O objetivo destes comit s garantir a reusabilidade e qualidade no desenvolvimento de software nas diversas organiza es fornecedoras Para cada comit devem existir dois grupos subordinados um Grupo de GQS e um Grupo de M tricas O Grupo de GQS consiste na verifica o e inspe o de artefatos assets produzidos no processo de desenvolvim
239. que eles t m os atributos desejados JACOBSON et al 1997 FICHMAN 2001 Medir progressos do reuso baseado em m tricas relevantes que possam ajudar na otimiza o do programa de reuso sempre que necess rio FRAKESD et al 1996 Incluir verifica es de reuso nas revis es de projeto e inspe es IEEE1517 1999 2 2 1 PROCESSO DE REUSO O processo de reuso deve maximizar reuso e minimizar esfor os b sicos de desenvolvimento Ent o o primeiro passo no processo de reuso encontrar e selecionar assets adequados Para efetivo reuso deve ser mais f cil achar assets que os desenvolver para nico uso JACOBSON et al 1997 Ao encontrar os assets adequados n o significa ter achado exatamente o que precisa Localizar assets semelhantes pode ser suficiente Depois que os assets foram encontrados eles devem ser entendidos para serem reusados Achar e entender est o relacionados porque para selecionar um asset para reuso deve se saber o que ele faz Entender fica mais importante quando o asset tiver que ser modificado Assim a documenta o adequada fundamental para este passo Naturalmente restri es legais podem proibir a disponibilidade da implementa o de um asset e podem permitir seu reuso somente como uma caixa preta IEEE 1517 1999 Construir um sistema de software sem precisar modificar os assets o ideal Geralmente pelo menos alguns dos assets devem ser adaptados s necessidades espec ficas do sistema de
240. r Feriar Esfor o de sistema de aplica o com reuso PF ponto de fun o para tamanho do software Tempo de desenvolvimento PF m s Tamanho da equipe de desenvolvimento gerentes testadores e documentadores Esfor o PF 150 homem m s Potencial de erros F Custo de desenvolvimento Esfor o custo de homem m s PF 150 inclui Avalia o da maturidade Modelo de maturidade de reuso Koltun Hudson KOLTUN et al 1991 Modelo de maturidade de reuso para nivelar procedimentos de uma organiza o por trabalhar para reuso de software Consiste em uma tabela com 5 fases de maturidade de reuso Inicial Ca tico Monitorado Coordenado Planejado Enraizado por 10 dimens es Motiva o cultura Planejamento para reuso Abrang ncia Responsabilidade de execu o Ponto de partida para reuso Assets reus veis Esquema de classifica o Suporte tecnol gico M tricas Considera es legais ou contratuais No cruzamento da linha com a coluna da tabela disp e da descri o dos aspectos que devem corresponder aos procedimentos da organiza o Modelo de capacidade de reuso Cons rcio de Produtividade de Software DAVIS 1993 O Cons rcio de Produtividade de Software identifica 4 est gios no modelo de implementa o da crescente redu o de risco para reuso de software Oportuno Integrado Influenciado e Adiantado Cada est gio apresenta um conjunto de aspectos que por meios des
241. r ncia de Projeto Para cada refer ncia estabelecida pelo Plano de Ger ncia de Projeto este processo deve especificar os itens a serem verificados revisados e armazenados de acordo com o Manual da Qualidade do Projeto e o Plano de Garantia da Qualidade do Software do Projeto PGQSP Este plano deve ser implementado e mantido durante a vig ncia do Contrato do Projeto ABNT12207 1998 ABNT9000 2001 e deve estabelecer os seguintes itens Respons vel pelas atividades de GQS no projeto identifica o nome do consultor de GQS alocado ao projeto pelo Comit de Qualidade Padr es e procedimentos para as atividades de GQS o consultor de GQS deve utilizar na execu o das atividades de GQS no projeto de software e na realimenta o acerca destas atividades os padr es e procedimentos estabelecidos no Plano de Ger ncia do Projeto vers o lt X X gt As responsabilidades e autoridade do grupo de GQS devem estar definidas no Documento de Implementa o de GQS do rg o Militar 17 Este artefato produto da atividade Prepara o do Plano de Ger ncia de Projeto do Processo de Fornecimento proposto por GURGEL 2004 Veja ANEXO 1 S Este artefato produto do Processo de Aquisi o proposto por GURGEL 2004 Veja ANEXO 1 58 Padr es e procedimentos de projeto informa os padr es e procedimentos que devem ser seguidos pelo projeto de software a ser verificado revisado pelo verificador revisor no Plano de Ger nc
242. r de Engenharia P gina 1 1 FIG 4 2 3 2 1 d Question rio de Sugest es para Melhoria da Garantia da Qualidade QSMGQ preenchido pelo revisor de TLH1 4 2 4 ETAPA SUBPROCESSO DE MEDI O E AVALIA O 4 2 4 1 PLANEJAMENTO DA MEDI O O Planejamento do processo de Medi o foi realizado da seguinte forma T cnica Utilizada Foi utilizado o modelo GQM Goal Question Metric de Basili veja se o 2 1 3 2 1 para constru o dos indicadores e tamb m com base na Constru o Mensur vel do PSM Practical Software Measurement de McGarry et al veja se o 102 2 1 3 2 2 para elabora o da especifica o dos indicadores foram estabelecidos os itens chaves Tempo Despendido Duas semanas Fatores de Influ ncia A utiliza o de um editor de texto MS Word atendeu ao prop sito da elabora o dos formul rios para especifica o dos indicadores e implanta o da metodologia GQM Avalia o dos Resultados e do Tempo A elabora o dos indicadores foi voltada para avaliar a qualidade dos artefatos dos processos de Engenharia de Dom nio e Desenvolvimento de GURGEL 2004 que comp e os assets produzidos por estes processos como tamb m avaliar o processo de controle de qualidade quanto s inspe es realizadas via checklist ou t cnicas de leitura e sua produtividade Os objetivos apresentados s o os Goals que a partir destes foram levantadas as Questions para se chegar s m tricas relati
243. r na pesquisa mas esteja certo que o significado sem ntico dos conceitos na caracter stica e classe seja o mesmo Marque com asterisco azul a s classe s correspondente s na Arquitetura do Dom nio 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois h caracter stica que n o est presente na Arquitetura de Dom nio ou h inconsist ncia entre os dois 2 Para cada caracter stica identificada certifique que suas rela es representadas por linha cont nua ou tracejada no Modelo de Caracter sticas estejam sendo capturadas no diagrama arquitetural do dom nio Caso n o contr rio preencha a Tabela de Discrep ncia pois h rela es entre caracter sticas que n o est presente na Arquitetura do Dom nio ou h inconsist ncia entre os dois WI Reveja na Arquitetura do Dom nio se todos as classes de cada camada est o sendo levadas em considera o ENTRADAS Arquitetura do Dom nio marcada com asterisco azul SA DAS Relat rio de Discrep ncias A Revejase as classes est o corretamente capturadas na Arquitetura do Dom nio 1 Certifique que n o existe nenhuma classe sem asterisco azul Caso exista alguma verifique se est utilizando um padr o de projeto adequado Caso contr rio preencha a Tabela de Discrep ncia pois h classe que n o deveria ser definido desta maneira relatando a necessidade de conhecimento adicional para compreens o Restrito Instituto Militar de Engenharia P gina 1 1
244. r o diagrama de intera o correspondente verifique se as intera es entre as classes deste diagrama est o sendo representadas por linhas pontilhadas como depend ncias entre componentes Caso contr rio preencha a Tabela de Discrep ncia pois h informa o em um diagrama que n o est presente em outro ou h inconsist ncia entre os dois HI Reveja a Arquitetura de Dom nio com marca o de asterisco azul e verde e realce amarelo para assegurar que todos os componentes e suas depend ncias est o sendo levados em considera o ENTRADAS Diagrama das Intera es dos Componentes marcado com asterisco azul e verde e Restrito depend ncias real adas em amarelo SA DAS Relat rio de Discrep ncias C Reveja na Camada de Neg cio da Arquitetura de Dom nio se todos componentes de neg cio est o especificados 1 Certifique que n o existe nenhuma especifica o de componentes sem asterisco azul Caso exista algum preencha a Tabela de Discrep ncia pois um servi o de interface n o deveria ser definido desta maneira relatando a necessidade de conhecimento adicional para compreens o Reveja na Camada de Aplica o da Arquitetura de Dom nio se todos componentes da aplica o est o especificados 1 Certifique que n o existe nenhuma especifica o de componentes sem asterisco verde Caso exista algum preencha a Tabela de Discrep ncia pois um servi o de interface n o deveria ser definido desta maneira relatan
245. rdware software e ferramentas necess rios para realiza o das revis es acordados pelos grupos revisor e autor SPR A1 4 Para cada revis o acordado pelos grupos revisor e autor agendar as atividades pertinentes treinamento prepara o e revis o t cnica e de gest o SPR A2 TREINAMENTO PARA REVIS O T CNICA A atividade Treinamento para Revis o T cnica deve ser realizada pelo Consultor de Qualidade Esta atividade consiste em capacitar os revisores a inspecionar o conjunto de artefatos de acordo com a TLV e TLH A dura o desta atividade n o deve ultrapassar uma hora Esta atividade opcional pois caso o grupo de revisor j tenha experi ncia com este tipo de revis o t cnica e n o necessite de instru es A sequ ncia de tarefas desta atividade consiste em SPR A2 1 Treinar o grupo revisor em que revis o de artefato eles v o examinar SPR A2 2 Associar t cnicas de leitura horizontal e vertical aos revisores SPR A2 3 Fornecer impress o do documento relativo ao artefato a ser examinado para cada revisor que dever dispor de uma hora para leitura do documento No caso da n o realiza o desta atividade as tarefas SPR A2 2 e SPR A2 3 devem ser executadas pela atividade seguinte ou seja SPR A3 SPR A3 PREPARA O PARA REVIS O T CNICA A atividade Prepara o para Revis o T cnica deve ser realizada pelo Consultor de Qualidade Esta atividade consiste em preparar os revisores sobre o conjunto
246. rer 3 Caracter sticas Administrativas Hist rico hist rico de vers es datas de libera es desenvolvedores respons veis principais diferen as entre as vers es Restri es comerciais e legais restri es comerciais ou legais no uso do componente por exemplo aquisi o licen a especial ou permiss o requerida 4 Caracter sticas de Avalia o Restri es t cnicas restri es t cnicas no uso do asset por exemplo capacidades linguagem de programa o depend ncias de sistema operacional 83 Qualidade indicar a situa o do asset quanto qualidade revis es verifica es e casos de testes aplicados inclusive os resultados obtidos Performance recursos do sistema necess rios para usar 0 asset por exemplo mem ria processador canais de comunica o Alternativas rela o de assets semelhantes que poderiam ser usados no lugar deste Problemas relato de problemas conhecidos e custo requerido Interdepend ncias o asset pode ser usado stand alone ou deve ser usado junto a outros assets Custo recomendado custo conhecido para melhorar performance tornar o asset mais robusto e ou estender o escopo de reuso 5 Caracter sticas Complementares Indexa o prov um ndice para assets complexos que requerem documenta o extensa Refer ncias refer ncias para literatura ou outra documenta o por exemplo documenta o de sistemas Este processo abrange duas atividades
247. respondente for ator verifique se o ator est interagindo com caso de uso correspondente a classe conceitual Realce em amarelo a itera o ou associa o de extens o ou inclus o correspondente 1 Certifique que o mesmo relacionamento e itera o estejam presentes em ambos documentos Caso contr rio h informa o em um documento que n o est presente em outro ou h inconsistente entre os dois E Se o Modelo Conceitual de Dom nio especifica algum mecanismo de heran a para esta classe verifique se eles est o corretamente representados no Modelo de Casos de Uso 1 Caso n o encontre preencha a Tabela de Discrep ncia pois h informa o em um documento que n o est presente em outro ou h inconsistente entre os dois Restrito Instituto Militar de Engenharia P gina 1 2 154 Garantia da Qualidade de Software Leitura Horizontal 2 Vers o 1 2 RELH201 03 Data da vers o 03 03 2004 A Verifique se o objeto correspondente classe conceitual est utilizando o n vel adequado de abstra o 1 Certifique que pode entender o prop sito desta classe Caso contr rio preencha a Tabela de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o B Verifique se todos os relacionamentos e restri es das classes conceituais estejam corretamente capturados nas descri es dos cen rios correspondentes 1 Certifique semanticamente que os relacionamentos fazem sentido pelo papel e obj
248. rfaces de comunica o est o definidos 3 8 Os algoritmos intr nsecos para as necessidades funcionais est o definidos 3 9 A necessidade inclui todo o conhecimento do cliente ou necessidades de sistema 3 10 O comportamento esperado est documentado para todas as condi es de erro 3 11 Todas as fun es cr ticas de tempo est o identificadas e seus crit rios de tempo espedficados s Total de itens do aspecto verificados Total de nao confommidades Restrito Instituto Militar de Engenharia P gina 1 4 NNNnnn 139 Garantia da Qualdade de Software Checklist Necessidades do Cliente e Gloss rio Vers o 1 5 VENCO001 03 Data da vers o 01 03 2004 Checklist Necessidades do Cliente e Glossario Artefato Verificado CTNC001 03 A coluna P Previs o ccont m a resposta correta desejada e na coluna C Confirma o o revidor deve preencher coma resposta adequada S Sim N N o NA N o se aplica Caso a resposta da coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados identificados e comentados na parte de N o Conformidades 4 Aspecto Rastreabilidade Este aspecto deve analisar a rastreabilidade das funcionalidades e caracter sticas desejadas 4 1 Cada necessidade exclusivamente e corretamente identificada 4 2 Cada funcionalidade pode ser rastreada nos requis
249. rg os Descentralizados de Fornecimento de Software na aprova o dos artefatos a serem empacotados em assets para certifica o classifica o e gerenciamento destes assets posteriormente em reposit rios de artefatos reutiliz veis Este trabalho viabilizou a integra o de diferentes t cnicas de controle de qualidade de software em um processo de desenvolvimento do ciclo de vida de software baseado em assets visando a assegurar e melhorar a qualidade para reutiliza o A avalia o da qualidade dos artefatos gerados nas fases iniciais do processo de Engenharia de Dom nio e Desenvolvimento possibilitou a realiza o de a es preventivas e ou corretivas como tamb m possibilitou a melhoria cont nua na qualidade do desenvolvimento correto dos artefatos a serem reutilizados desde a primeira vez Com isto quantidades relevantes de retrabalho e de retestes futuros puderam ser evitadas FALCONI 1999 As inspe es abordadas neste trabalho foram abrangidas pelas verifica es e revis es Estas inspe es de software possibilitaram a detec o e remo o de defeitos na fase em que foram gerados inclusive na codifica o A combina o destas inspe es com as realiza es dos testes foi necess ria para a produ o de software com qualidade Atrav s do estudo de caso foi observado que investir exclusivamente em testes acarretaria em um retrabalho maior Pois os testes ao removerem defeitos ao final do ciclo de desenvolvimento
250. ricas de Bibliotecas de Reuso s o usadas para gerenciar e acompanhar o uso de um reposit rio de reuso O crit rio de avalia o para indexar esquemas de bibliotecas de reuso custos busca pela efetividade suporte para entendimento e efici ncia As organiza es frequentemente necessitam desses modelos e m trica nesta ordem apresentada por Frakes e Terry FRAKESb et al 1996 A maioria dos modelos econ micos de engenharia de software precisa ser ajustada para incluir reuso e customizada para cada reuso espec fico Muitos autores t m modificado os modelos de custos como COCOMO BOEHM et al 1988 que s o usados para estimar tempo e esfor o e para o desenvolvimento tanto de componentes quanto de aplica es usando componentes POULIN 1997 Jacobson et al JACOBSON et al 1997 apresentam como usar um modelo de esfor o e custo de reuso simplificado essencialmente reformulando a an lise de Gaffney e Durek GAFFNEY et al 1989 e aplicando as recomenda es de Poulin POULIN 1997 Ele tamb m adiciona um fator de utiliza o de biblioteca pois em uma biblioteca de sistemas de 12 A Rational desenvolveu uma An lise por Pontos de Caso de Uso similar An lise por Pontos de Fun o que pode ser utilizada para estimar o tamanho de uma aplica o baseada no n mero e complexidade de atores e casos de uso 51 componentes que cont m v rios sistemas de componentes esperado que ocorra mais reuso para os sistemas d
251. rkshop on Software Reusability Los Alamitos California March IEEE Computer Society Press 1993 RATIONAL SOFTWARE CORPORATION Reusable asset specification 2001 Dispon vel http www rational com rda forms preview online v2 jsp capturado em 21 de janeiro de 2004 REGNELL B RUNESON P THELIN T Are the perspectives really different Technical Report CODEN LUTEDX tets 7172 1 40 1999 amp Local 4 Department of Communication Systems Lund University 1999 p 141 181 RISING L A Way to Reuse Expertise IEEE Communications Magazine v 37 n 4 April 1999 Dispon vel http wwwagcs com supportv2 techpapers expertise htm capturado em junho de 2003 ROCHA A R C MALDONADO J C WERBER K C Qualidade de software teoria e pr tica 1 Edi o S o Paulo Prentice Hall 2001 303 p ISBN 85 87918 54 0 ROSENBERG L HYATT L HANNER T HUFFMAN L WILSON W Testing metrics for requirement quality 11 International Software Quality Week California May 1998 9 p Dispon vel http satc gsfc nasa gov support ISQW_MAY98 qual_5_98 pdf capturado em mar o de 2003 ROSS D T Applications and extensions of SADT IEEE Computer v 18 n 4 April 1984 p 25 35 SAMETINGER J Reuse documentation and documentation reuse In Proceedings of TOOLS Europe 96 Paris February 1996 12 pp Dispon vel http www swe uni linz ac at publications abstract TR SE 95 13 html capturado em janeiro de 2004
252. role de Qualidade Entrada para o processo 1 Modelo de Casos de Uso do Dom nio 2 Descri o dos Cen rios dos Casos de Uso do Dom nio 3 Interface da Camada da Aplica o representada pelo diagrama de classes Procedimentos I Leiao Modelo de Casos de Uso do Dom nio e Cen rios para entender os casos de uso e suas itera es ENTRADAS Modelo de Casos de Uso do Dom nio Descri o de Cen rios do Dom nio SA DAS Servi os candidatos marcados em verde na Descri o de Cen rios do Dom nio A Para cada caso de uso leia atentamente a descri o do Cen rio do Dom nio correspondente tanto o curso normal quanto os alternativos B Encontre os verbos ou descri o de a es que s o candidatos a serem servi os ou comportamento no sistema Sublinhe em verde os verbos ou descri o de a es C Procure por dados necess rios de entrada e sa da nos verbos identificados no passo B Sublinhe em vermelho os dados de entrada em azul e os dados de sa da II Compare os casos de uso s interfaces do sistema para verificar se as interfaces foram capturadas adequadamente ENTRADAS Modelo de Casos de Uso do Dom nio Interface da Camada da Aplica o SA DAS Relat rio de Discrep ncias Para cada caso de uso do Modelo de Casos de Uso do Dom nio execute os seguintes passos A Encontre a classe correspondente na especifica o da Interface da Camada da Aplica o e marque esta classe com um asterisco azul 1 Caso n o
253. rsos gastos e no reuso de software visando garantir a satisfa o do cliente em obter um produto de software cada vez mais r pido de qualidade e de baixo custo de produ o O aumento da efici ncia do desenvolvimento de software refere se 20 ao desenvolvimento de linguagens mais eficientes e ferramentas de apoio melhora do processo produtivo gerencial e de treinamento do pessoal como tamb m obten o de um bom arquivo de dados informa o O reuso considerado como chave da estrat gia de algumas organiza es se torna uma ferramenta facilitadora que permite o ganho em qualidade redu o de falhas pelo reuso de artefatos j testados e aprovados redu o de custos de produ o ao m dio longo prazo com altera o do enfoque organizacional diminui o de redund ncias e melhoria no desenvolvimento aumento da agilidade Desta forma o reuso pode ser definido como a utiliza o de um artefato fora de seu contexto de cria o isto uma equipe a respons vel pelo desenvolvimento e outra pelo seu emprego apropriado JACOBSON et al 1999 Um dos pontos cr ticos da reutiliza o do produto de software o tempo despendido pelos desenvolvedores para compreender adaptar e integrar o artefato a ser reusado A compreens o do artefato reutiliz vel e o momento de integr lo no ciclo de vida de desenvolvimento de software faz com que a documenta o do asset desempenhe um papel vital na viabiliza o da reutiliza
254. s Para cada classe do diagrama do Modelo Conceitual do Dom nio execute os seguintes passos A Encontre o objeto correspondente ator ou caso de uso Marque com um asterisco azul o objeto correspondente no Modelo de Casos de Uso do Dom nio quando encontrar Se for necess rio consulte na Descri o dos Cen rios dos Casos de Uso do Dom nio para ajudar a encontrar o caso de uso correspondente 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois uma classe conceitual n o est presente no Modelo de Casos de Uso e Cen rios B Verifique se o nome da classe conceitual o mesmo utilizado nos objetos ator ou caso de uso assim como na descri o dos cen rios correspondentes 1 Caso n o tenha o mesmo nome preencha a Tabela de Discrep ncia pois a descri o pode estar amb gua relatando a necessidade de conhecimento adicional para compreens o C Se o objeto correspondente n o for ator ent o verifique se todos os atributos da classe conceitual est o sendo referenciados na descri o do cen rio correspondente nos cursos normal ou alternativo 1 Certifique que o mesmo conjunto de atributos esteja presente em ambos os documentos Caso contr rio preencha a Tabela de Discrep ncia pois informa o est presente em um documento mas ausente no outro D Se o objeto correspondente n o for ator verifique se os relacionamentos da classe conceitual s o capturados pelo caso de uso correspondente Se o objeto cor
255. s In Proceedings of the Workshop on Learning Software Organizations Oulu 2000 p 15 33 Dispon vel http www iese fhg de LSOworkshop2000 LS O Complete 2000 pdf capturado em maio de 2003 FIORINI S T STAA A BAPTISTA R Engenharia de software com CMM Rio de Janeiro Brasport 1998 346 p 117 FRAKES W B NEJMEH B A Software Reuse through Information Retrieval In Proceedings of the Twentieth Annual Hawaii International Conference on Systems Sciences Kona Jan 1987 p 530 535 FRAKES W POLE T An empirical study of representation methods for reusable software components IEEE Transactions on Software Engineering v 20 n 8 Aug 1994 p 617 630 FRAKES W FOX C Sixteen questions about software reuse Communication ACM v 38 n 6 1995 p 75 87 FRAKESa W B FOX C J Quality improvement using software reuse failure modes model IEEE Transactions on Software Engineering v 22 n 4 April 1996 p 274 279 FRAKESb W B TERRY C Software reuse metrics and models ACM Computing Surveys v 28 n 2 1996 p 415 435 FUJIWARA S BOCHMAN G V KHENDECK F AMALON M GHEDAMSI A Test selection based on finite state models IEEE Transactions on Software Engineering v 17 n 6 June 1991 p 591 603 FUSARO P LAMBILE F VISAGGIO G A replicated experiment to assess requirements inspections techniques Empirical Software Engineering an International Journal v 2 n 1 1997
256. s o gt fetches pelo consultor volvedores gt projeto gt GQS gt de GQS gt FIG 4 2 1 3 Cronograma para as verifica es e revis es de GQS do projeto 91 De acordo com a Norma ISO 9000 2000 ABNT9000 2001 foi estabelecido o QSMGQ para prover a melhoria do processo de qualidade de forma que o Comit de Qualidade possa obter um feedback do grupo de qualidade O Question rio de Sugest es para Melhoria da Garantia da Qualidade apresentado na FIG 4 2 1 4 Question rio de Sugest es para Melhoria da Garantia da Qualidade 1 A verifica o revis o atingiu os objetivos do grupo da qualidade Se n o por qu 2 O grupo da qualidade sente que contribuiu para melhorar a qualidade do artefato ou asset pela verifica o revis o 3 Todos tiveram tempo suficiente para fazer prepara o Se n o quanto tempo precisa 4 H necessidade de conhecimento espec fico para utilizar o checklist t cnica de leitura para este tipo de artefato asset durante a prepara o 5 Foi til para detectar nao conformidades Do 6 O checklist t cnica de leitura pode ser melhorado Caso afirmativo como 7 No subprocesso de Revis o todos os participantes estavam presentes Se n o quem estava ausente Indicar e justificar se n o havia necessidade 8 Os procedimentos para as verifica es revis es foram seguidos corretamente 9 No subprocesso de Revis o co
257. s B sicas Quantidade de n o conformidades detectadas Quantidade de n o conformidades resolvidas dentro do prazo Grau de severidade 2 Frequ ncia da Coleta de Dados Nos marcos definidos no plano de projeto para entrega da vers o 3 Respons vel Consultor de Qualidade 4 Fase ou Atividade para Coleta Entrega de uma nova vers o 5 Ferramentas usadas na Coleta Excel 6 Verifica o e Valida o Quantidade de n o conformidades detectadas deve ser a soma das quantidades de n o conformidades resolvidas dentro e fora do prazo Severidades devem ser do tipo A B ou C 7 Reposit rio para Dados Coletados Banco de Dados de Medi o do projeto 108 TAB 4 2 4 1 7 Formul rio associado ao procedimento para An lise dos Dados AN LISE DE DADOS Indicador Quantidade de n o conformidades resolvidas no prazo Frequ ncia do Reporte de Dados Gera o de uma nova vers o do projeto Respons vel Analista de Medi es Fase ou Atividade para An lise Entrega de uma nova vers o Fonte dos Dados para An lise Banco de Dados de Medi o do projeto Ferramentas usadas na An lise de Dados Excel Relat rio Relat rio de Medi o e Avalia o para o gerente de reuso 4 2 4 2 MEDI O A Medi o foi realizada da seguinte forma T cnica Utilizada Os dados resultantes da realiza o das listas de confer ncias checklists e das revis es capturados conforme descrit
258. s Relevantes Checklists Relat rios de Revis o Relat rios de Resolu o de N o Conformidades Atributos N mero de n o conformidades detectadas N mero de n o conformidades resolvidas dentro do prazo Severidade Medidas B sicas Quantidade de n o conformidades detectadas Quantidade de n o conformidades resolvidas dentro do prazo Grau de severidade M todo de Medi o Somat rio das n o conformidades detectadas pelas tarefas de inspe o realizadas multiplicadas pelo valor correspondente ao grau de severidade 1 para severidade do tipo A 2 para tipo Be 3 para tipo C Para as n o conformidades encontradas via Checklist considerar grau de severidade 1 Tipo de M todo Objetivo Escala N meros reais positivos Tipo de Escala Raz o Unidade de Medida N o conformidades Severidade Medida Derivada Percentagem de n o conformidades resolvidas no prazo Fun o de Medi o IQPVR Quantidade de n o conformidades resolvidas dentro do prazo Quantidade de n o conformidades detectadas 100 Modelo de An lise Os resultados do indicador devem ser analisados nos marcos definidos no plano do projeto ap s a entrega de uma vers o 15 Crit rio de Decis o Caso o percentual esteja acima dos limites estabelecidos para o projeto deve se analisar a causa dos atrasos TAB 4 2 4 1 6 Formul rio associado ao procedimento de Coleta de Dados COLETA DE DADOS 1 Medida
259. s S 1 2 O documento teve ortografia e gram tica checada s s 1 3 O documento est livre de erros de layout s S 1 4 O gloss rio disp e de todas as defini es e explica es que o revisor necessita para o completo entendimento das necessidades e caracter sticas desejadas s s 1 5 Os n meros das linhas do texto do documento est o impressos para facilitar a refer ncia de localiza o espec fica durante a verifica o s s Total de itens do aspecto verificados Total de nao conformidades FIG 4 2 2 1 1 d Parte do checklist do artefato Necessidades do Cliente e Gloss rio 94 Identifica o da Verifica o Projeto Id do artefato Verificador Data da Verifica o N vel de conhecimento do dominio C Jpaixo m dio Do JAto Dados da Verifica o An lise da Verifica o Total de Tempo Total de itens do checklist Prepara o hr a2 Total de itens verificados Realiza o da verifica o E A hr Qtd de itens atendidos Dispendido hr Qtd de itens NAO atendidas Quantidade a3 Total de itens NAO aplic veis Paginas verificadas L Total de Defeitos Detectados Resultado da Verifica o aceito _ Nao Aceito sem r siri es Data da pr xima verifica o i i o Jcom restri es E A z Refazer para nova verifica o Data da pr xima verifica o P i i __ Verificagao nao completada Problemas Listar os problemas detectados que n o s o n o conformidades por ex o
260. s devem ser identificados e comentados na parte de N o Corformidades 1 Aspecto Corretude e Completude Este aspecto deve verificar a presen a de um conjunto de fun es e sua adequa o s tarefas espec ficas obtendo resultados e efeitos corretos 1 1 A janela abre cometamente conforme o tipo selecionado ou comandos de menu 1 2 Todos os dados est o corretamente dentro da janela efetiva como mouse teclas de fun o setas direcionais e teclado dispon veis 1 3 Todas as fun es relacionadas janela est o operacionais 1 4 Todos os menus pull down barras de ferramenta barras de rolagem caixas de di logo e bot es cones e outros controles dispon veis est o corretamente exibidos najanela 1 5 A janela ativa real ada coretamente 1 6 Naopera o de multi tarefa todas as janelas s o atualizadas no tempo devido 1 7 A janela fecha corretamente 1 8 A barra de menu exibida adequadamente ao contexto 1 9 A barra de menu da aplica o retrata corretamente os requisitos relativos ao sistema 10 Asopera es de pull down s o realizadas corretamente 11 Os menus e as barras de feramenta s o realizados corretamente 12 Todas as fun es de menu e as subfun es do menu pull down s o corretamente listadas 13 Todas as fun es de menu s o corretamente tratadas pelo mouse 14O tipo tamanho e formato dos textos apresentados est o cometos 15 Asfun es de menu real adas est o coerente com o
261. s existentes dentro de um espa o real limitado pelo alcance dos sensores e pela im possibilidade de altera o destes em um curto espa o de tempo Este espa o de tempo definido pela velocidade e disponibilidade dos meios existentes Centro de Informa es de Combate CIC Local onde s o compilados os dados referentes ao Cen rio T tico Controlador T tico Sistema respons vel por auxiliar no recebimento de dados referentes ao Cen rio T tico na realiza o de c lculos t ticos necess rios e na apresenta o destes de uma forma amig vel Dados hist ricos de posi o da plataforma Dados fornecidos pelos sensores de detec o que servem de entrada para o c lculo dos dados t ticos Por exemplo dist ncia marca o posi o em latitude e longitude Dados de Configura o Dados fornecidos pelo operador que definem a dist ncia para passagem segura e o limite do cen rio t tico Dados de Ambiente Dados fornecidos pelos sensores de navega o que servem de entrada para o c lculo do vento real e corrente Por exemplo vento relativo e velocidade relativa da plataforma Differential Global Positioner System DGPS Um dos Sistemas de Posicionamento Sat lite existente Sua precis o da informa o de posicionam ento de aproximadamente 15 metros Dist ncia para Passagem Segura Dist ncia pr definida para o c lculo do rumo para passagem segura Enlace Autom tico de Dados EAD Sistema de comunica o
262. s itens do Checklist de Necessidades do Cliente e Gloss rio que n o est o em conformidades 5 cci5sccccnssesscaccssvoncecdestenecaseesaceens 97 FIG 4 2 2 2 1 c Relat rio de Verifica o de Necessidades do Cliente e Gloss rio 97 FIG 4 2 3 1 1 a T cnica de Leitura Vertical TLVI ereta 99 FIG 4 2 3 1 1 b Relat rio da Revis o erre er erre area aeee errrerada 99 FIG 4 2 3 2 1 a Tabela de Discrep ncia para T cnica de Leitura Vertical 101 FIG 4 2 3 2 1 b Tabela de Discrep ncia para T cnica de Leitura Horizontal 101 FIG 7 3 3 Componentes do Modelo CMMI representa o Organizado 132 FIG 7 3 3 1 Processos de ciclo de vida da ABNT 12207 com as extens es para processos de ciclo de vida de re so da IEEE 1517 00 00 cess ccccssscccccssccccccssscccccssesceeeers 137 11 LISTA DE TABELAS TAB 2 1 2 2 1 T cnicas de inspe o de software e suas caracter sticas 35 TAB 2 2 3 1 2 As m tricas de projeto para avaliar as propriedades de projeto 43 TAB 2 1 3 1 3 Parcelas das fun es de medi o de BANSIYA et al 2002 44 TAB 3 2 1 2 2 1 Conjunto de artefatos para revis o ita seis dean qt aaa 71 TAB 3 2 2 1 Tipos de assets produzidos pelo Processo de Desenvolvimento de Software baseado em Re so na MD
263. s quais trocam mensagens Caso contr rio uma associa o est presente no diagrama de seqii ncia por causa da troca de mensagem mas n o est presente no diagrama de classes 4 Esteja certo que n o est o faltando comportamento os quais poderiam evitar que algum servi o seja executado Se existem isto significa que algo est faltando no diagrama de seqii ncia Verifique que as restri es identificadas no diagrama de seqii ncia podem ser atendidas no diagrama de classes correspondente Verifique as seguintes discrep ncias e preencha a Tabela de discrep ncia se quaisquer das declara es seguintes n o s o verdadeiras ou seja informa o no diagrama de seqii ncia n o foi representada nos diagramas de classes 1 Seo diagrama de seqii ncia descreve restri es no n mero de objetos que podem receber uma mensagem esteja certo que a restri o aparece como uma informa o de cardinalidade na associa o apropriada do diagrama de classe correspondente 2 Seo diagrama de sequ ncia especifica uma faixa de valores permitidos para os dados esteja certo que uma restri o aparece como uma faixa de valores no atributo do diagrama de classes correspondente 3 Seo diagrama de segii ncia cont m informa o relacionada s depend ncias entre os dados ou objetos esteja certa que esta informa o est inclu da no diagrama de classes correspondente via uma restri o na classe ou restri es de cardinalidade no relaciona
264. s vari veis de controle de loop do comando for est o declaradas no escopo do m todo Todos os atributos t m modificadores de acesso apropriados private protected public Existem constantes literais que devem ser nomeadas constantes Existem vari veis ou atributos que devem ser constantes Existem atributos que devem ser vari veis locais ao m todo Existem atributos est ticos que devem ser n o est ticos ou vice versa Total de itens do aspecto verificados Total de n o conformidades 2 Aspecto Defeito de Defini o de M todo Este aspecto deve verificar os defeitos de defini o de m todo 2 1 Os nomes dos m todos est o de acordo com a conven o de nomes 2 2 Todos os valores de par metro dos m todos foram checados antes de serem usados 2 3 Todos os valores de par metros s o usados no c lculo ou manipulados 2 4 Para todos os m todos que implementam fun o t m o valor correto de ponto de retomo 2 5 Todos os m todos t m modificadores de acesso apropriados private protected public 2 6 Existem m todos est ticos que devem ser n o est ticos ou vice versa Total de itens do aspecto verificados Total de n o conformidades 3 Aspecto Defeito de Defini o de Classe Este aspecto deve verificar os defeitos de defini o de classe P 3 1 Cada classe tem seu construtor apropriado s 3 2 Todas as subclasses t m membros comuns que devem estar na superclasse n 3 3 A hierarquia de heran a de classe pode ser simp
265. sabilidade compatibilidade padroniza o da documenta o rastreabilidade corretude facilidade no entendimento das funcionalidades e objetivos do asset A partir da qualidade aprovada do asset pelo Relat rio de Verifica o o Comit de Qualidade deve enviar o asset aprovado ao Processo de Ger ncia de Assets para cataloga o notifica o e gest o do asset no reposit rio de assets reutiliz veis e um Relat rio de Aprova o do asset ao Grupo de GQS Corporativo e ao Gerente de Reuso Especifica o de Requisitos do Asset Relat rio de Verifica o do Asset Subprocesso de Verifica o Grupo de GQS insssE nda Aprov a o de Asset Re so EngenhariadeDom nio asset documenta o PAA conjunto de artef atos Engenheiros de com qualidade aprovada Dom nio Processo de Desenv olv imento Desenv olv edoreg montadores Processo de Ger ncia de Assets Relat rio de Aprov a o de Asset asset documenta o conjunto de artef atos com qualidade aprov ada Grupo de GQS Corporativ o Gerente de Re so Comit deQualidade FIG 3 2 2 1 Processo de Aprova o de Assets PAA Na FIG 3 2 2 1 s o apresentadas as intera es do Processo de Aprova o de Asset PAA com os processos de GURGEL 2004 e de Controle da Qualidade PCQ apresentando os artefatos de entrada sa da com seus respectivos pap is e os respons veis pelo PAA E
266. screp ncia pois informa o no Modelo Conceitual de Dom nio n o est na descri o textual do Modelo de Contexto do Dom nio Restrito Instituto Militar de Engenharia P gina 1 2 152 Garantia da Qualidade de Software Leitura Horizontal 1 Vers o 1 2 RELH101 03 Data da vers o 03 03 2004 1 Utilize a hierarquia de classes para encontrar os pais desta classe Verifique semanticamente se o nome da classe do tipo da classe pai e se faz sentido ter esta classe neste ponto de hierarquia Caso contr rio a hierarquia n o deveria ser definida desta maneira ent o preencha a Tabela de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o B Verifique se todos os relacionamentos das classes associa o agrega o e composi o estejam corretamente descritos com respeito s indica es de multiplicidade 1 Para cada relacionamento certifique semanticamente que o relacionamento faz sentido dado o papel e os objetos relacionados Caso contr rio o relacionamento n o deveria ser definido desta maneira ent o preencha a Tabela de Discrep ncia relatando a necessidade de conhecimento adicional para compreens o II Reveja o Modelo Conceitual do Dominio para assegurar que todas as classes e suas associa es est o sendo levadas em considera o ENTRADAS Classes marcadas com asterisco azul Associa es realgadas em amarelo SA DAS Relat rio de Discrep ncias A Reveja as classes e seus rela
267. sessssssseesnseseseees 115 7 AP NDICES e ns GU di 124 EM AP NDICE 1 ESTUDO SOBRE OS TIPOS DE REUSO s 124 72 AP NDICE 2 RESUMO DOS PRINCIPAIS MODELOS E M TRICAS 127 13 AP NDICE 3 PRINCIPAIS NORMAS ccecsscscssessesseseesesseseessssessessssssessssesseeees 128 Teal Indicadores de produto de soffWare ss Sadia qdo aiin ies 132 L2 Ciclo de Vida do Software nos Padr es da ISO 12207 135 Todo Processos Voltados a Reuso de Assets pela IEEE 1517 essscsssssceenssceenenees 136 14 AP NDICE 4 CHECKLISTS E T CNICAS DE LEITURA s 139 7 4 1 Areias C ea e A EE ES AE a E E RD 139 7 4 2 Artefatos T cnicas de Leitura Horizontal ccccccccccccssssnsncececeeeesesensaceeeeeeens 152 7 4 3 Artefatos T cnicas de Leitura Vertical 2 ccccciccsssscciccucescasasovesscsuesseedesseccccseavecess 162 8 PRE O A T ETET E E E EO 170 8 1 ANEXO 1 PROPOSTA DO PROCESSO DE CICLO DE VIDA DO SOFTWARE BASEADO EM REUSO NO CONTEXTO DO MD 170 8 2 ANEXO 2 ARTEFATOS DOS PROCESSOS DE ENGENHARIA DE DOM NIO E DESENVOLVIMENTO BASEADO EM REUSO NO CONTEXTO E 8h oh daha AR RE AP E POR RR E aeai aa t 171 9 GLOSS RIO DE TERMOS TECNICOS E EXPRESS ES USADAS 185 LISTA DE ILUSTRA ES FIG 1 3 1 a Ciclo PDCA de Deming adaptado de FALCONI 1999 b Espiral de Seite SAL LC CLEL 6 ists en i Dq a 25 FIG 2 1 1 1 Diagrama de relacionamento das etapas de desenvolvimento de projeto
268. so de Medi o e Avalia o o PCQ deve garantir que as medi es do processo e produto de software estejam de acordo com os procedimentos estabelecidos de reusabilidade e satisfa o do cliente No caso de subcontrata o este processo deve garantir que os artefatos assets da subcontratada satisfa am as necessidades do Contrato original repassando as necessidades e caracter sticas desej veis aplic veis e executando verifica es e revis es durante as fases de desenvolvimento de cada refer ncia fornecida ABNT12207 1998 3 2 1 2 1 SUBPROCESSO DE VERIFICA O SPV O Subprocesso de Verifica o tem o prop sito de definir as atividades para verificar artefatos assets via a T cnica de Checklist baseado em Aspecto a fim de determinar sua conformidade com os requisitos e padr es estabelecidos para o projeto veja FIG 3 2 1 2 2 Os artefatos e os assets com suas respectivas documenta es verificados s o os seguintes produtos do Processo de Desenvolvimento baseado em Reuso para MD de GURGEL 2004 Necessidades do Cliente e Gloss rio Arquitetura de Dom nio C digo fonte Casos de Testes de Qualifica o Asset de Dom nio Asset de Arquitetura de Dom nio Asset de Componente de Dom nio e Asset de Componentes Este subprocesso abrange duas atividades que s o apresentadas no diagrama da FIG 3 2 1 2 1 1 Planejamento SPV A1 e Verifica o SPV A2 SPV SUBPROCESSO VERIFICA O Modelo Modelo PGQSP Checklist
269. so e de projeto precisa de dados acurados das tend ncias para saber quando e onde deve agir IEEE 1517 1999 O controle da qualidade deve produzir um documento contendo todos os problemas identificados e estes devem ser resolvidos Ap s a cada altera o necess rio repetir o controle da qualidade ABNT 12207 1998 FIORINI et al 1998 Ishikawa prop s sete ferramentas b sicas de estat stica para controle da qualidade PALADINI 1994 que s o teis para o planejamento e controle de projetos de desenvolvimento de software Dentre elas se destacam o Diagrama de Causa Efeito o Checklist e o Diagrama de Pareto 7 E n E 5 F E g 2 GQT um sistema que combina t cnicas de controle da qualidade e modelos organizacionais onde a qualidade reconhecida como uma vantagem estrat gica com o ap io total da alta administra o 27 O Diagrama de Causa Efeito conhecido como Gr fico Espinha de Peixe ou Gr fico de Ishikawa identifica todos os fatores de causa de uma caracter stica da qualidade em um nico gr fico Sua forma similar espinha de peixe onde o eixo principal mostra a caracter stica da qualidade e as espinhas representam os fatores que afetam esta caracter stica PALADINI 1994 O Checklist um formul rio que cont m itens para serem verificados conforme as necessidades espec ficas de seus usu rios e por isso apresentam extrema flexibilidade de elabora o utiliza o e interpreta o Seu princ
270. so que seja sistem tico FRAKES et al 1994 O reuso deve estar explicitamente definido nos processos de ciclo de vida de software para assegurar o reuso repetidamente nos diversos produtos e projetos de software da organiza o FICHMAN 2001 As organiza es devem estabelecer uma pol tica de reuso reuso a priori artefato projetado para reuso ou a posteriori artefato transformado para reuso FICHMAN 2001 As organiza es devem ter um programa de reuso que utilize um esquema de classifica o para catalogar componentes em uma base de software Os esquemas devem especificar alguns atributos chamados de facetas para serem utilizados como descritores de um componente de software Em geral esses atributos devem ser relativos a o que o componente realiza e aos objetos manipulados pelo componente A classifica o e a recupera o devem ser realizadas ao especificar termos para cada atributo no esquema Os relacionamentos com termos ou frases devem ser atrav s da combina o de atributos o que possibilita melhor precis o nas buscas GIORARDI 1998 As organiza es devem ter um programa de reuso onde os reutilizadores tenham conhecimento da exist ncia dos assets possam ser facilmente localizados e entendidos e principalmente tenham suas qualidades asseguradas Portanto o reuso requer que o projeto de software seja examinado quanto sua qualidade para maximizar oportunidades de reuso de implementa o JACOBSON et
271. software a ser constru do Os assets podem ser modificados mudando caracter sticas internas ou acrescentando novas caracter sticas Quando um asset oferece a funcionalidade exigida ele deve ser incorporado no sistema de software Por m os assets existentes podem n o ser suficiente para construir um novo sistema Portanto alguns assets devem ser constru dos do zero para serem inseridos no reposit rio de assets reutiliz veis facilitando o seu reuso em projetos futuros FICHMAN 1999 Desta forma desenvolver para reuso implica em construir modelo de dom nio e arquitetura construir novos assets ou reengenhar assets existentes para melhorar sua reusabilidade Para apoiar desenvolvimento para reuso devem ser acrescentadas ao ciclo de 48 vida do software as seguintes atividades IEEE 1517 1999 veja se o 7 3 3 do AP NDICE 3 Executar an lise de dom nio Executar projeto de dom nio Construir assets reutiliz v is Na FIG 2 2 1 1 apresentado um resume das etapas do processo de reuso O processo de reusar um asset existente requer as seguintes atividades Busca Entende e Adapta A atividade Desenvolve necess ria quando nenhum asset reutiliz vel pode ser identificado A atividade Integra deve ser feita mesmo que um asset existente seja reusado ou um novo tenha sido desenvolvido Finalmente o novo asset ou o asset modificado deve ser generalizado e classificado para ser armazenado no reposit rio de assets re
272. sores de navega o agulha girosc pica anem metro hod metro 172 Gloss rio Introdu o Este documento usado para definir a terminologia espec fica do dominio do problema o Controlador T tico cujo pleno entendimento se faz necess rio para o desenvolvimento e opera o do sistema a ser desenvolvido Defini es Acompanhamento Vis o virtual de uma plataforma para o sistema e que possuidados correlacionados Passa a existir para o sistema ap s inser o direta do operador ou automaticamente por um dos sensores conectados ao sistema Extrator radar ou link Possui sempre um identificador numeral o n mero de acom panhamento NA Agulha Girosc pica Sensor que fornece a indica o referencial de Norte para o sistema o norte da giro Alarme de Colis o Retorno fornecido pelo sistema quando o c lculo do PM A indicar a passagem de um contato a uma dist ncia inferior a definida como segura Pode ser uma indica o na tela ou um evento para um sistema externo C lculos T ticos C lculos efetuados sobre os dados recebidos do cen rio t tico Por exemplo c lculo do rumo e velocidade de um acompanhamento c lculo do ponto de maior aproxima o de um acompanhamento c lculo do rumo para passagem segura de um acompanhamento c lculo do vento real c lculo da corrente e c culo da posi o estimada da plataforma Cen rio T tico Conjunto de informa es formado pelos meios dispon veis e acompanhamento
273. sos e determina o de capacidade levando em considera o os m todos e normas j existentes CMM SEI STD Compita Trillium Bell SQPA HP Bootstrap SAM BT HelthCheck BT ISO 9001 Esta norma objetiva se a ser mais abrangente que os modelos existentes e al m disso ser mais espec fico que a norma ISO 130 9001 ROCHA et al 2001 Da ISO IEC 12207 herdou a arquitetura dos processos do ciclo de vida do software e do CMM herdou o conceito de n veis de maturidade de processos N vel 5 OTIMIZADO LA N ivels de Maturidade Otimizada Objetivo Controle do processo Matu rl d ade d O Caracter sticas Base quantitativa para investimento de capital continuado na automa o e melhoria do processo CM M Atua o nfase cont nua na medi o do processo e m todos de processo para preven o de defeitos KPA s Preven o de Defeitos Gest o da Mudan a de Tecnologia e Gest o de Mudan a de Processo N vel 4 GERENCIADO Maturidade Quantitativa Objetivo Medi o do processo Caracter sticas Controle estat stico racional da qualidade do produto e do processo Atua o Estabelecer planos e controle de produtividade quantitativo ambiente de processo documentado e investimentos tecnol gicos justificados economicamente KPA s Gest o da Quantitativa do Processo e Gest o da Qualidade do Software N vel 3 DEFINIDO Maturidade Qualitativa Objetivo Defini o do
274. stejam em conformidade com a especifica o PRESSMAN 2001 O sistema deve ser testado no ambiente de opera o computacional antes da realiza o do teste de aceita o O teste de caixa cinza que combina as abordagens caixa branca teste estrutural e caixa preta teste funcional fregiientemente aplicado neste tipo de teste ROCHA et al 2001 O teste de aceita o certifica que o sistema de software satisfaz os requisitos originais Este teste n o deve ser realizado antes do completo sucesso do teste de sistema Neste tipo de teste empregada a t cnica de caixa preta para testar o sistema contra suas especifica es Em geral o teste de aceita o um subconjunto de um ou mais testes de sistema LEWIS 2000 30 Os casos de teste de aceita o devem incluir testes de desempenho testes de carga testes de reusabilidade e testes de compatibilidade de arquitetura de dom nio Os testes de reusabilidade que incluem os testes de generalidade e de adaptabilidade devem ser escritos pelos engenheiros de dom nio assim como o teste de compatibilidade de arquitetura de dom nio O teste de generalidade consiste em validar a modifica o do dom nio da aplicabilidade do asset ao passo que o teste de adaptabilidade verifica a facilidade de reuso dos assets Os testes de sistema devem ser escritos pela equipe de desenvolvimento montadores e os testes de aceita o pelos engenheiros de dom nio e cliente IEEE1517 1999 Em gera
275. suas 132 subcaracter sticas Na TAB 7 3 1 1 s o apresentados os indicadores de qualidade do produto da norma ISO IEC 9126 ISO9126 2000 TAB 7 3 1 1 Indicadores de qualidade do produto da norma ISO IEC 9126 1 2000 1 Funcionalidade Conjunto de atributos que evidencia a exist ncia de um conjunto de fun es que satisfazem as necessidades expl citas ou impl citas dos usu rios e suas propriedades especificadas Confiabilidade 1 1 Adequa o Evidencia a presen a de um conjunto de fun es e sua apropria o s tarefas especificadas 1 2 Acur cia Evidencia a gera o de resultados ou efeitos corretos ou conforme acordados 1 3 Interoperabilidade Evidencia sua capacidade de interagir com outros sistemas especificados 1 4 Conformidade Evidencia o quanto o software est de acordo com as normas conven es ou regulamenta es previstas em leis e descri es similares relacionadas funcionalidade da aplica o 1 5 Seguran a de acesso Evidencia sua capacidade de evitar acessos n o autorizados acidentais ou deliberados a programas e dados Conjunto de atributos que evidenciam a capacidade do software de manter seu n vel de desempenho sob condi es estabelecidas durante um per odo de tempo estabelecido No produto de software falhas devido ao envelhecimento n o ocorrem as limita es na confiabilidade s o decorrentes de defeitos na especifica o dos req
276. te aspecto deve analisar o retestar P C I 4 1 Os casos de teste adequados e necess rios para retestar fun es anteriormente testadas s o identificados s 4 2 Todas as altera es de c digo s o suficientemente testadas principalmente as altera es de interfaces s Total de itens do aspecto verificados Total de n o conformidades 5 Aspecto Recursos e Escalabilidade Este aspecto deve analisar os recursos envolvidos para ajudar na realiza o do teste CI 5 1 Todos os recursos humanos e de hardware e software est o sendo considerados 5 2 Os recursos como desenvolvimento ou obten o de utilit rios e ferramentas facilitadores de testes estabelecidos t m sido escalados no tempo apropriado 5 3 Est o estabelecidos os pap is e as responsabilidades das pessoas envolvidas nas atividades de teste 5 4 Todas as possibilidades de conten o de recurso ou restri es de disponibilidade est o sendo consideradas Restrito Instituto Militar de Engenharia 141 Garantia da Qualdade de Software Checklist Arquitetura Vers o 1 2 VEAR00 1 03 Data da vers o 03 03 2004 Checklist Arquitetura Artefato Verificado CTAR001 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto qu
277. teVisao lt x lt x ag lt Q 7 a a interface type interface type interface type interface type lt interface type interface type configura o laberturaAcomp latualPlat linsDadosAmb IcancelAcomp lextra o qa oc interface interface o IplatMgt IhistPosMgt no LO a O core core oO Peet a Su Plataforma Hist ricoPosi o A Plataforma Prim aria Acompanhamento O lt lt Q metaclas s am TO Conexao uw H Oz wW N no Lu SE 22 oa Diagrama de Sequ ncia Colabora o do Controle T tico Diagrama Seqii ncia Camada Aplica o Controle ComponenteAplica o Extracao DispachanteVisao Visao T request T i 1 solicita o Procedimento T gt i 2 retorno REM EP a l 3 extrair j 1 4 reto mo d Sa RC e o Pia SENSO a ENS O RR 6 envia fi DiagramaSe qii nciaAbrirAcompanhamento abrirAcomp 1 criar I i I I I I 2 criar 3 retorno 4 retorno Diagrama Seq ncia Configura o Configuracao PlatMat inserir I I i 1 setDadosConf i I l I l I I i Diagrama de Seqii ncia Cancela Acompanhamento CancelAcomp PlatMat HistPosMat T cancelar 1 cancelar I l l 2 cancelar
278. tendo o sentido sem ntico dos mesmos O modelo conceitual n o um modelo de software mas um modelo de informa o inerente ao dom nio do problema Pr requisito Nenhum Entrada para o processo 1 Modelo de Contexto do Dom nio representado pelo diagrama de contexto baseado no m todo FORM e sua descri o textual 2 Modelo Conceitual do Dom nio representado pelo diagrama de classes Procedimentos I Leia a descri o do Modelo de Contexto do Dom nio e analise o diagrama de contexto para entender o escopo do dom nio do problema e as entidades externas e identificar seus relacionamentos ENTRADAS Modelo de Contexto do Dom nio Descri o textual do Modelo de Contexto do Dom nio Modelo Conceitual do Dom nio SA DAS Relat rio de Discrep ncias Para cada funcionalidade ou restri o na descri o textual do Modelo de Contexto do Dom nio execute os seguintes passos A Encontre a classe correspondente Marque com um asterisco azul a classe correspondente no diagrama de classes quando encontrar 1 Caso n o consiga encontrar preencha a Tabela de Discrep ncia pois uma funcionalidade n o est presente no modelo de dom nio B Verifique se o nome da classe inerente ao dom nio do problema e se ela est utilizando o n vel adequado de abstra o 1 Baseado no conhecimento fornecido pela descri o do Modelo de Contexto do Dom nio certifique se pode entender o prop sito desta classe Caso contr rio preencha a Tabela
279. ter o menor n mero de restri es t cnicas poss veis e a maior abrang ncia quanto seu escopo Complementar deve conter qualquer detalhe a mais que n o foi suprido pelas primeiras quatro caracter sticas Segundo Sametinger a documenta o de um asset deve conter os seguintes itens de acordo com as cinco caracter sticas acima descritas SAMETINGER 1996 1 Caracter sticas Gerais Nome do asset nome dando uma poss vel sugest o sobre a funcionalidade do asset Identifica o declara o inicial concisa e clara sobre a funcionalidade do asset para sele o inicial e inclusive com descri o geral de todas as opera es externamente vis veis se for um componente Especifica o funcionalidade do asset que deve ser detalhada Classifica o classifica o do asset como uma lista de palavras chaves para habilitar recupera o futura por exemplo se asset for um componente indicar o tipo classes de C fun es de C aplica o de OpenDoc 2 Caracter sticas de Reutiliza o Usabilidade descri o de como o asset pode ser utilizado corretamente Instala o descri o de como adaptar o asset em uma nova aplica o Adapta o descri o de como e para que necessidades espec ficas pode ser adaptado o asset Implementa o descri o de como o asset est implementado Suporte onde adquirir ajuda se necess rio for por exemplo ao adaptar o componente ou o que fazer se um problema ocor
280. tes s o avaliados os procedimentos de uma organiza o para trabalhar com e para reuso Quantidade de reuso N vel de reuso Frakes Terry TERRY 1993 FRAKES et al 1994 Assume que um sistema consiste de partes onde itens de alto n vel s o compostos de itens de baixo n vel O n vel de reuso interno de um item de alto n vel definido como o n mero de itens de baixo n vel interno reusados dividido pelo n mero total de itens de baixo n vel no item de alto n vel Tamb m s o definidos n vel de reuso externo n vel total de reuso frequ ncia de reuso e complexidade Fra o de reuso Agresti Evanco AGRESTI 1992 A vari vel FNEMC definida como a fra o de unidades de software novas ou extensivamente modificadas FNEMC o 127 n mero de novos componentes mais o n mero de componentes modificados dividido pelo n mero total de componentes FNEMC igual ao valor 1 menos a fra o de reuso Modelos e m tricas orientadas a objeto Bieman Karunanithi BIEMAN et al 1993 Existem 3 perspectivas para reuso no ambiente de orienta o a objeto servidor cliente e sistema Atributos mensur veis de reuso de sistemas orientados a objeto incluem percentagens de c digo e classes que s o relacionamentos cliente servidor espec ficos e novos ou derivados An lise de modos de fracasso Frakes e Fox FRAKESa et al 1996 Um m todo para medir e melhorar um processo
281. testado 3 6 Todos os poss veis tipos de erro foram testados Total de itens do aspecto verificados Total de n o conformidades Instituto Militar de Engenharia P gina 1 2 147 Garantia da Qualdade de Software Checklist Teste de Integra o Vers o 1 2 VETIO01 03 Data da vers o 01 03 2004 Checklist Teste de Integra o Artefato Verificado CTTI001 03 As quest es devem ser respondidas ap s um breve contato como documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exoeto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero seguencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades Os testes de integra o t m como objetivo verificar a integra o entre os componentes Neste checklist quanto mais respostas negativas forem dadas s perguntas mais alto o risco do teste de integra o para alcan ar seu devido prop sito A arquitetura de software est completamente definida no documento do projeto A estrutura de dados globais est identificada O projeto de componente est completo para todos os m dulos dentro do sistema Uma sequ ncia de integra o foi estabelecida Os drivers e stubs foram definidos e des
282. theory perspective IEEE Transactions on Software Engineering v 22 n 4 Apr 1996 p 267 271 TEEE610 12 INSTITUTE OF ELECTRICAL AND ELETRONICS ENGINEERS IEEE Standard 610 12 Standard glossary of software engineering terminology IEEE Press 1990 TEEE828 INSTITUTE OF ELECTRICAL AND ELETRONICS ENGINEERS IEEE ANSI Standard 828 1990 Software configuration management plans IEEE Software Engineering Standard Collection 1990 TEEE1517 INSTITUTE OF ELECTRICAL AND ELETRONICS ENGINEERS IEEE Standard 1517 1999 Software life cycle processes reuse processes IEEE Standard for Information Technology 1999 IFPUG INTERNATIONAL FUNCION POINT USERS GROUP Counting practices manual Version 4 1 1 April 2000 Dispon vel http www ifpug org capturado em 20 de junho de 2002 IS08402 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO IEC 8402 Quality management and quality assurance vocabulary 2 Edition 1994 IS015504 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO IEC TR 15504 Information technology software process assessment 1998 Dispon vel http www sqi gu edu au spice capturado em 10 de abril de 2003 IS09126 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ISO TEC 9126 1 International standard Information technology Software product evaluation Quality characteristic and guidelines for their use 2000 JACOBSON I GRISS M JONSSON P Software reuse architecture process and
283. tivo com o artefato em quest o cujo prop sito de garantir que os processos de Engenharia de Dom nio e de Desenvolvimento estejam sendo seguidos atividades tarefas e artefatos Todos os Comit s de Qualidade dos rg os Descentralizados de Fornecimento de Software devem se reportar ao Grupo da GQS Corporativo de forma que este possa obter subs dios para verificar as necessidades e oportunidades para realizar a melhoria do processo de toda a corpora o quanto ao processo de desenvolvimento de software 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 tricas deve ter especialistas em estat sticas para fornecer suporte aos projetos da corpora o com finalidade de analisar os dados consolidados dos rg os Descentralizados de Fornecimento de Software As 56 ferramentas estat sticas como Gr ficos de Controle Histogramas e Pareto devem ser usadas para an lise e melhoria do processo importante ressaltar que o Comit da Qualidade n o pode ser visto como fiscalizador O papel do consultor ou facilitador da qualidade apoiar as equipes de desenvolvimento para melhoria da qualidade de seus projetos No entanto n o se pode fugir do papel de fiscalizador caso a equipe seja resistente a trabalhar com base no processo Todos os resultados devem ser reportados para a Ger ncia de Reuso pois esta precisa ter visibilidade do que est acontecendo Pode s
284. to Instituto Tecnol gico da do Ex rcito de Tecnologia da Aeron utica Informa o Navais Material da Marinha Navega o da Informa o Tecnologia Controle A reo Diretoria de Direioria de Sistema Diretoria de Centro de Comando em Chefe Administra o da x Hidrografia e H Desenvolvimento de a de Armas da Marinha ju i Marinha Navega o Sistemas Diretoria de Centro Integrado de Telecomunica o da Telem tica do Matinha Ex rcito Centro de Computa o da Aeron utica de Bras lia Centro de Apoio Sistemas Operativos instituto Militar de Engenharia Centro de instituto de Pesquisa Centro integrado de Instituto de Pesquisa Computa o da da Marinha Guerra Eletr nica Desenvolvimento Aeron utica de S o J s dos Campos Diretoria Material de Centro de LL Ditetaria de Servi o Comunica es computa o da Geogratico Eletr nica Aeron utica do Rio Inform tica de Janeiro FIG 3 1 2 Grupo da Garantia da Qualidade de Software GGQS no contexto do MD Os Consultores da Qualidade n o devem fazer parte da equipe de desenvolvedores montadores J o Grupo de GQS deve ser formado por desenvolvedores montadores selecionados pelo Comit de Qualidade para exercerem o papel de verificadores revisores de artefato desde que n o tenham v nculo opera
285. to Este aspecto deve verificar os defeitos de utiliza o de armazenamento 10 1 Os objetos e os conjuntos de refer ncias de array s o nulos uma vez que os objetos ou arrays n o s o mais necess rios 10 2 Os arrays s o suficientemente grandes Total de itens do aspecto verificados Total de n o conformidades Verificador Tempo de prepara o N vel de conhecimento do dom nio Tempo de realiza o da verifica o 0 baixo 1 m dio 2 alto Qtde linhas de c digo n o coment rio Data da Verifica o Assinatura Restrito Instituto Militar de Engenharia 145 Garantia da Qualdade de Software Checklist C digo Fonte em Java Vers o 1 5 VECF00 1 03 Data da vers o 01 03 2004 Checklist C digo Fonte em JAVA Artefato Verificado pacote CTCF00 1 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 11 Aspecto Defeito de Interface Este aspecto deve verificar os defeitos de assinatura de m todo 11 1 O n mero
286. to a reutiliza o n o trivial ela apresenta muitos problemas os principais s o A localiza o e recupera o dos componentes de software a partir de uma grande cole o GIORARDI 1998 Aus ncia da pr tica de reuso nos processos de desenvolvimento de projetos das organiza es FICHMAN 2001 O reuso requer mudan a na forma de pensar IEEE1517 1999 Ao praticar reuso espera se que as equipes de desenvolvimento n o se concentrarem em um nico produto de software mas em um grupo de produtos relacionados pelos requisitos fun es e aspectos comuns Al m disso espera se que os desenvolvedores construam assets para serem reusados sempre que ocorram os mesmos respectivos requisitos nas especifica es ou um subconjunto de requisitos que correspondam ao conjunto de requisitos do artefato a ser reutilizado Portanto isto requer frequentemente uma generaliza o do asset conformidade com padr es e uma estrat gia de projeto para o produto de software ALMEIDA et al 2003 Para o sucesso da pr tica do reuso de software os seguintes crit rios devem ser seguidos Determina o grau em que um asset pode ser usado em mais de um sistema de software ou construir outros assets Especifica es podem ocorrer em v rios n veis de abstra o desde a especifica o de requisitos de um sistema at a especifica o de projeto detalhado de m dulos ou classes 11 46 As organiza es devem ter um programa de reu
287. to de software baseado em reuso de assets artefatos criados com o prop sito expl cito de serem posteriormente reutilizados Este processo promove o desenvolvimento de projetos e de assets de forma eficaz com base em aspectos qualitativos e quantitativos Os indicadores quantitativos asseguram um melhor planejamento e controle de projetos e de assets do reuso no desenvolvimento de aplica es utilizando m tricas e modelos de software indicadores de qualidade produtividade e reusabilidade Este trabalho est baseado nas defini es de padr es de processos mais utilizados atualmente pelas industrias e organiza es tais como CMM CMMI ISO 9000 ISO 12207 e ISO 15504 al m da Norma IEEE1517 Os processos estabelecidos neste trabalho abrangem diferentes n veis de maturidade do CMM tais como pontos de revis o e checklists nas diversas fases do processo de desenvolvimento de software N vel 3 Definido e tamb m a defini o de um processo de medi o N vel 4 Gerenciado As verifica es e revis es empregam t cnicas de leitura baseada em perspectiva e t cnicas de leitura horizontal e vertical respectivamente A implanta o do processo desenvolvido neste trabalho possui quatro fases implanta o de um processo de garantia de qualidade no processo de desenvolvimento de assets defini o dos modelos de qualidade dos artefatos dos objetivos da avalia o e de indicadores aplica o de t cnicas de qualidade e utiliza
288. to em quest o Mas a parte principal do processo de inspe o a detec o de defeitos por t cnica de leitura de documentos e o registro de n o conformidades detectadas Todo o material gerado do artefato deve ser lido as n o conformidades anotadas e uma estat stica das n o conformidades detectadas deve ser posteriormente realizada para fins de trabalho futuro da efic cia do procedimento ABNT12207 1998 HAZAN 1999 LAITENBERGER 2002 2 1 2 2 T CNICAS DE LEITURA DE SOFTWARE Uma abordagem para identificar defeitos em artefatos diferente da abordagem ad hoc normalmente utilizada na maioria dos casos fornecida pelas t cnicas de leitura de software Uma t cnica de leitura uma s rie de procedimentos ou estrat gias preparada para an lise de um artefato que permite alcan ar a compreens o necess ria para uma determinada tarefa BASILI et al 1996 As t cnicas de leitura aumentam a efici ncia dos revisores por fornecerem diretrizes do que procurar j que estas t cnicas propiciam que o resultado da atividade de detec o de defeitos seja menos dependente dos fatores humanos como a experi ncia Em vez dos revisores aplicarem apenas seus pr prios conhecimentos e t cnicas as t cnicas de leitura agregam o conhecimento sobre as melhores pr ticas para detec o de defeitos em um procedimento que pode ser seguido e repetido Essas t cnicas de leitura auxiliam a identifica o de defeitos e melhoram o processo de revis o
289. to varia de acordo com a situa o a que se destina o software Por exemplo o que defeito para uma aplica o pode n o o ser para outra ROCHA et al 2001 As classes de defeito n o s o ortogonais ou seja um defeito pode se enquadrar em mais de uma categoria Segundo TRAVASSOS et al 1999 a taxonomia de defeitos pode ser classificada em Omiss o omiss o de informa es necess rias sobre o sistema no artefato Fato incorreto contradi o entre as informa es do artefato e a especifica o de requisitos conhecimento do dom nio Inconsist ncia inconsistentes nas informa es contidas em um artefato Ambigiidade ambigiiidade nas informa es do artefato que pode levar a uma implementa o incorreta Informa o estranha as informa es s o verdadeiras mas n o se aplicam ao dom nio Na ltima revis o da ISO IEC 9000 2000 ABNT9000 2001 a principal modifica o o objetivo da garantia da qualidade Na vers o anterior o objetivo significava atendimento aos requisitos especificados que passou nesta nova vers o para a satisfa o do cliente A satisfa o do cliente envolve tanto os requisitos expl citos como os impl citos ou seja a satisfa o est diretamente relacionada com a qualidade dos produtos e servi os fornecidos como por exemplo suporte ao usu rio final As empresas t m investido mais no aumento da efici ncia do desenvolvimento de software prazos menores e menos recu
290. todo apresenta algumas dificuldades como LAITENBERGER 2002 66 Freqiientemente esta abordagem se tornar n o sistem tica devido s perguntas serem gerais e n o adequadas suficientemente a um determinado ambiente de desenvolvimento provendo pouco apoio para o verificador entender o artefato inspecionado Falta de uma estrat gia de como usar o checklist para responder a uma determinada pergunta N o fica claro que abordagem os verificadores devem seguir ao usar um checklist e como eles chegam aos seus resultados defeitos detectados O verificador pode conduzir uma nica pergunta por todo o artefato responde a pergunta e segue para a pr xima pergunta ou o verificador l o documento e depois responde as perguntas do checklist As perguntas do checklist s o frequentemente limitadas detec o de defeitos que pertencem a tipos espec ficos de defeitos Como os tipos de defeito est o baseados em informa o de defeito ocorrido em experi ncias passadas CHERNAK 1996 os verificadores podem n o focalizar nos tipos de defeito que n o tenham sido anteriormente detectados ocasionando perda de classes inteiras de defeitos Para tratar das dificuldades supracitadas neste subprocesso a lista de confer ncia checklist deve seguir os seguintes princ pios O comprimento da lista de confer ncia n o deve exceder a uma p gina ou a trinta e cinco quest es mas se for necess rio ultrapassar esta medida ent o designar verifica
291. tor data type DadosHistorico posi o Posi o data hora Data hora vento Real 177 dadosTaticos DadosT ticos distPasSeg short idl data type DadosAmbiente Veto rl corrente Vetor num Acomp short idl dad osHistorico DadosHistorico data type Vetor marca o shori idl inte nsidade short idl data type PMA Vetor short id data type Posi o latGraus short idl latMin short idl latSeg short idl norteSul string longGraus short idl longMin short idl longSeg sho rt idl lesteOeste string Interface da Camada de Aplica o interface type configura o inserir in dadosConf DadosCont shortfidl interface type latualPlat atualPlat in numAcomp shortfid in posicao Posi o short idl interface type linsDadosAmb insDadosAmb in ventoRelativo Vetor in velocRelativa Vetor shorifid interface type laberturaAcomp abrirAcomp in posi o Posi o short idl do Controle T tico interface type IcancelAcomp cancelar in numAcomp short id short idl interface type lextra o extrairP LatPrim Plataforma Prim ria extrairPosEst Prim DadosHistorico extrairA companhamento Acompanhamento extrairAcompDadosHist DadosHistoricol extrairA larmeColisao Acompanhamentof Modelo de Caracter stica do Controle T tico Controle
292. tualdo D E a or Dom nio Dom nio do om nio Cen rios Caracter sticas baseado m todo Diagrama de Diagrama de Casos de Uso baseado m todo Classe Descri o dos Cen rios FORM Projeto de Dom nio Especifica o da Arquitetura de Dom nio Interfacesda Interfacesda Diagrama de Araui o rquiteturade eae hea Camadade Camadade Interagoes orla Diagramade Neg cio Aplica o Diagrama de Diagramade Classe Diagramade Diagramade Seqgu ncia Classe Classe Classe Colabora o Projeto de Dom nio Especifica o dos Componentes de Dom nio Especifica o de Componentes do Dom nio Diagramade Classe FIG 3 2 1 2 2 2 Conjunto das T cnicas de Leitura Horizontal e Vertical Cada inspe o deve empregar a T cnica de Leitura Vertical TLV e Horizontal TLH baseada em TRAVASSOS et al 2003 E cada revisor deve direcionar sua leitura por um cen rio espec fico ao inv s de uma leitura passiva O cen rio um procedimento que o revisor deve seguir durante a inspe o consistindo de atividades repet veis que um revisor precisa executar e de verifica es que um revisor deve certificar Desta forma esta t cnica de leitura procura abranger as mais diversas classes de defeitos O resultado desta reuni o deve ser uma lista de n o conformidades as quais devem ser numeradas segiiencialmente e anotadas no Relat rio de Revis o pelo secret rio N
293. type X interface type lalarmeColisao IplatM gt Componente Calcula PMA comp esp f CalculaPMA a interface type IcalculaPMA calcular in pos Referencia Posi o in posAcomp Posi o in dadosReferencia Vetor in dadosAcomp Vetor PMA I interface type Soma Veto rial Componente Calcula Rumo e Velocidade comp esp CalculaRV interface type IcalculaRV calcular sa da dadosHistoricos DadosHistorico DadosHistorico 4 yyrinterface type ISomavV eto rial Componente Calcula Rumo para Passagem Segura comp esp CalculaRPS a interface type calcular in posReferencia Posi o in posAcomp Posi o in dados Referencia Vetor in dadosAcomp Vetor Vetor aulas I fim nt e e poi i aa gt i interface type gt interface type Iconversao ISomaVetorial 184 9 GLOSS RIO DE TERMOS T CNICOS E EXPRESS ES USADAS AN LISE DE PONTOS POR FUN O T cnica de avalia o de um sistema conhecida como FPA Function Point Analysis baseada na medi o do valor das fun es executadas pelos programas ao inv s de utilizar como base o volume ou a complexidade do c digo dos programas A t cnica est baseada na vis o externa do usu rio sendo portanto independente da linguagem utilizada permitindo calcular o esfor o de programa o e auxiliando o usu rio final a melhorar o exame e avalia o de projetos IFPUG 2000 ARTEFATO s m
294. uantidade de dados coletados e o gerenciamento dos mesmos um aspecto cr tico Caso n o seja poss vel a coleta de dados automatizada a organiza o deve definir padr es templates para obten o dos dados assegurando assim a melhoria da qualidade dos dados obtidos MCGARRY et al 2001 Dentro do contexto de programa de medi o os termos indicadores medida e m trica s o empregados conforme a defini o a seguir STAA 2002 M trica medida quantitativa de um atributo As m tricas podem ser objetivas ou subjetivas medidas relativas ao alto ou baixo grau de precis o respectivamente diretas ou indiretas medidas simples ou derivadas de outras medidas respectivamente e de produto ou de processo medidas da qualidade do produto ou da qualidade do processo respectivamente Por exemplo n mero de defeitos por linhas de c digo 38 Medida avalia o de um resultado perante uma unidade padr o Por exemplo 1000 linhas de c digo Indicador forma de representa o quantitativa de caracter sticas de produtos e de processos utilizado para acompanhar avaliar e melhorar os resultados ao longo do tempo Por exemplo aumento no n mero de defeitos detectados na nova vers o do produto de software O modelo de qualidade elaborado por MCCALL et al 1977 foi o primeiro dos modelos que prop s qualidade de produto de software como uma hierarquia de fatores crit rios e m tricas Esfor os internacionais tamb m conduziram
295. ui todas as caracter sticas desejadas que o sistema precisa ter s s 3 4 Todas as refer ncias internas das necessidades est o corretas s s 3 5 As necessidades fornecem uma base adequada para o projeto s s 3 6 A prioridade de implementa o das necessidades est definida s s 3 7 Todo hardware software e interfaces de comunica o est o definidos s n 2 3 8 Os algoritmos intr nsecos para as necessidades funcionais est o definidos s s 3 9 A necessidade inclui todo o conhecimento do cliente ou necessidades de sistema s s 3 10 O comportamento esperado est documentado para todas as condi es de erro s s 3 11 Todas as fun es cr ticas de tempo est o identificadas e seus crit rios de tempo especificados s s Total de itens do aspecto verificados Total de n o conformidades 1 FIG 4 2 2 2 1 a Itens do Checklist de Necessidades do Cliente e Gloss rio 96 N o Conformidades Detectadas Artefato Verificado CTNC001 03 Identificar e comentar brevemente os defeitos detectados O numero de identifica o Id deve sero mesmo fornecido na coluna Identifica o do checklist id o Coment rios _ OE Os itens 5 8 5 9 5 11 6 5 5 e 6 5 6 est o em desacordo em Necessidades do Cliente 2 Falta defini o dos tipos de monitores a serem usados FIG 4 2 2 2 1 b Coment rios dos itens do Checklist de Necessidades do Cliente e Gloss rio que n o est o em conformidades
296. uisitos projeto e implementa o As falhas decorrentes destes defeitos dependem de como o produto de software usado e das op es do programa selecionadas e n o do tempo decorrido 2 1 Maturidade Evidencia a frequ ncia de falhas causadas por defeitos no software 2 2 Toler ncia a falhas Evidencia sua capacidade em manter um n vel de desempenho no caso das falhas no software ou de viola o nas interfaces especificadas 2 3 Evidencia sua capacidade de reestabelecer seu n vel de desempenho e recuperar os dados diretamente afetados em caso de falha e o tempo e esfor o necess rio para tal Recuperabilidade Evidencia o quanto o software est de acordo com as normas conven es ou regulamenta es relacionadas confiabilidade da aplica o Conformidade Usabilidade Conjunto de atributos que evidenciam o esfor o necess rio ao uso bem como a sua homologa o individual por um conjunto de usu rios estabelecido ou subentendido 3 1 Inteligibilidade Evidencia o esfor o do usu rio para reconhecer o conceito l gico e sua aplicabilidade 3 2 Apreensibilidade Evidencia o esfor o do usu rio para aprender sua aplica o por exemplo controle de opera o entradas sa das 3 3 Operacionalidade Evidencia o esfor o do usu rio para sua opera o e controle da sua opera o 3 4 Atratividade Evidencia sua capacidade de ser atrativo ao usu rio como uso de cor
297. ula I concatenado com o nome da classe do neg cio Caso n o tenha o padr o preencha a Tabela de Discrep ncia pois pode haver falta de padr o ou ambigiiidade relatando a necessidade de conhecimento adicional para compreens o Para cada atributo da classe de neg cio verifique se na classe de interface existe um m todo p blico correspondente para acess lo leitura e escrita 1 Caso contr rio preencha a Tabela de Discrep ncia pois um m todo de uma interface n o est presente na Interface da Camada de Neg cio Il Reveja a Interface da Camada de Neg cio para assegurar que todas as classes e seus relacionamentos e Restrito atributos est o sendo levados em considera o ENTRADAS Interface da Camada de Neg cio marcados com asterisco azul e verde sublinhado em azul e real ado em amarelo SA DAS Relat rio de Discrep ncias A Reveja as classes seus atributos e relacionamentos para ter certeza que todas as classes de neg cio est o corretamente capturadas na classe correspondente da Interface da Camada de Neg cio 1 Certifique que n o existe nenhuma classe do tipo core sem asterisco azul Caso exista alguma preencha a Tabela de Discrep ncia pois uma classe na Interface da Camada de Neg cio n o est presente no Modelo Tipo do Neg cio 2 Certifique que n o exista nenhuma classe do tipo interface sem asterisco verde Caso exista alguma preencha a Tabela de Discrep ncia pois uma class
298. uldades na realiza o da verifica o e expressaram certo conforto quanto utiliza o dos checklists Tamb m foi verificado o grau de conhecimento de cada verificador por exemplo conhecimento em OO e design patterns para atribuir o artefato apropriado ao conhecimento do verificador Na FIG 4 2 2 2 1 a apresentada parte da aplica o do checklist baseado em aspecto em b as anota es das n o conformidades detectadas para Necessidades do Cliente e Gloss rio e em c o respectivo Relat rio da Verifica o Checklist Necessidades do Cliente e Gloss rio Artefato Verificado CTNCO01 03 As quest es devem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fornecer a resposta adequada S Sim 7 N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com n mero sequencial para identifica o do erro detectado Todos os erros detectados devem ser identificados e comentados na parte de N o Conformidades 1 Aspecto Apresenta o do Documento Este aspecto deve analisar as quest es gerais de apresenta o do documento P Cc I 1 1 O documento esta de acordo com o tempiste padr o s n 1 2 O documento teve ortografia e gram tica checada s s 1 3 O documento est livre de erros de layout s s 1 4
299. utiliz veis para futuro reuso FRAKESb 1996 Reposit rio de Assets Reutilizaveis Equipe de Desenvolvimento FIG 2 2 1 1 Procedimentos para reuso de software importante que a documenta o seja considerada uma parte essencial do asset pois sem sua pr pria documenta o um asset in til Nem pode ser recuperado quando for necess rio e nem pode ser reusado e adaptado com esfor o razo vel Desta forma a documenta o de cada asset deve ser clara concisa e auto suficiente para agilizar e viabilizar os seguintes aspectos a avalia o de assets em um conjunto de poss veis candidatos a compreens o da funcionalidade de um asset o uso de um asset em um certo ambiente e a adapta o de um asset para necessidades espec ficas SAMETINGER 1996 49 2 2 2 MODELOS E M TRICAS As m tricas s o necess rias para avaliar a robustez da arquitetura em termos das mudan as de requisitos requererem mudan a na arquitetura Tamb m s o necess rias m tricas para determinar a perda da reutiliza o em virtude de sucessivas manuten es A perda de reutiliza o ocorre quando uma vers o de artefato particionada em v rias vers es coexistentes em virtude da necessidade de cada uma dessas vers es necessitar de aten o espec fica pela ger ncia de configura o e ao realizar novas altera es ALMEIDA et al 2003 A literatura destaca algumas m tricas importantes veja TAB 7 2 1 do AP NDICE 2 M tri
300. utilizadas pela equipe de desenvolvimento trouxe um grande desconforto e gerou incertezas por estar atuando em patamares desconhecidos Por isso a implanta o de um programa de qualidade n o uma tarefa simples e requer habilidade para mostrar ger ncia que os novos processos v o melhorar e agilizar planejamentos e acompanhamentos das atividades e consequentemente dos projetos Para os t cnicos importante evidenciar que o ganho com planejamentos e reusos aumenta o trabalho produtivo da equipe de desenvolvimento medida que o retrabalho nas atividades tende a n o ocorrer Para tal o processo de Medi o e Avalia o fundamental para controlar e avaliar os produtos de software e os processos envolvidos para gera o destes produtos 5 1 BENEF CIOS O principal benef cio deste trabalho o desenvolvimento de um processo de garantir a qualidade de software que se integre plenamente ao processo de reuso sistem tico proposto por GURGEL 2004 para o Minist rio da Defesa e de seus Comandos Subordinados Com base neste processo de qualidade a melhoria da qualidade dos artefatos produzido na especifica o de an lise e projeto de dom nio e do pr prio desenvolvimento do projeto possibilita um aumento no reuso destes artefatos Outro benef cio reside no processo de medi o que quantifica a qualidade e a produtividade do processo de desenvolvimento baseado em reuso fornecendo uma base quantitativa para a avalia o das
301. vas as Questions Desta forma foram selecionadas as m tricas mais relevantes apresentadas acima junto aos Goals para a constru o dos indicadores Depois baseado na Constru o Mensur vel que descreve como os atributos de qualidade de software s o quantificados e convertidos para indicadores foi estabelecida a especifica o para cada indicador como apresentado a seguir 4 2 4 1 1 INDICADORES DE QUALIDADE DO PROCESSO DE VERIFICA O E REVIS O IQPVR Na TAB 4 2 4 1 1 apresentado o modelo GQM Goal Question Metric aplicado as n o conformidades detectadas durante as atividades de verifica es e revis o pelas listas de confer ncias checklists e t cnicas de leitura verticais e horizontais respectivamente Abaixo segue uma descri o mais detalhada dos quatro tipos de m tricas apresentadas na TAB 4 2 4 1 1 que tratam os estados das n o conformidades encontradas no processo de Verifica o e Revis o a saber N o Conformidade Detectada o Grupo de Garantia de Qualidade de Software GQS encontra uma n o conformidade durante a verifica o revis o dos artefatos N o Conformidade Resolvida Dentro do Prazo a equipe de desenvolvimento resolve a ocorr ncia de n o conformidade no prazo estabelecido pelo Grupo de GQS 108 N o Conformidade Resolvida Fora do Prazo a equipe de desenvolvimento resolve a ocorr ncia de n o conformidade com atraso O prazo estabelecido pelo Grupo de GQS estourado
302. vidades do Subprocesso de Revis o s o detalhadas a abaixo SPR A1 PLANEJAMENTO O Consultor de Qualidade deve criar e documentar um Plano de Revis o para as fases de An lise e Projeto do Dom nio da Engenharia de Dom nio do Processo ao Longo do Projeto conforme o PGQSP usando um modelo e cronograma adequado ao projeto de desenvolvimento do software para definir para cada atividade os recursos cronograma e procedimentos para gerenciar as revis es dos artefatos A sequ ncia de tarefas da atividade Planejamento consiste em SPR Al 1 Agendar as reuni es das revis es peri dicas nos marcos estabelecidos no Plano de Ger ncia do Projeto conforme o t rmino das atividades An lise de Dom nio Especifica o da Arquitetura de Dom nio durante a atividade Projeto de Dom nio e Especifica o de Componentes do Dom nio para avalia o dos artefatos produzidos SPR A1 2 Estabelecer as t cnicas de leitura para revis es individuais dos artefatos que v o compor os assets da Engenharia de Dom nio Para cada t cnica de leitura horizontal e vertical um procedimento estabelecido para verifica o e certifica o de um conjunto de informa o dentro do contexto dos objetivos do tipo da t cnica Para estas t cnicas devem ser reutilizados modelos aplic veis se existirem 73 SPR A1 3 Selecionar os membros que v o compor a reuni o da revis o relativa ao artefato a ser examinado Al m disso deve definir local instala es ha
303. vos As mensagens de entrada de dados est o leg veis s Total de itens do aspecto verificados Total de n o conformidades Restrito Instituto Militar de Engenharia P gina 3 4 150 Garantia da Qua lda de de Software Checklist Teste de Valida o Vers o 1 2 VETV001 03 Data da vers o 01 03 2004 Checklist Teste de Valida o Artefato Verificado CTTI001 03 As quest es de vem ser respondidas ap s um breve contato com o documento A coluna P Previs o cont m a resposta correta desejada e na coluna C Confirma o o revisor deve fomecer a resposta adequada S Sim N N o NA N o se aplica Caso a resposta da Coluna C diferencie da coluna P exceto quando n o se aplica NA a coluna Identifica o deve ser preenchida com numero sequencial para identifica o do erro detectado Todos os erros detecta dos devem ser identificado s ecomentados na parte de N o Corformidades Os testes de valida o t m como objetivo verificar os requisitos do software Neste checklist quanto mais respostas negativas forem dadas s perguntas mais alto o risco doteste de valida o para alcan ar seu devido prop sito Uma especifica o completa dos re quisitos de software est dispon vel Existe limita o para os requisitos Classes equivalentes foram definidas para testar entradas Foram realizados testes de limite para verificar os limites do software Os sripts de teste foram desenvolvidos para vali
304. y applying metric software models quality indicators productivity and reusability This work is based on the process standard definitions more frequently used presently by industries and organizations such as CMM CMMI ISO 9000 ISO 12207 and ISO 15504 and also the IEEE1517 Standard The processes established in this work include different CMM maturity levels such as revision points and checklists in the several phases of the software development process Level 3 Defined and also the measurement process definition Level 4 Managed The verifications and revisions use reading techniques based on perspective as well as horizontal and vertical reading techniques respectively The process implantation developed in this work is divided into four phases implantation of quality warranty process on the assets development process definition of the software products quality models definition of the evaluation objectives and indicators usage of quality techniques and usage of the indicators to promote process improvement Besides this a case study is presented applying the software warranty process defined on a pilot project a Tactical Controller developed according to a reuse based Software Development Process under the Defense Ministry Context and of their Subordinate Commands of GURGEL 2004 This case study points out that the used strategy can increase quality of the final conceptual model as well as of the software production process

Download Pdf Manuals

image

Related Search

Related Contents

Bedienungsanleitung PCA 410  Arat NS1245 holder  水道工事標準仕様書2013（6月1日改訂版） [1664KB pdf  DSC-W350/W350D/W360  guide-fonctions-add-phone (201.6 Kio)  C. LA TEMPERATURE  Avaya Communication Server 1000 IP Phone 2007 User Guide  1 - Sony  Le livret d`accompagnement - Canopé Clermont    

Copyright © All rights reserved.
Failed to retrieve file