Home

da Monografia - Departamento de Sistemas e Computação

1. esc cesreseornascenseaceaenda 31 FIGURA 3 DIAGRAMA DE ENTIDADE RELACIONAMENTO N VEL L GICO 32 FIGURA 4 DIAGRAMA DE ENTIDADE RELACIONAMENTO N VEL F SICO 33 FIGURA 5 DIAGRAMA DE FLUXO DE DADOS DEI A 5 34 FIGURA 6 DIAGRAMA DE FLUXO DE DADOS DE 6 A 9 35 FIGURA 7 DICION RIO DE 36 FIGURA 8 TELA INICIAL DO SOFTWARE DE APOIO AO PROCESSO DE VERIFICA O DE SOFTWARE a Ri a ri 38 FIGURA 9 TELA DE CADASTRO DA 39 FIGURA 10 TELA DE CADASTRO DO 39 FIGURA 11 TELA DE CADASTRO DAS PERGUNTAS DO CONTRATO 40 FIGURA 12 TELA DE REGISTRO DO PLANO DE 41 FIGURA 13 TELA DE SELE O DAS PERGUNTAS DA ATIVIDADE DO CONTRA TO 42 FIGURA 14 C DIGO FONTE DA 43 FIGURA 15 TELA DA CONSULTA DAS PERGUNTAS DA ATIVIDADE DO CONTRATO RS 44 FIGURA 16 TELA DA VERIFICA O 45 FIGURA 17 RELAT RIO DAS PERGUNTAS DA ATIVIDADE D
2. o rg o certificador faz uma visita empresa colhe mais dados e explica o processo de certifica o d o rg o certificador verifica se a documenta o do sistema de qualidade est de acordo com a norma ISO e o rg o certificador envia uma equipe empresa com fins de auditoria Nesta visita ser verificado se todos na empresa cumprem o que est documentado no manual de qualidade f o rg o certificador emite o certificado de qualidade g o rg o certificador realiza visitas peri dica empresa par assegurar que o sistema continua sendo efetivo Apesar de um processo de desenvolvimento de software ser considerado distinto dos demais processos de fabrica o de outros produtos conforme a norma ISO 9000 3 da extremamente necess rio que esse campo de tecnologia seja provido de orienta es adicionais para o estabelecimento de sistemas da qualidade onde estejam envolvidos os produtos de software ABNT 1993 A norma ISO 9000 3 define algumas diretrizes a fim de tornar poss vel a aplica o da NBR 19001 nas organiza es que desenvolvem fornecem e mant m software Estas diretrizes destinam se a descrever os controles e m todos sugeridos para a produ o de software que atendam aos requisitos do comprador evitando se n o conformidades em todos os est gios 3 4 PROCESSO DE VERIFICA O SEGUNDO A NORMA ISO 9000 3 A norma ISO 9000 3 determina que uma organiza o deve definir document
3. Verifica o da documenta o Observa se a documenta o est adequada completa coerente se est sendo desenvolvida no prazo e se o gerenciamento de configura o dos documenta o Os requisitos de entrada para cada fase do desenvolvimento devem ser definidos e documentados de modo que o seu atendimento possa ser verificado 6 2 Deve se avaliar a documenta o SUP 4 1 segue os procedimentos especificados 6 4 2 7 O resumo do comparativo foi realizado da seguinte maneira tornou se uma atividade como refer ncia que foi retirada da norma ISO IEC 12207 cuja atividade correspondia a um processo ou uma cl usula das normas Essa atividade foi colocada na primeira coluna do quadro Nas outras colunas foram colocadas lado a lado as atividades correspondentes as normas sendo que em alguns casos n o havia uma atividade correspondente nesse caso foi deixado um espa o em branco Na coluna Atividades foram colocados os processos cl usulas que apresentavam maior facilidade de interpreta o e abrang ncia ao assunto proposto sendo que a maior parte dessas atividades foi obtida da norma ISO IEC 12207 por ela ser a mais completa referente ao processo de verifica o de software Foi realizado um mapeamento das normas e modelos com o objetivo da possibilidade de uma an lise a partir da leitura e compara o do processo de verifica o dos itens em cada norma e modelo
4. 6 4 2 1 O fornecedor deve estabelecer e manter procedimentos para an lise critica de contrato e para a coordena o destas atividades Revis o do contrato o fornecedor deve estabelecer e manter procedimentos para a revis o do contrato e para a coordena o dessas atividades 5 2 1 A empresa tem o objetivo de avaliar um fornecedor em potencial obtendo o seu perfil de capacidade Para isso ela deve definir os objetivos e o contexto da avalia o os modelos e m todos de avalia o e os requisitos esperados O perfil de capacidade permite ao contratante estimar o risco associado contrata o daquele fornecedor em potencial para auxiliar na tomada de decis o de contrata lo ou n o SUP 4 Ger ncia de contrato de fornecedor tem o objetivo de gerenciar a aquisi o de produtos e servi os de fornecedores externos ao projeto para os quais existem um acordo formal Estabelecer contratos com fornecedores Satisfazer os contratos com fornecedores n vel 4 verifica o do processo Observa se o planejamento do projeto e a atribui o de tempos est o adequados se o que foi determinado no projeto est sendo seguido e est de acordo com o contrato se a equipe possui o treinamento desejado etc 6 4 2 2 Organiza o dos recursos do projeto programa o do projeto fases de desenvolvimento planos da qualidade procedimentos de verifica o i
5. 80 81 82 83 90 durante a instala o do software as responsabilidades de ambas as partes s o definidas em termos de disponibilidade de pessoal especializado durante a instala o do software as responsabilidades de ambas as partes s o definidas em termos de acesso aos equipamentos e sistemas do cliente durante a instala o do software as responsabilidades de ambas as partes s o definidas em termos de necessidade de valida o de cada instala o do produto h procedimentos para as atividades de manuten o requeridas h um plano de manuten o do software o plano de manuten o contempla o escopo da manuten o o plano de manuten o contempla a identifica o do status inicial do produto o plano de manuten o contempla a organiza o de suporte o plano de manuten o contempla os registros de manuten o e relat rios o plano de manuten o contempla as atividades de manuten o a identifica o efetuadas no software em fun o da manuten o s o documentadas e controladas para cada item de software que sofre manuten o h uma lista de solicita o ou relato de problemas recebido do cliente e o status atual de cada solicita o para cada item de software que sofre manuten o h respons veis para responder s solicita es ou para implementar a a o corretiva apropriada para cada item de software que sofre manuten o h prioridade atribu das s a es
6. 73 74 75 76 77 78 79 80 81 82 83 84 66 a implementa o do sistema da qualidade organizada documentada e verificada com organogramas descri es de cargos tarefas supervis o ou auditorias da qualidade todos os requisito importante relacionado funcionalidade ao desempenho s restri es de projeto ao atributo interface externa foram inclu do est definida a resposta do software para todas as poss veis situa es de entrada de dados todas as se es est o conforme a especifica o de requisitos todas as refer ncias de figuras tabelas e diagramas est o contempladas as informa es no artefato de software est o de acordo com as informa es presentes na especifica o de requisitos ou ao conhecimento geral do dom nio todos os requisito descrevem fato que verdadeiro est o de acordo as condi es solicitadas para o sistema os diagrama de projeto cont m as representa es do conceito descrito nos requisitos gerais do dom nio ou no documento de requisitos a representa o de um conceito dos requisitos gerais do dom nio ou do documento dos requisitos est o presente em todos dos diagramas de projeto as informa es em uma parte do artefato de software est o inconsistentes com outras no artefato de software nenhum requisitos entra em conflito com outro uma representa o de um conceito em um diagrama de projeto est em acordo
7. antes que o valor dos dados seja setado o valor do pointer deve estar setado antes que algu m tente setar o valor dos dados na fun o existe algum conceito ou uma id ia fundamental que possa ser facilmente expresso numa linguagem comum no c digo implementado 80 79 a fun o dessa parte do c digo est bem definida em rela o fun o geral do todo e tal fun o encontra se claramente expressa 80 a rotina encontra se protegida adequadamente de forma a poder desempenhar sua fun o confiavelmente apesar de um poss vel mau uso 81 forma independente do estilo adotado o c digo encontra se claro e definido quanto visto como um todo 82 ele significativo pra todas as classes de leitores que o usar o 83 existem segmentos de c digo repetido dentro ou entre as rotinas 84 os coment rios s o teis ou simplesmente desculpas para uma codifica o pobre 85 o n vel de detalhe consistente 86 os padr es est o sendo obedecidos 87 a inicializa o feita adequadamente a rotina tem um procedimento claro de desvio ou sa da 88 existem opera es redundantes para as quais n o h benef cios compensadores 89 o uso do armazenamento consistente tanto internamente quanto em rela o s especifica es externas 90 quanto custar modificar o c digo 91 o c digo simples 92 os nomes dos itens de dados est o em conformidade com seu uso 93 os itens de dados que preci
8. estabelecido um banco de dados sobre o processo e o sistema de qualidade s o centralmente mantidos e protegidos 68 69 70 71 72 73 74 15 76 77 78 79 80 81 82 83 84 85 86 87 59 mecanismos e responsabilidades s o estabelecidos para assegurar a defini o e o uso de m tricas padr es a produ o e acompanhamento dos planos de qualidade e a inser o apropriada de novas tecnologias mecanismos e responsabilidades s o definidos para assegurar que os profissionais t cnicos dos projetos aprovem e aceitem os planos de qualidade dos produtos e tornem se pessoalmente comprometidos em mant lo apoio inser o de tecnologias estabelecido incluindo apoio para a instala o e uso de ferramentas assist ncia utiliza o de novos m todos bem como customiza o do ambiente o procedimento de planejamento de projeto exige a identifica o de quem o respons vel por cada atividade de projeto e desenvolvimento os procedimentos exigem que o planejamento do projeto seja atualizado medida que o projeto evolui nessa segunda fase a preocupa o central com a estrutura o e viabiliza o operacional do projeto Nela a proposta de trabalho j aprovada detalhada por meio de um plano de execu o operacional detalhamento das metas e objetivos a serem alcan ados s o com base na proposta aprovada h alguma defini o do
9. o diferente elementos especificando a mesma coisa 112 todos os elementos est o contendo itens de especifica o relacionados com a sua inten o 113 todos os elementos cuja inten o seja completamente est o descrita pelos respectivos itens de especifica o 114 todos itens de especifica o de algum elemento acres am algo ao conjunto dos demais itens de especifica o desse elemento 115 poss vel adicionar itens especifica o tornando mais completa a inten o do elemento 116 0 escopo de um item de especifica o o menor poss vel 117 existem fun o retornando refer ncia ou ponteiro para espa o de dados local 118 todos os elementos inflex vel s o necessariamente utilizados 119 todos os elementos reutiliz vel s o necessariamente utilizados 120 todos os elemento da especifica o s o adequados ao usu rio 121 a verifica o est envolvida em qualquer um dos ciclos de controle do projeto e da produ o por exemplo revis o do projeto revis o da qualidade outros 122 como as especifica es de confiabilidade mantenabilidade e disponibilidade s o administradas do ponto de vista de projeto e verifica o por exemplo plano da qualidade especifica o do produto 123 0 projeto avaliado ou verificado em rela o aos requisitos do mercado por exemplo testes de verifica o modelos de computa o outros 124 existem controles que se aplicam durante as fases de projeto e ver
10. o operador tem de preparar a unidade de disco designada sen o o sistema simplesmente repetir a solicita o o operador deve preparar a unidade de disco designada mas se n o o fizer o sistema tomar atitudes alternativas uma unidade familiar consiste em uma m e e seus filhos e em um pai e seus filhos uma unidade familiar consiste em uma m e e um pai e todos os filhos cujos pais sejam aquela m e e aquele pai a inclus o dos elementos sempre cessar com a inclus o do elemento com a data atual a inclus o dos elementos cessar como o elemento com a data atual se n o for interrompida de outra forma como o t rmino da lista por exemplo o usu rio que escreveu esta especifica o criar um guia de operador o usu rio e o analista que s o os leitores desta especifica o criar o um guia de operador o nico modo de terminar uma sess o do terminal atrav s do comando desliga se o comando desligar for emitido a sess o do terminal termina se n o dever haver outras formas de terminar a sess o do terminal finaliza quando o comando de desliga for exibido o contador setado em zero quando a sub rotina foi invocada o contador setado em zero assim que a sub rotina for invocada e somente neste tempo o contador setado em zero sempre toda vez que a sub rotina for invocada o pointer ser setado antes que o valor dos dados seja algu m ter setado o valor do pointer
11. significativo 105 as transa es de testes desenvolvidas demonstra todos os casos testes 106 crit rios de testes das unidades est satisfeitos 107 crit rios de testes do sistema est satisfeitos 108 existem transa es criadas para pelo menos dois ciclos de execu o do sistema 68 109 s o demonstradas op es do sistema de fim de per odo m s ano 110 0s resultados dos testes preditos e documentados para compara o posterior com os resultados do computador 111 os resultados paralelos do sistema est o identificados para padr o de precis o 112 padr es de aceitabilidade e precis o est o estabelecidos e documentados para posterior avalia o dos resultados 113 a disponibilidade de mem ria em modo de produ o 114 a limita es de tempo em modo de produ o 115 transa es de testes s o alimentadas pelo departamento de entrada de dados utilizando procedimentos padr es 116 testes executados pelo pessoal de opera o tem supervis o do programador 117 a uma listagem de transa es obtida antes da execu o dos testes 118 dumps de arquivo s o obtidos antes da execu o dos programas 119 existem algum sistema que executado para demonstrar todos os casos de testes podem ser necess rias execu es m ltiplas do sistema ou de m dulos individuais 120 h obten o de todos os relat rios de controle via hard copy 121 h obten o da transi o de mensagens da console e da
12. conhecimento especial por exemplo procedimentos de sistema operacional 132 0 exemplo est correto 133 0 exemplo relevante 62 134 0 exemplo encontra se disposto na mesma seqii ncia que os materiais 135 0s pontos principais do exemplo s o refor ados adequada e corretamente 136 0 exemplo inteiramente coerente 137 05 pontos principais do exemplo est o diretamente relacionados com uma necessidade do mundo real em caso afirmativo como em caso negativo por que n o 138 0 m todo de apresenta o coerente com nossos m todos de reprodu o se for necess rio o uso de cores dispomos de recursos de reprodu o em cores 139 0 m todo de apresenta o coerente com nossos m todos de proje o 35mm 16mm super 8 filme cont nuo videocassete projetor de transpar ncia projetos de slides 140 0 m todo de apresenta o faz amplo uso dos recursos de edi o 141 ele usa recursos de edi o apenas por usar ou para melhorar o produto 142 a nota o e os s mbolos est o de acordo com as pr ticas atuais 143 ele coerente com nossos sistemas de computador onde necess rio 144 0 m todo de representa o consistente com o design do materiais a instru o auto ajust vel realmente auto ajust vel ou precisa ser programada 145 a forma do produto melhora ou reduz seu valor educacional 146 dado algum tipo de treinamento 147 a qualidade do treinamento e do programa de instala o
13. ndices 175 por via das d vidas colocar um elemento extra no final do arranjo 176 no caso de apontadores existe um isolamento aos apontadores em rotinas especializadas 177 checar os apontadores antes de usa los 178 checar as vari veis apontadas antes de usa las 179 usar campos de verifica o de erros em vari veis apontadas 180 anular o valor apontadores depois de libera los 181 usar apontadores extra quando isso contribuir para tornar o c digo mais leg vel 182 simplificar express es com apontadores 183 procurar formas seguras de controlar a aloca o e libera o de apontadores 184 documentar opera es sobre apontadores de prefer ncia em formato gr fico 185 checar na libera o de listas se a ordem de libera o dos apontadores correta 83 186 tipos estruturados de dados registros e estruturas devem ser usados para esclarecer relacionamento de dados 187 simplificar opera es sobre blocos de dados 188 simplificar listas de par metros dede que o agrupamento seja l gico 189 reduzir encargos de manuten o 190 s o declaradas todas as vari veis 191 as declara es s o acompanhadas de coment rios descritivos 192 iniciada todas as vari veis em sua declara o 193 minimizar o escopo das vari veis 194 usar cada vari vel com uma nica finalidade 195 minimizar o uso de vari veis globais 196 usar vari veis globais s em ltimo caso 197 todos os nomes descrev
14. o Codigo avaliador Endere o organiza o Nome avaliador Bairro oraganiza o Cargo avaliador Cidade organiza o Telefone avaliador UF organiza o Email avalidor Telefone organiza o Area atua o avalidor CGC organiza o CEP organiza o Realiza AN Plano de Verifica o Codigo plano verifica o o A Data inicio verifica o l avalia Data termino verifica o Hora inicio verifica o Hora termino verifica o Sele o Pergunta Descri o software possui Posssui Codigo pergunta Status contrato E Observa o Descri o pergunta Status processo Resposta Tipo Status requisitos Status projeto Status codigo Status integra o Status documenta o 33 FIGURA 4 DIAGRAMA DE ENTIDADE RELACIONAMENTO N VEL F SICO ORGANIZACAO CODIGO ORGANIZACAO Longlinteger CODIGO ORGANIZA O Longinteger AVALIADOR Longinteger NOME ORAGANIZACAO Text 80 ONES ENDERECO Text 50 BAIRRO ORAGANIZACAO Text 50 TELEFONE AVALIADOR Text 20 CIDADE ORGANIZACAO Text 20 UF_ORGANIZACAO Byte AREA ATUACAO AVALIDOR Text 50 TELEFONE Text 20 CGC ORGANIZACAO Texi 18 CEP ORGANIZACAO Text 8 CODIGO ORGANIZACAO CODIGO ORGANIZACAO PLANO DE VERIFICACAO CODIG
15. o h alguma rela o de faltas e defici ncias encontradas pelas ferramentas de apoio ao desenvolvimento existe alguma defini o dos casos de teste os resultados obtidos ao executar os testes s o verificados s o feitos laudos de avalia o dos testes s o realizados relat rios de problemas indicando o estado do problema a causa do problema e a solu o dada este relat rio cumulado e descreve a hist ria de evolu o do m dulo assegurado que cada programa adequado ao usu rio assegurado que cada programa opera exatamente conforme a sua especifica o assegurado que o conjunto de programas interagem conforme especifica o s o verificadas as implementa es de solu es s o controladas os processamento subseqiiente entrega e instala o do produto n o conforme at que a defici ncia ou condi o insatisfat ria tenha sido corrigida a identifica o documentada dos requisitos de verifica o e provis o dos recursos necess rios s o inclu do ao pessoal treinado para todas as atividades de verifica o existe independ ncia documentada daqueles que realizam atividades de verifica o em rela o aos que t m responsabilidade direta pelo trabalho sendo realizado existe independ ncia documentada daqueles que realizam atividades de verifica o em rela o aos que t m responsabilidade direta pelo trabalho sendo realizado 66 67 68 69 70 71 72
16. ria os materiais constantes da documenta o est o claros os diagramas quadros ou outros materiais visuais est o claros 70 71 72 73 74 15 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 s o usados sempre que necess rios s o relevantes onde foram usados contribuem para a compreens o s o claramente representados a uma quantidade apropriada de informa o a terminologia est clara s o consistentes por todos os documentos s o de acordo com os padr es as defini es est o corretas as defini es est o claras o gloss rio est completo existe terminologia t cnica em excesso quantidade apropriada de informa o o estilo de reda o claro os par grafos expressam apenas id ias correlatas e nada mais as unidades l gicas maiores s o segmentadas em subt tulos o n vel do texto alto demais para a audi ncia o documento dirige se ao leitor t pico ele faz voc dormir existe algum resumo os documentos cont m refer6encias adequadas existe um ndice se necess rio o ndice est bem colocado existe um ndice remissivo se necess rio o ndice remissivo est bem colocado o ndice est correto o ndice remissivo est correto as refer ncias s p ginas s o precisa existe verbetes para os tipos de consulta que os usu rios
17. tulos significativos s o significativos para o leitor 251 para o entendimento torna se mais claro pela especifica o de nomes usado uma forma constitu da de m ltiplas partes 252 05 nomes padronizados pela instala o s o usados para campos com utiliza es padr es 253 existe elemento no nome que por exemplo um prefixo identifica meio f sico ou o tipo de dado 254 05 r tulos referem se ao esquema do programa 255 eles identificam sua posi o segiiencial no programa 256 a estrutura da l gica auto evidente 257 a l gica adequada ao problema 258 a estrutura facilmente corrig vel 259 a l gica tem um fluxo de cima para baixo 260 uma t cnica padr o de projeto de programa est sendo utilizada 261 se componentes s o usados estes s o sens veis quanto fun o 262 se componentes s o usados estes t m entrada e sa da nicas 263 se componentes s o usados estes utilizam apenas desvios internos 264 todas as sub rotinas usadas est o agrupadas em conjunto 265 na pr tica de codifica o a l gica do programa auto evidente pela codifica o 266 as a es realizadas pela codifica o s o compreendidas 267 as finalidades de se usarem contadores e modificadores s o auto evidentes pela codifica o 26 perif ricos s o abertos apenas quando necess rios 269 5 perif ricos s o fechados quando n o s o mais necess rios 270 0s campos de dados s o formatados possibi
18. verificar desempenho e conformidade dos processos com padr es e procedimentos verificar correteza e completeza do software entregue e avaliar documentos revisar atividades de engenharia do software e assegurar que os defeitos encontrados ser o removidos dos produtos de trabalho e que os resultados ser o disponibilizados para os clientes e realizar testes para verificar atendimento aos requisitos 3 3 NORMA ISO 9000 3 Segundo Bento 2000 a ISO 9000 3 uma guia de aplica o da ISO 9001 NBR 19001 para o desenvolvimento fornecimento e manuten o de software A Norma ISO 9001 faz parte da s rie de normas ISO 9000 voltadas para a gest o e garantia da qualidade Estas normas especificam os requisitos m nimos para que as empresas possam assegurar a qualidade de seus produtos e servi os n o definindo modelos impondo sistemas de qualidade a serem implementados nas organiza es As empresas definem seus pr prios modelos de gest o da qualidade dependendo do seu tipo de neg cio e suas caracter sticas Conforme a norma ISO 9000 3 o processo de certifica o de uma empresa de software segundo as normas ISO 9001 9000 3 segue um conjunto de passos bem definidos ABNT 1993 a a empresa estabelece o seu sistema de qualidade b a empresa faz uma solicita o formal a um rg o certificador incluindo detalhes do neg cio da empresa escopo da certifica o solicitada e c pia do manual de qualidade 19
19. 323 existem defini es de todas as macros usadas 324 existe manual de instru es para execu o 325 pelo ponto de corre o identificada a partir da esquem tica do programa 87 326 f cil descobrir a raz o do uso de t cnicas modulares 327 f cil descobrir o porqu do uso de coment rios 328 f cil descobrir o porqu do uso de nomes significativos para r tulos ou par grafos 10 11 12 13 14 15 16 17 18 19 VERIFICA O DA INTEGRA O os componentes de software e unidade de cada item de software foram completa e corretamente integrados dentro do item do software os itens de hardware de software e opera es manuais do sistema foram completa e corretamente integrados ao sistema as tarefas de integra o foram executadas de acordo com um plano de integra o as fun es principais s o definidas de uma forma delimitadas sem ambig idades as interfaces entre os elementos do sistema est o definidas foram definidos limites de desempenho para o sistema como todo e para cada elemento a organiza o utiliza se de uma estrat gia definida para conduzir a integra o do produto atrav s da composi o de seus componentes existe uma pol tica organizacional documentada para assegurar a compatibilidade das interfaces internas entre os componentes de software e as interfaces de software com outros sistemas de software com o hardware com sistemas de s
20. 90 o plano prever tamb m como o projeto ser gerenciado 91 o plano identifica as regras pr ticas conven es ferramentas t cnicas e a ger ncia de configura o 92 o fornecedor verifica as sa das de todas as fases do desenvolvimento 93 o processo de planejamento monitorado com base em padr es e procedimentos aprovados pela rea de garantia da qualidade 94 m todos padr es s o desenvolvidos para estimativa e planejamento de projeto 95 medi es e an lise s o feitas entre o planejamento e o executado 96 a nfase organizacional sobre o planejamento e acompanhamento da qualidade 97 procedimentos documentados s o desenvolvidos para o planejamento da produtividade gera o de c digos reutiliz veis customiza o de componentes reutiliz veis 98 o plano de desenvolvimento contempla a defini o do projeto incluindo a declara o de seus objetivos bem como referencia o relacionamento com outros projetos da empresa e do cliente 99 a organiza o dos recursos do projeto incluindo a estrutura da equipe responsabilidades utiliza o de subcontratos recursos materiais e outros 100 0 cronograma e calendariza o do projeto as tarefas recursos e esfor os requerido para cada tarefa e qualquer inter relacionamento ente elas 101 a identifica o dos planos relacionados como plano da qualidade plano de ger ncia de configura o plano de integra o plano de teste 102 0 plan
21. a maturidade dos processos nas organiza es de software J a futura norma ISO IEC 15504 tamb m conhecida como SPICE constitui se de um padr o para avalia o do processo de software visando determinar a capacidade de uma organiza o A estrutura descrita na norma ISO IEC 12207 utiliza se de uma terminologia bem definida e composta de processos atividades e tarefas a serem aplicadas em opera es que envolvam de alguma forma o software seja atrav s de aquisi o fornecimento desenvolvimento opera o ou manuten o ABNT 1998 Entre esses processos encontra se o processo de verifica o O processo de verifica o define as atividades para verifica o dos 2 produtos de software um processo para determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condi es impostas a eles Segundo Rocha 2001 os procedimentos de verifica o n o s o mutuamente exclusivos mas sim complementares A verifica o pode ser aplicada no in cio e ao longo de todo o ciclo de vida do processo de desenvolvimento Na ess ncia as t cnicas de verifica o t m por objetivo identificar a presen a de defeitos ou erros in cio do processo de desenvolvimento e de certa maneira aprender com essa atividade e evoluir o desenvolvimento inclusive pela pr pria evolu o das t cnicas de verifica o utilizadas na empresa Conforme Rocha 2001 um ponto relevante para a condu o efe
22. cada fase de desenvolvimento s o definidas e documentadas 117 h um plano para a execu o de verifica es dos produtos de cada fase de desenvolvimento 118 05 resultados das verifica es s o registrados 119 para o desenvolvimento do projeto preparado um plano da qualidade espec fico 120 0 plano da qualidade contempla objetivos da qualidade expressos em termos mensur veis 121 existem crit rios de entrada e sa da para cada fase de desenvolvimento 122 a identifica o dos tipos de teste bem como atividades de verifica o e valida o a serem desempenhadas 123 existem planejamento detalhado de teste atividades de verifica o e valida o a serem realizadas definindo cronograma recursos e autoridade de aprova o 124 existem responsabilidades para revis es e testes ger ncia de configura o controle de mudan a controle de defeitos e a o corretiva 125 05 documentos de planejamento descrevem a evolu o do relacionamento com o cliente 126 0s operadores recebem treinamento em rela o aos m todos e normas de trabalho 127 no treinamento o exemplo apresenta as principais fun es do produto 128 0 restante do exemplo coerente com o que j foi aprendido 129 0 exemplo coerente com os padr es 130 0 exemplo introduz nova terminologia essa terminologia definida antes do exemplo ela necess ria 131 0 aluno conseguiria reproduzir o exemplo com o conhecimento autal ou o exemplo requer
23. checklist foi criado a partir das informa es encontradas em Mills 1994 Staa 2000 Freedman 1993 Menezes 2001 Rocha 2001 P dua 2001 Longworth 1985 Fernandes 1995 Gil 1989 Anacleto 1996 e Junior 2000 Na tabela 2 s o demonstradas as quantidades de perguntas criadas em cada atividade Est o cadastradas no sistema para apoio ao processo de verifica o 1160 perguntas para o checklist das atividades No anexo s o demonstradas algumas delas A cria o do checklist foi elaborado na busca das perguntas que descrevessem sobre o processo de verifica o das atividades da norma ISO IEC 12207 onde algumas perguntas foram novamente elaboradas para seguir apenas um tipo de resposta e outras foram exclu das pois existiam semelhan a entre elas Teve se tamb m a necessidade de verificar a onde cada uma das perguntas se encaixariam do processo de verifica o das atividades da norma TABELA 2 QUANTIDADE DE PERGUNTAS ATIVIDADE QUANTIDADE Contrato 7 Processo 157 Requisitos 174 Projeto 165 C digo 328 Integra o 196 Documenta o 140 FIGURA 11 TELA DE CADASTRO DAS PERGUNTAS DO CONTRATO Cadastro De Perguntas Do Contrato Codigo Pergunta 7 Pergunta s o empregados m todos de estimativas de custo prazos e recursos 4 Na figura 12 para iniciar o registro do Plano de Verifica o obrigatoriamente todos os outros cadastros
24. com a representa o do mesmo conceito no mesmo ou em outro diagrama de projeto existe alguma informa o no artefato de software que amb gua isto poss vel ao desenvolvedor interpretar as informa es de diferentes maneiras podendo n o levar a uma implementa o correta existe algum requisito que tenha v rias interpreta es devido a diferentes termos utilizados para uma mesma caracter stica ou v rios significados de um termo para um contexto em particular as representa o dos conceitos no projeto est clara e n o causam m interpreta o ou entendimento errado do seu significado por parte do usu rio do documento as informa es dos requisito que s o fornecidas s o necess rias e s o mesmo usadas resultados da codifica o produzem o c digo de cada programa e geram as tabelas de dados utilizados pelos programas por exemplo tabelas de mensagens s o produzido as defini es dos recursos utilizados pelo programa por exemplo di logos menus cones s o produzidos os textos de aux lio help 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 67 s o produzidos os tutoriais s o realizados teste de unidade em rela o de faltas e defici ncias encontradas do ponto de vista das especifica es s o realizados teste de unidade em rela o de faltas e defici ncias encontradas do ponto de vista dos padr es de
25. contrato Entretanto o adquirente dever tomar a decis o final sobre essa adapta o bem como incluir ou referir a norma adaptada no contrato Esse contrato deve ser preparado e negociado com o fornecedor e deve tratar dos requisitos de aquisi o e incluir custos e cronograma bem como os direitos de uso propriedade autoria garantia e licen a associados com os produtos de software de prateleira que ser o utilizados Quando o contrato estiver em andamento o adquirente tamb m deve controlar poss veis altera es no mesmo por meio de negocia o com o fornecedor Essas altera es 10 devem ser investigadas quanto ao impacto nos planos nos custos nos benef cios na qualidade e no cronograma do projeto De acordo com Mills 1994 avalia o do fornecedor uma t cnica usada por v rios grandes compradores para avaliar a capacidade de um fornecedor potencial de fornecer um determinado produto servi o ou processo Uma avalia o de fornecedor normalmente cobre todos os aspectos do fornecedor potencial incluindo fatores como estabilidade financeira capacidade de projeto capacidade de manufatura sistema da qualidade etc As t cnicas de verifica o podem ser teis na avalia o de todos esses aspectos Uma vez firmado o contrato as avalia es podem ser realizadas para confirmar a observ ncia do sistema da qualidade estabelecido A verifica o do fornecedor a verifica o ou observa o de determinada
26. corretivas para cada item de software que sofre manuten o h o registro das a es corretivas para cada item de software que sofre manuten o s o mantidos dados estat sticos sobre a ocorr ncia de falhas e atividades de manuten o os registros das atividades de manuten o s o utilizados para a melhoria do produto de software e do pr prio sistema da qualidade h procedimentos documentados para incorporar mudan as no produto de software numa abordagem de release estes procedimentos incluem regras para determinar onde novas implementa es ser o realizadas ou incorporadas no produto estes procedimentos incluem regras para determinar m todos pelos quais o cliente ser comunicado sobre mudan a planejadas no produto estes procedimentos incluem regras para determinar m todos para confirmar que as mudan as a serem implementadas n o introduzir o outros problemas 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 91 existem registros indicando quais mudan as foram implementadas por instala o para m ltiplos produtos h um sistema de ger ncia de configura o este sistema identifica unicamente as vers es de cada item de software o sistema identifica as vers es de cada item de software que juntos constituem uma vers o espec fica de um produto completo o sistema identifica o status de constru o do produto de software e
27. da qualidade relat rios de assist ncia t cnica e reclama es do cliente para detectar e eliminar causas potenciais de servi os aplicado a es preventivas para tratar dos problemas em um n vel correspondentes aos riscos encontrados s o executados controles para assegurar que as a es corretivas s o realizadas e que as mesmas s o efetivas ao implementar e registrar altera es nos procedimentos resultantes de a es corretivas 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 65 h utiliza o de m tricas para a medi o da qualidade do produto as m tricas relativas ao produto s o coletadas em intervalos regulares s o identificados os n veis de desempenho com as m tricas com os resultados das medi es e quanto h indica o h tomada de a o corretiva s o estabelecidas metas de melhoria em fun o das medi es h m tricas para a medi o da qualidade do processo de desenvolvimento de software software produto incluso h procedimentos para a valida o armazenamento prote o e manuten o de produto de software do cliente ou de terceiros s o feitas testes de unidade em rela o de faltas e defici ncias encontradas do ponto de vista das especifica es h alguma rela o de faltas e defici ncias encontradas do ponto de vista dos padr es de programa
28. de serem detectados corrigidos quando detectados e requerem modifica es muito mais caras 6 extensas 2 3 5 VERIFICA O DO C DIGO Segundo Rocha 2001 verifica o do c digo observa se o c digo est de acordo com os requisitos se test vel e correto se est de acordo com os requisitos e padr es de codifica o se implementa requisitos cr ticos e de seguran a com m todos rigorosos Conforme Rocha 2001 o desenvolvedor deve codificar e documentar cada unidade de software e definir a base de dados usando t cnicas e implementa o que produzam um c digo eficiente e livre de erros Como resultado de uma implementa o bem sucedida as unidades de software devem ser obtidas e crit rios de verifica o devem ser definidos para todas elas A atividade de teste combina v rias etapas com uma s ria de m todos de projeto de casos de teste que ajudaram a garantir que erros sejam efetivamente detectados Segundo Staa 2000 cada padr o estabelece regras que s o de aplica es obrigat ria exce es que estabelecem alternativas para regras e recomenda es que devem ser seguidos na medida do poss vel Os padr es podem ser adaptados a cada organiza o desde que o seu 14 esp rito seja mantido Ou seja organiza es que j possuem padr es podem ajustar os seus padr es e os aqui apresentados de modo a minimizar o impacto na organiza o J organiza es que n o possuam um programa de qualidade esta
29. de implementa o representado pelo chamado de implementa o O m todo para a especifica o do software utilizada foi a t cnica de an lise essencial 4 2 LISTA DE EVENTOS Segundo Pompilho 1994 um evento pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema uma resposta A rigor o valor de um sistema est na sua capacidade de responder com efic cia a todos os est mulos a que for submetido Assim um sistema constru do para responder a est mulos A cada est mulo o sistema deve reagir produzindo uma resposta predeterminada Com isso o software proposto possui a seguinte lista de eventos l avaliador cadastra organiza o neste evento o avaliador respons vel ou quem estiver operando o software dever realizar o cadastramento da organiza o que ser avaliada 30 2 avaliador cadastrado o cadastro do avaliador tem por objetivo manter o nome da pessoa respons vel pela verifica o do software 3 momento de efetuar pergunta neste processo o avaliador do sistema ir proceder a avalia o da organiza o relacionada a cada atividade espec fica anteriormente cadastrada 4 avaliador registra plano de verifica o neste cadastro poss vel a inclus o do software a ser verificado e neste processo o avaliador ir proceder tamb m o cadastramento do plano de verifica o 5 momento de selecionar pergunta neste processo as perg
30. gerado as tabelas de dados utilizados pelos programas por exemplo tabelas de mensagens 233 produzido as defini es dos recursos utilizados pelo programa por exemplo di logos menus cones 234 produzido os textos de aux lio help 235 produzido os tutoriais 236 as regras e recomenda es de escolha de nomes t m por objetivo tornar f cil 237 escolhido bons nomes novos ao criar ou manter programas 238 f cil de localizar a especifica o e a declara o completa do nome 239 1embrar se corretamente dos nomes dos elementos j declarados ao redigir ou alterar c digo 240 entender corretamente um trecho de c digo sendo lido sem precisar recorrer documenta o na grande maioria das vezes 241 assegurar que os elementos do programa possuam tipos consistentes como contexto em que est o sendo utilizados 242 argumentar a corretude de trechos de programas 243 acompanhar corretamente o comportamento do programa ao utilizar ferramentas de apoio depura o 244 existe uso de vari veis n o definidas ou n o inicializadas 245 todas as vari veis foram declaradas explicitamente 246 existem vari veis de tipos inconsistentes de dados e equa es programadas incorretamente 247 existe uso incorreto de operadores semelhantes 248 h n mero incorreto e ordem de par metros em uma chamada de sub rotina 249 0 programa executa testes de consist ncia devidos na entrada 85 250 nomes de dados e r
31. h procedimentos para identificar documentar revisar e autorizar qualquer mudan a aos itens de software sob a ger ncia da configura o 102 todas as mudan as nos itens de software seguem estes procedimentos 103 h m todos para notificar as mudan as s partes interessadas e para mostrar a rastreabilidade entre mudan as e partes modificadas dos itens de software 92 104 h procedimentos para registrar gerenciar e relatar sobre o status dos itens de software sobre solicita o de mudan as 105 para registros das qualidades h procedimentos para identifica o coleta indexa o arquivamento armazenamento manuten o e disposi o de registro da qualidade 106 h procedimentos para determinar per odo de tempo em que os registros devem ser retidos 107 existe uma rela o das fun es que dever o ser desempenhadas pelo sistema de computador 108 existe algum modelo da interface entre usu rio e o sistema de computador 109 tal modelo prev uma descri o das linguagens dispon veis ao usu rio 110 h quantidades de detalhes suficientes para que voc consiga assimilar o uso do sistema em sua pr pria mesa de trabalho 111 existe informa es sobre flexibilidade adaptabilidade extensibilidade da interface de usu rio 112 existe informa es pra o usu rio sobre tutoriais assist ncia etc 113 h uma descri o das fun es dispon veis ao usu rio e do acesso a essas fun es 114 h uma a
32. informa o entre grupos documentada transmitida e periodicamente revista 135 0 programa suficientemente documentado 136 0 vendedor proporciona manuten o 137 h uma qualidade da documenta o dos procedimentos manuais do usu rio 138 h um sistema da qualidade documentado considerando todo o ciclo de vida assegurando que a qualidade seja verificada durante o processo 139 0 sistema da qualidade documentados est efetivamente implementado 140 0s elementos e requisitos do sistema da qualidade est o claramente documentados numa estrutura l gica coerente 141 para cada projeto de software existe um plano da qualidade baseado no sistema da qualidade 142 este plano da qualidade entendida e observado pelas pessoas 6 reas da organiza o envolvidas com o projeto
33. intemas foram assinadas e recebidas Page 1 of 1 h No menu Relat rios pode se ainda visualizar ou emitir uma rela o de perguntas por tipo de resposta isto perguntas que satisfazem as exig ncias dos padr es versus aquelas que n o satisfazem Conforme figura 18 nestes relat rios o cliente poder ter uma rela o de todas as perguntas por grau de atendimento 47 FIGURA 18 RELAT RIO DAS RESPOSTAS ATENDIDAS DO CONTRATO Relatorio por tipo de resposta de contrato Iof x DEBM D mel Relatorio das resposta atendidas do contrato Nome Organiza o Empresa de Vendas de Produtos 5 4 Nome Avaliador Itabora Cordoni Ebertz Data In cio Plano 15 11 2002 Hora In cio Plano 08 00 00 Data Termino Plano 15 11 2002 Hora termino Plano 08 00 00 Descri o do software Sistema de Controles de Vendas 5 4 Resposta Pergunta Atende h cortrole quantitativo est tico da qualidade do sotware Atende o bmecedor tem a capacidade de atender os requisitos Atende o m todo de embalagem controlado pelo bmecedor Atende os requisitos est o consistentes e cobrem as necessidades do usu rio Atende s o empregadas t cricas de inspe o eteste de sistemas Aende s o empregadas t cnicas de Inspe o e teste de sistemas Atende a empresa opera com procedimentos formalizados Atende quanto aos contratos o escopo do contrato e os requerimentos s o definidos e documentados Atende se
34. ncia cruzada 294 possui um mapa das reas est ticas 295 tendo se mais de uma listagem do programa existe uma nota da finalidade espec fica cada listagem 296 as corre es s o datadas 297 as corre es s o claramente indicadas 298 as corre es referem se especifica o 299 a especifica o de programa possui formato padr o 300 cont m documentos padr es 301 existe um esquema de alto n vel 302 descreve as interfaces do sistema 303 cont m explica o para trabalho espec fico 304 layouts de arquivos e descri o de registro est o em documentos padr es 305 0s layouts est o inclu dos ou referenciados 306 usa se de modo perfeito as reas de armazenamento 307 0s nomes padr es s o usados para determinar reas 308 est o atualizados 309 esquema de programa existe um esquema global 310 5 s mbolos padr es s o usados 311 est dentro de um formato padr o 312 est atualizada e uma representa o real do programa 313 05 identificadores de componentes s o utilizados no programa 314 atinge um n vel de detalhes satisfat rio 315 existe um esquema para componente 316 existe uma l gica esquem tica 317 instru es operacionais est o em documentos padr es 318 existe um esquema operacional 319 existem descri es de mensagem e a es para c digos de erro 320 as instru es operacionais est o presentes 321 est o atualizadas 322 de f cil entendimento
35. nome da organiza o e do avaliador logo abaixo ser o enviadas as perguntas selecionadas para fazer a verifica o basta clicar em uma das op es de resposta Atende N o Atende ou Desconhece N o Sabe Para seguir o checklist basta clicar no bot o pr ximo 45 FIGURA 16 TELA DA VERIFICA O DO CONTRATO Verifica o Do Contrato Organiza o Empresa de Vendas de Produtos 5 Avaliador Itabora Cordoni Ebertz Pergunta fornecedor tem a capacidade de atender os requisitos Iniciar Checklist e C N o Atende Desconhece N o Sabe EE Finalizar Observa o Respost E Finalmente para as verifica es j efetuadas poder ser emitido um relat rio apresentando os resultados deste procedimento onde poder o ser verificadas as respostas fornecidas em cada avalia o Este relat rio permite efetuar uma rela o de todas as perguntas atendidas e suas respectivas respostas referente a uma determinada atividade verificadas Ser o mostrados tamb m o nome do avaliador datas da verifica o horas da verifica o descri o do software e nome da organiza o No menu Relat rios pode se visualizar ou emitir uma rela o de metas conclu das basta clicar na op o da atividade que voc queira realizar a impress o Conforme figura 17 nestes relat rios o cliente poder ter uma rela o de todas as perguntas selecionadas e suas respectivas respostas refere
36. o de contratos 11 2 3 2 VERIFICA O DO PROCESSO Segundo Rocha 2001 verifica o do processo observa se o planejamento do projeto e a atribui o de tempos est o adequados se o que foi determinado no projeto est sendo seguido e est de acordo com o contrato se a equipe possui o treinamento desejado Cabe ao fornecedor conduzir uma revis o dos requisitos de aquisi o como o objetivo de definir a estrutura e estabelecer os planos os quais ser o utilizados para gerenciar o projeto e garantir a qualidade do produto ou servi o de software que ser entregue No levantamento dos requisitos para os planos interessante que o fornecedor inclua as necessidades de recursos bem como o modelo de envolvimento do adquirente Um ponto importante a se considerar o modelo de ciclo de vida que ser usado Se n o estiver estipulado no contrato o fornecedor deve definir ou selecionar um modelo de ciclo de vida de software apropriado para abrang ncia o objetivo a magnitude e a complexidade do projeto Os processos as atividades e as tarefas relacionadas com a norma ISO IEC 12207 devem ser selecionados e mapeados nesse modelo de ciclo de vida adotado J para Staa 2000 reconhecido que um dos principais fatores para os problemas com projetos de desenvolvimento de software n o se situam na rea t cnica mas sim na ger ncia do processo A grosso modo a falta de coordena o acompanhamento e controle do desenvolviment
37. o est o completos existe pol tica escrita divulgada e documentada requerendo que o padr o do processo de desenvolvimento de software seja usado estabelecido um grupo de engenharia do processo de software revis es gerenciais peri dicas s o realizadas para verificar o status dos projetos internos de aperfei oamento do processo de software o grupo de engenharia do processo de software lidera as atividades de aperfei oamento do processo bem como assegura a conscientiza o sobre os m todos empregados mecanismos s o estabelecidos para identificar problemas sobre projeto de sistema e software e resolve los imediatamente 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 cursos padr es s o oferecidos sobre ger ncia da qualidade ger ncia de profissionais de software m todos de software e inspe es os recursos s o estimativos para cada atividade chave no processo de software conting ncias s o estabelecidas para todas estimativas conforme a experi ncia hist rica planos de ger ncia de risco dos projetos identificam termos t cnicos e de neg cio os quais possam afetar o sucesso do projeto o desempenho do projeto acompanhado e revisado por atividade chave no processo de software inspe es de projeto e c digo s o monitorados at a resolu o dos problemas que surjam o desenvolvimento e doc
38. para estabelecer contratos com fornecedores externos para aquisi o de seus produtos ou servi os Os resultados reais e desempenho do fornecedor contratado s o acompanhados com base nos compromissos assumidos no projeto do software s o empregados m todos de estimativas de custo prazos e recursos h controle de mudan a a metodologia de desenvolvimento est claramente estabelecida s o empregadas t cnicas de inspe o e teste de sistemas h controle quantitativo est tico da qualidade do software os projetos seguem os custos e prazos planejados seus novos fornecedores s o selecionados s o estabelecidos os termos e as condi es do contrato por exemplo planos de inspe o de produto ou contrato procedimentos dados de contrato outros o m todo de embalagem controlado pelo contrato por exemplo informa o do contrato plano contratual de garantia da qualidade plano de contrato de produ o outros o m todo de embalagem controlado pelo fornecedor o fornecedor disp em de procedimentos e instru es estabelecidos documentados e atualizados para verificar o projeto do produto em quest o para assegurar que os requisitos s o cumpridos assegurado que tudo o que foi prometido foi fornecido e foi devidamente aprovado 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 54 exist
39. produtividade s o produzidos para cada projeto o desempenho avaliado em fun o das melhorias no processo e produtividade a reutiliza o de componentes e suas defini es s o mantidas sob o controle da ger ncia da configura o de software melhorias de processo e produtividade dos subcontratados s o revistas aprovadas e monitoradas a rea de garantia da qualidade da empresa monitora as a es de melhoria de processo e de produtividade dos subcontratados padr es documentados s o produzidos para a medi o da produtividade de cada tarefa em termos de limites estat sticos guias documentados e padr es s o produzidos para a reutiliza o de componentes incluindo padr es de interfaces m todos documentados s o desenvolvidos para o projeto de componentes reutiliz veis an lise de preven o de defeitos e extin o de defeitos estudos econ micos e t cnicos s o conduzidos durante o projeto para decidir quando componentes reutiliz veis devem ser empregados medi es e an lises s o realizadas sobre efic cia de ferramentas m todos de prototipa o da reutiliza o an lise de causas de defeitos s o conduzidos existe um mecanismo formal para gerenciar a introdu o de novas tecnologias utilizado um mecanismo para identificar e substituir as tecnologias absoletas mecanismos e responsabilidade s o definidas para acompanhamento de produtividade integra o de tecnologia
40. representa o por est gios O n vel de maturidade dos processos onde a rea de verifica o esta relacionada o definido O prop sito da verifica o assegurar que os produtos de trabalho selecionados satisfazem aos seus requisitos especificados O processo de verifica o n vel 3 descrevem os passos para assegurar que as atividades est o sendo executadas de acordo como o processo estabelecido O prop sito da verifica o assegurar que os produtos de trabalho selecionados satisfazem aos seus requisitos espec ficos As metas especificas para alcan ar ou implementar esta rea chave s o as seguintes preparar para a verifica o a prepara o para a verifica o conduzida executar as revis es por parceiros revis es por parceiros s o executadas nos produtos de trabalho selecionados 24 verificar os produtos de trabalho selecionados os produtos de trabalho selecionados s o verificados com rela o aos seus requisitos especificados A verifica o tamb m pode ser encontrado em outros n veis do modelo CMMI na integra o de produto ger ncia de requisitos planejamento de projeto controle de monitoramento de projeto ger ncia de contrato an lise casual e resolu o O prop sito da integra o de produto n vel 3 montar o produto dos componentes de produto assegurar que o produto como integrado funcione corretamente e entregar o produto As metas espec ficas para alc
41. requerido 148 necessita se de pr requisitos 149 as despesas quanto o treinamento s o em separado 150 no treinamento o fornecedor estabelece e mant m procedimentos para identificar as necessidades de treinamento e prover o treinamento para todo o pessoal que desempenha atividades que afetam a qualidade 151 0 fornecedor deve mant m registros apropriados sobre a realiza o de treinamento 152 as revis es gerenciais peri dicas s o realizadas para tratar sobre treinamento inser o de tecnologia status do processo de software e planos de aperfei oamento do processo 153 um plano de treinamento produzido definindo os recursos requerimentos para cada fun o no ambiente de desenvolvimento 154 0 pessoal requerido e requisitos de treinamento 155 h procedimentos para identificar as necessidades de treinamento do pessoal envolvido com atividades que afetam a qualidade 63 156 s o mantidos registros sobre as atividades de treinamento 157 5 procedimentos exigem adequadamente a designa o de pessoal qualificado apoiado pelos recursos 10 11 12 13 14 15 16 necess rios VERIFICA O DOS REQUISITOS os requisitos do sistema s o consistentes vi veis e test veis os requisitos do sistema foram distribu dos apropriadamente para os itens de hardware itens de software e opera es manuais de acordo com os crit rios do projeto os requisitos de software s o consistentes v
42. requisitos um documento de Especifica o de Requisitos de Software Os requisitos de alta qualidade s o claros completos sem ambigiiidade implement veis consistentes e test veis Os requisitos que n o apresentam estas qualidades s o problem ticos eles devem ser revistos e renegociados com os clientes e usu rios A revis o dos requisitos tem por objetivo assegurar que a especifica o dos requisitos do Software 13 esteja conforme com o respectivo padr o e com outros padr es aplic veis ao projeto em quest o atenda aos crit rios de qualidade dos requisitos e forne a informa o suficiente para o desenho do produto de seus testes de aceita o e do seu manual de usu rio 2 3 4 VERIFICA O DO PROJETO Segundo Rocha 2001 verifica o do projeto observa se o projeto est correto e coerente com os requisitos se ele implementa apropriadamente as seq ncias de eventos entradas sa das requisitos de seguran a com m todos rigorosos Em Freedman 1993 o local onde a maioria dos erros se encontram depende do estado da arte da instala o Onde n o s o praticadas revis es de esp cie alguma nem mesmo as revis es informais de c digo dentro da pr pria equipe de programa o a maioria dos erros encontrada no n vel do c digo Entretanto os erros de projetos podem mostrar se em m dia mais s rios do que os erros de c digo Os erros de projeto s o na m dia mais dif ceis
43. rios revisados comparados com o plano as atividades de revis o e produtos intermedi rios s o submetidos a auditoriais e revis es da Garantia da Qualidade de software por exemplo revis es planejadas s o conduzidas e a es posteriores s o acompanhadas medidas s o usadas para determinar o estado das atividades de preven o de defeitos por exemplo o tempo e custo para identificar e corrigir defeitos e a quantidade de a es propostas e completadas quando os requisitos definidos para o software mudam s o feitos ajustes nos planos produtos de software e atividades relacionadas voc faz revis es peri dicas dos planos e registros de teste submetendo os aprova o de outros profissionais 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 64 os dados de revis o de projetos s o analisados para avaliar o produto e reduzir defeitos futuros as principais fun es s o logo demonstradas o plano de testes consistente com o plano de projeto global um cronograma de teste foi explicitamente definido os recursos e ferramentas de teste foram identificados e es disposi o um mecanismo de manuten o de registros de teste foi estabelecido a organiza o utiliza se de um plano definido para conduzir a verifica o dos componentes em rela o aos seus requisitos especificados a organiza o prov um proce
44. sabe que a malha dever ser executada um n mero espec fico de vezes 213 usado um formato padronizado e facilmente reconhec vel para malhas eternas 214 a condi o de sa da da malha facilmente identific vel 215 evitado malhas vazias 84 216 0 uso de efeitos colaterais dentro do teste de termina o das malhas evitado ou pelo menos documentado com destaque 217 cada malha executa apenas uma fun o 218 gotos s s o usados em casos extremos em que o c digo ficara mais ileg vel sem o goto do que com ele 219 s usado o return para melhorar a legibilidade 220 56 usado a recurs o quando puder provar que ela tem limite 221 simplificada as express es de teste usadas para controle 222 s o organizados os testes num ricos na dire o dos pontos de uma reta 223 minimizado os n veis de aninhamento 224 h pelo menos um espa o de cada lado de um operador bin rio 225 s mbolos parent ticos tem um espa o depois do s mbolo de abertura e antes do s mbolo de fechamento 226 h pelo menos uma linha em branco deve separar um coment rio do c digo precedente 227 linhas de c digo excedem 80 caracteres 228 se es mais importantes de programa s o precedidas por um coment rio de bloco 229 todos os coment rios est o sempre atualizados 230 todo c digo n o definido s o marcado atrav s de um tipo de coment rio padronizado 231 produzir o c digo de cada programa 232
45. tabelas 139 utiliza o perfeita dos recursos de hardware 140 0 tamanho do programa est relacionado com a m quina e o sistema operacional 141 0 programa mant m uma interface satisfat ria com o sistema 142 0s dados s o manipulados no formato mais adequado 143 0 uso de comandos considerados lentos quanto opera o restrito 144 em n vel de ambiente operacional a comunica o com os operadores mantida em um m nimo 145 a comunica o com os operadores significativa e til 146 h um procedimento padr o para rein cio 147 0 programa f cil de ser operado 148 0 programa f cil de ser preparado 94 149 todas as fun es necess rias est o dispon vel 150 as necessidades futuras do usu rio podem ser implementadas pelo fornecedor ou pelo usu rio 151 vai rodar dentro das restri es impostas pelo hardware agora dispon vel 152 56 outro equipamento for necess rio qual ser o custo e a disponibilidade 153 pode ser convertido para rodar no hardware atual 154 ser f cil mudar o sistema para outros perif ricos no mesmo computador 155 pode o sistema operacional ser mudado 156 0 sistema pode ser rodado em outro computador 157 pode ser rodado em mais de um computador sem alterar o custo no mesmo local ou em outro 158 as despesas quanto documenta o s o separadas 159 existe despesa quanto o suporte ou s atualiza es 160 outros usu rios encontram se satisfeitos 161 outros
46. todos b sicos de projeto codifica o e teste de software est o definidos e documentados dados hist ricos s o retirados sobre o c digo erros de teste etc 20 21 22 23 24 25 26 27 28 20 30 31 32 33 34 35 36 37 38 39 40 41 97 mecanismos e responsabilidades s o estabelecidos para assegurar que os planos sejam produzidos e acompanhados para todos os projetos os planos s o aprovados pelas equipes de implementa o todos os planos s o revistos antes de haver comprometimento efetivo auditorias s o conduzidas quando especificadas controle de mudan a rigorosamente implementado e a garantia da qualidade e ger ncia de configura o de software s o efetivamente desempenhadas procedimentos m todos e responsabilidades s o estabelecidas par assegurar que os desenvolvedores entendam tanto os requerimentos como o ambiente dos usu rios da aplica o meios s o estabelecidos para prover o ambiente de desenvolvimento com o conhecimento sobre ferramentas e m todos dispon veis todos os itens s o cobertos por algum tipo de documenta o as atividades de produ o e verifica o s o documentadas a documenta o t cnica e de uso aux lios manuais tutoriais existem est completa e consistente como o que se encontre implementado a documenta o de uso est na vers o definitiva e correspondente exatamente ao sistema im
47. 177 procedimentos s o aplicados a fim de assegurar para cada vers o do software as especifica es funcionais e t cnicas todas as ferramentas de desenvolvimentos que afetam estas especifica es todas as interfaces com outros itens de software e hardware e todos os documentos e arquivos de computador relacionados ao item de software 178 0 fornecedor estabelece e mantem procedimentos para identificar documentar revisar e autorizar quaisquer mudan a no software sob controle da ger ncia de configura o 179 qualquer equipamento pode ser usado para processar o sistema 180 dispositivos de entrada sa da preciso serem requeridos 181 qualquer tipo de meio e organiza o de arquivos podem ser processados 182 h restri es especificas 183 0s procedimentos fornecem instala es de armazenagem que evitam danos ou degrada o do produto exemplo instala o para armazenagem prateleiras caixas 184 30 transferir os programas da plataforma de desenvolvimento para a plataforma de uso a base de dados de uso est completa e corretamente povoada 185 0s usu rios saibam utilizar completa e corretamente o sistema 186 0 sistema de instala o est operando corretamente 187 0 sistema atende efetivamente s necessidades do usu rio 188 0 sistema est em conformidade com as suas especifica es 189 0 usu rio consegue utilizar o sistema sem requerer assist ncia continuada 190 0 sistema opera em todas a plataformas e respec
48. 1993 GIL Antonio de Loureiro Auditoria de computadores S o Paulo Atlas 1989 IAHN An sio Avalia o de processos de software utilizando a norma ISO IEC 15504 1999 43 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau INTHURN C ndida Qualidade amp teste de software Florian polis Visual Books 2001 JUNCKES A Fabio Software de apoio ao processo de auditoria segundo normas de qualidade 1999 66 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau JUNIOR Uno T An lise de uma organiza o de software utilizando o modelo CMMI SEI V 1 0 2000 92 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau KRAUSE Conrad An lise de uma metodologia de desenvolvimento de sistemas baseada na norma ISO IEC 12207 1998 47 f Trabalho de Conclus o de Curso Bacharelado em 52 Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau LONGWORTH G Padr es em programa o m todos e procedimentos Rio de Janeiro Campus 1985 MENEZES Lu s C sar de Moura Gest o de projetos S o Paulo Atlas 2001 MILLS A Charles A auditoria
49. 2 PROCESSO DE VERIFICA O SEGUNDO A NORMA ISO IEC 15504 17 3 3 NORMA ISO 9000 3 ASA OR 18 3 4 PROCESSO DE VERIFICA O SEGUNDO A NORMA ISO 9000 3 19 SS MODELO CMMI 1 a 22 3 6 PROCESSO DE VERIFICA O SEGUNDO O MODELO 23 3 7 QUADRO COMPARATIVO cedo podiam Heda fitas Beda eagle 25 4 ESPECIFICA O DO PROT TIPO setas as DC Dq 29 4 1 REQUISITOS 29 42 LISTA DE EVENTOS sossego 29 4 3 DIAGRAMA DE US perda 30 4 4 DIAGRAMA 31 4 5 DIAGRAMA DE FLUXO DE 34 4 6 DICION RIO DE DADOS sas iai aan Ga ciais dia cialis 35 5 IMPLEMENTA O DO PROT TIPO eee 38 5 1 OPERACIONALIDADE DA 38 O CONCLUS ES sais arcar notas a e a aa ea 48 REFER NCIAS BIBLIOGR FICAS eee eee eee meets 50 ANEXO O IAO E RI quis A dA a Di fa ea GA pa DR a Dida 53 vi LISTA DE FIGURAS E TABELAS FIGURA 1 ROTEIRO DE VERIFICA O DE 8 7 FIGURA 2 DIAGRAMA DE CONTEXTO
50. 4 Cada vez mais as empresas investem na diferencia o de seu produto no mercado Isto faz com que o termo qualidade seja usado diariamente tanto em propagandas quanto em conversas informais Por este motivo a qualidade definida como a totalidade de requisitos e caracter sticas de um produto ou servi o que estabelecem a sua capacidade de satisfazer necessidades impl citas e expl citas Bizzoto 1992 A qualidade de software determinada pela qualidade dos processos utilizados para o desenvolvimento Deste modo a melhoria da qualidade de software obtida pela melhoria da qualidade dos processos Esta vis o orienta a elabora o de modelos de defini o avalia o e melhoria de processos de software Iahn 1999 Segundo Junckes 1999 a comunidade de inform tica vem criando normas e modelos de qualidade como ISO IEC 12207 ISO 9000 3 CMMI e ISO IEC 15504 para regular e orientar a atividade de produ o de software A norma ISO IEC 12207 Processos de Ciclo de Vida de Software tem por objetivo principal estabelecer uma estrutura comum para os processos de ciclo de vida do software A norma ISO 9000 3 aborda basicamente situa es em que um software espec fico desenvolvido como parte de um contrato atendendo as especifica es do comprador O Modelo de Capacidade e Maturidade de Software Integrado CMMD uma estrutura que descreve os elementos de um processo eficiente de software e um caminho evolucion rio que aumenta
51. 995 a verifica o refere se ao conjunto de atividades que garante que o software implemente corretamente uma fun o espec fica importante notar que a verifica o abrange um conjunto amplo de atividades de que incluem revis es t cnicas formais auditorias de configura o e qualidade monitora o do desempenho simula o estudo da viabilidade revis o da documenta o revis o de bancos de dados an lise de algoritmos teste de desenvolvimento teste de qualifica o e teste de instala o N o obstante a atividade de teste desempenhe um papel extremamente importante na verifica o muitas outras atividades tamb m s o necess rias Uma defini o simples e ao mesmo tempo completa emitida por Inthurn 2001 verifica o refere se ao conjunto de atividades que garante que o software implementa corretamente uma fun o espec fica Na verifica o deve se utilizar a seguinte pergunta Estamos construindo certo o produto As verifica es podem ser aplicadas no in cio e ao longo de todo o ciclo de vida do processo de desenvolvimento A valida o refere se ao conjunto de atividades que garante o software que foi constru do rastre vel s exig ncias do cliente Na valida o deve se utilizar a seguinte pergunta Estamos construindo o produto certo Assim cabe ressaltar que verifica o e valida o de software s o conceitos diferentes onde os de verifica o podem ser aplicado no in cio e ao lo
52. Es software Avaliador Sele o Resposta Pergunta Avaliador 4 4 DIAGRAMA ENTIDADE RELACIONAMENTO z O Diagrama Entidade Relacionamento um diagrama utilizado para detalhar as associa es existentes entre as entidades de dados do sistema Todas as entidades do software como j mencionado se originaram de um estudo particular realizado com base nas normas utilizadas Para um melhor entendimento da representa o dos modelos l gico e f sico de dados das figuras 3 e 4 uma breve descri o de cada entidade apresentada a organiza o esta entidade respons vel por armazenar as organiza es cadastradas no sistema b avaliador esta entidade respons vel por armazenar os avaliadores cadastrados no sistema z c plano de verifica o esta entidade respons vel por armazenar o plano de verifica o das atividades cadastradas no sistema 32 d pergunta esta entidade respons vel por armazenar as perguntas propostas para avalia o cadastradas no sistema relacionada a cada atividade espec fica z e sele o nesta entidade selecionada a pergunta da atividade para realizar a verifica o do checklist A figura 3 apresenta este diagrama no n vel l gico e em seguida na figura 4 a n vel f sico FIGURA 3 DIAGRAMA DE ENTIDADE RELACIONAMENTO N VEL L GICO Organiza o Codigo organiza o Avaliador Nome oraganiza
53. NIZA O sf Cadastro Da Organiza o Iof x Codigo o 1 Nome Empresa de Vendas de Produtos SA Endereco Rua 7 de setembro 95 756 Bairro Cidade ilmena ur fec Cep 89010 001 78024617000145 Fone 047 328 1162 f Incluir 5 Salvar t4 Excluir amp Finalizar A figura 10 demonstra a tela de Cadastro do Avaliador que cadastra os dados pessoais Este avaliador ser utilizado posteriormente no registro do Plano de Verifica o FIGURA 10 TELA DE CADASTRO DO AVALIADOR a Cadastro Do Avaliador Mm El Codigo a Nome itabora CordoniEbertz 0 Area Garantia da Qualidade 00 Cargo Consultor de Software Fone 047 333 1505 Email fita inf furb br f Incluir 5 Salvar Excluir Cancelar Na figura 11 apresentada a tela que permite o cadastramento das perguntas do checklist que comp em todas as atividades do processo de verifica o da norma ISO IEC 12207 Para cada atividade dever o ser cadastradas as perguntas espec ficas Al m do Cadastro de Pergunta do Contrato mostrado na figura 11 ainda existem o cadastro de perguntas para processo requisitos projeto c digo integra o e documenta o Ap s o 40 avaliador entrar com a pergunta e clicar no bot o Incluir as perguntas ser o armazenadas em uma lista que possibilitar a exclus o altera o e verifica o das perguntas j cadastradas O
54. O CONTRATO 46 FIGURA 18 RELAT RIO DAS RESPOSTAS ATENDIDAS DO CONTRATO 47 TABELA 1 COMPARATIVO DO PROCESSO DE VERIFICA O DE SOFTWARE 26 TABELA 2 QUANTIDADE 40 vii RESUMO Este trabalho descreve conceitos de verifica o de software e apresenta um estudo comparativo entre o processo de verifica o de software existente nas normas de qualidade ISO IEC 12207 ISO 9000 3 ISO IEC 15504 SPICE e no modelo CMMI Prop e se um processo de verifica o de software baseado na norma ISO IEC 12207 bem como o desenvolvimento de um software para o apoio a este processo viii ABSTRACT This work describes concepts of software verification and presents a comparative study between existing software verification process in ISO IEC 12207 ISO 9000 3 and ISO IEC 15504 SPICE quality norms and the CMMI model It proposes software verification process based in ISO IEC 12207 as well as it developed software to the support this process 1 INTRODU O Nos dias atuais a melhoria da qualidade do software torna se um processo cada vez mais comum nas organiza es devido a necessidade de obten o de melhores resultados em todas as fases do ciclo de vida de software com o objetivo de obter esta melhoria da qualidade que surgiram normas e modelos como ISO IEC 12207 ISO 9000 3 CMMI e ISO IEC 1550
55. O PLANO VERIFICACAO CODIGO ORGANIZACAO CODIGO AVALIADOR DATA INICIO VERIFICACAO DATA TERMINO VERIFICACAO HORA INICIO VERIFICACAO HORA TERMINO VERIFICACAO DESCRICAO SOFTWARE STATUS CONTRATO STATUS PROCESSO STATUS REQUISITOS STATUS PROJETO STATUS CODIGO STATUS INTEGRACAO STATUS DOCUMENTACAO Longlnteger Longlinteger Longlinteger DateTime DateTime DateTime DateTime Text 50 YesNo YesNo YesNo YesNo YesNo YesNo YesNo CODIGO PLANO VERIFICACAO CODIGO PLANO VERIFICACAO CODIGO PERGUNTA SELECAO CODIGO PLANO VERIFICACAO OBSERVACAO RESPOSTA Longlnteger Text 50 Byte Longlnteger CODIGO PERGUNTA CODIGO PERGUNTA PERGUNTA CODIGO PERGUNTA DESCRICAO PERGUNTA TIPO Longlnteger Text 300 Byte CODIGO AVALIADOR CODIGO AVALIADOR 34 4 5 DIAGRAMA DE FLUXO DE DADOS O objetivo do Diagrama de Fluxo de Dados mostrar um sistema completo ou parte dele de onde os dados surgem para onde v o quando s o armazenados que processos os transformam e as intera es entre armazenamento de dados e processos Nas figuras 5 e 6 s o apresentados os diagramas de fluxo de dados para cada evento conforme descrito no item 4 2 Lista de Eventos FIGURA 5 DIAGRAMA DE FLUXO DE DADOS DE 1 A 5 Rd Organiza o Organiza o Cadastrar Organiza o 1 Organiza o
56. Organiza o ok 2 F Pa 2 Y Avaliador Cadastrar Avaliador ok Avaliador gt Avaliador gt i Ed A A A 3 Pergunta Cadastrar Pergutna ok Avaliador gt Pergunta gt gt Pergunta 1 d A A Ed 4 nm avaliador Plano de Verifica o Registrar Plano Avaliador 2 Organiza o gt gt de Verifica o Fa N A nm_organiza o Plano de Verifica o_ok Organiza o 2 Plano de Verifica o nm avaliador Sele o Selecionar lt Avaliador 3 Avaliador Pergunta Edi A oe ad nm organiza o ds pergunta Organiza o 3 Pergunta 2 FIGURA 6 DIAGRAMA DE FLUXO DE DADOS DE 6 A 9 35 F f 3 nm avaliador Resposta Registrar lt Avaliador Avaliador gt Resposta nm avaliador Nica Ps ds pergunta Organiza o Sele o 3 Gerar rela o das Rela o das perguntas selecionadas perguntas M Cliente lt selecionadas N r As X Ze p ia d ds respsota plano de verifica o Ea Ed ds perguntas N Plano de Verifica o 1 Sele o 1 pe 8 q A Rela o das perguntas por tipo de resposta Gerar rela o das Cliente E perguntas por tipo E deresposta Plano de Verifica o a i ds resposta di ds perguntas Plano de
57. Os trechos da tabela 1 foram retirados das suas respectivas normas e modelos e tamb m de algumas monografias que j faziam o comparativo das mesmas No texto aparece a refer ncia ao segmento da norma cl usula artigo se o etc 29 4 ESPECIFICA O DO PROT TIPO Este cap tulo trata da especifica o do software Ser o apresentadas a lista de eventos com uma breve descri o sobre cada evento o diagrama de entidade relacionamento tanto em n vel l gico como f sico o dicion rio de dados o diagrama de contexto e os diagramas de fluxos de dados 4 1 REQUISITOS DO PROBLEMA O software a seguir foi desenvolvido segundo a proposta de processo de verifica o demonstrada nos cap tulos anteriores Cabe lembrar que o objetivo do software proposto apoiar o processos de verifica o de software baseando se na norma ISO IEC 12207 Al m disso o comparativo feito entre as normas dar subsidio para ampliar o processo de verifica o Este software dever ser capaz de auxiliar o engenheiro de software no processo de verifica o Utilizou se para isto um checklist para facilitar o apoio ao processo de verifica o Segundo Pompilho 1994 a an lise essencial considera tr s perspectivas fun es dados e controles Em rela o ao grau de abstra o a an lise essencial considera dois n veis o n vel essencial e o n vel de implementa o O n vel essencial representado pelo chamado modelo essencial e o n vel
58. UNIVERSIDADE REGIONAL BLUMENAU CENTRO DE CI NCIAS EXATAS E NATURAIS CURSO DE CI NCIAS DA COMPUTA O Bacharelado PROT TIPO DE APOIO AO PROCESSO DE VERIFICA O BASEADO NA NORMA ISO IEC 12207 TRABALHO DE CONCLUS O DE CURSO SUBMETIDO UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTEN AO DOS CREDITOS NA DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CI NCIAS DA COMPUTA AO BACHARELADO ITABORA CORDONI EBERTZ BLUMENAU NOVEMBRO 2002 2002 2 33 SOFTWARE DE APOIO AO PROCESSO DE VERIFICA O BASEADO NA NORMA ISO IEC 12207 ITABORA CORDONI EBERTZ ESTE TRABALHO DE CONCLUS O DE CURSO FOI JULGADO ADEQUADO PARA OBTEN O DOS CREDITOS NA DISCIPLINA DE TRABALHO DE CONCLUSAO DE CURSO OBRIGATORIA PARA OBTEN O DO TITULO DE BACHAREL EM CI NCIAS DA COMPUTA O Prof Everaldo Artur Grahl Orientador na FURB Prof Jos Roque Voltolini da Silva Coordenador do TCC BANCA EXAMINADORA Prof Everaldo Artur Grahl Prof Marcel Hugo Prof Ricardo A Azambuja DEDICAT RIA Dedico este trabalho aos meus pais Valentin e Yara por toda ajuda incentivo compreens o e carinho que tiveram comigo durante mais esta etapa da minha vida iii AGRADECIMENTO Agrade o a Deus por ter me dado for as em mais um momento decisivo da minha vida Agrade o especialmente ao Professor Everaldo Artur Grahl por toda sua dedica o e orienta o durante a confec o deste trabalho Aos professores do curso que me rep
59. VALIADOR NOME AVALIADOR CARGO AVALIADOR TELEFONE AVALIADOR EMAIL AVALIDOR AREA ATUACAO AVALIDOR Byte Text 20 Longlnteger Text 50 Text 50 Text 20 Text 50 Text 50 FIGURA 7 DICION RIO DE DADOS CONTINUA O Plano de Verifica o Codigo plano verifica o Codigo organiza o Codigo avaliador Data inicio verifica o Data termino verifica o Hora inicio verifica o Hora termino verifica o Descri o software Status contrato Status processo Status requisitos Status projeto Status codigo Status integra o Status documenta o Pergunta CODIGO PLANO VERIFICACAO Longlinteger CODIGO ORGANIZACAO Longlnteger CODIGO AVALIADOR Longlnteger DATA INICIO VERIFICACAO DateTime DATA TERMINO VERIFICACAO DateTime HORA INICIO VERIFICACAO DateTime HORA TERMINO VERIFICACAO DateTime DESCRICAO SOFTWARE Text DO STATUS CONTRATO YesNo STATUS PROCESSO YesNo STATUS REQUISITOS YesNo STATUS PROJETO YesNo STATUS CODIGO YesNo STATUS INTEGRACAO YesNo STATUS DOCUMENTACAO YesNo 37 Oo o Nae code Te Codigo pergunta Descri o pergunta Sele o Codigo plano verifica o Observa o Resposta Codigo pergunta CODIGO PERGUNTA Longlnteger DESCRICAO PERGUNTA Text 300 TIPO CODIGO PLANO VERIFICACAO Longlnteger OBSERVACAO Text 50 RESPOSTA Byte CODIGO PERGUNTA Longlnteger Yes Yes No No 38 5 IMPLEMENTA O DO PROT TIPO Este software foi desen
60. Verifica o 2 Sele o 2 4 6 DICI ON RIO DE DADOS O Dicion rio de Dados do software foi gerado atrav s da Ferramenta CASE Power Designer que tem por objetivo fornecer suporte textual para complementar a informa o mostrada no Diagrama Entidade Relacionamento sendo considerado um grupo organizado de defini es de todos os elementos de dados do sistema A figura 7 apresenta este dicion rio de dados Para a documenta o do Dicion rio de Dados utilizado o seguinte formato a a coluna Name apresenta uma breve descri o do atributo 36 b a coluna Code apresenta o nome que identifica o atributo na tabela c a coluna Type apresenta o tipo do atributo d a coluna P identifica se o atributo chave prim ria da tabela e a coluna M identifica se obrigat rio o preenchimento do atributo FIGURA 7 DICION RIO DE DADOS Organiza o CODIGO ORGANIZACAO Longlnteger NOME ORAGANIZACAO Text 80 ENDERECO ORGANIZACAO Text 50 BAIRRO ORAGANIZACAO Text 50 CIDADE ORGANIZACAO Text 20 Codigo organiza o Nome oraganiza o Endere o organiza o Bairro oraganiza o Cidade organiza o UF organiza o Telefone organiza o CGC organiza o CEP organiza o Avaliador Codigo avaliador Nome avaliador Cargo avaliador Telefone avaliador Email avalidor Area atua o avalidor UF ORGANIZACAO TELEFONE ORGANIZACAO CGC ORGANIZACAO CEP ORGANIZACAO CODIGO A
61. a causar o mudan a dif ceis ou dispendiosas na documenta o existem condi es adequadas para distribui o das altera es na documenta o a documenta o pode ser reproduzida facilmente a c pia dos documentos pode ser evitada ou controlada existem pessoas dispon veis para suplementar a documenta o existem condi es adequadas para distribui o da documenta o os usu rios e os produtores concordam com os objetivos da documenta o existem condi es adequadas para manter pessoal de suporte informado e atualizado existem recursos dispon veis por exemplo microfich rios terminais para ler acessar armazenar esses materiais os documentos foram devidamente aprovados os documentos est o organizados adequadamente em rela o documenta o como um todo os documentos fazem refer ncia a outros documentos que podem ser usados como follow up o conte do da documenta o adequado todos os t picos essenciais est o completos os t picos irrelevantes foram eliminados os t picos completos est o no n vel de detalhe adequado o n vel t cnico apropriado ao n vel do documento o documento destinado existe algum erro no documento existe alguma contradi o a evid ncia adequada para sustentar a apresenta o a evid ncia realista existe uma declara o definida de metas da documenta o as metas s o consistentes a apresenta o da documenta o parece autorit
62. a os elementos de sistema externos a estrutura de dados consistente com o dom nio de informa o a estrutura de dados consistente cornos requisitos de software a manutenibilidade foi levada em considera o para o walhthrough de projeto o algoritmo executa a fun o desejada o algoritmo est logicamente correto a interface consistente com o projeto arquitetural a complexidade l gica razo vel o tratamento de erros e o antibugging foram especificados as estruturas de dados locais foram adequadamente definidas as constru es de programa o estruturadas s o usadas do princ pio ao fim os detalhes de projeto s o adequados linguagem de implementa o existem particularidades usadas de sistema operacional ou dependentes de linguagem usada uma l gica composta ou inversa a manutenibilidade foi levada em considera o o dom nio de informa o completo consistente e acurado a divis o do problema em parti es completa as interfaces externas e internas s o adequadamente definidas o modelo de dados reflete adequadamente os objetos de dados seus atributos e rela es todos os requisitos s o rastre veis em n vel de sistema a prototipa o foi levada a efeito pelo cliente usu rio o desempenho ating vel dentro das restri es impostas por outros elementos do sistema os requisitos t m consist ncia com os prazos os recursos e o or amento os crit rios de valida
63. ado de software da organiza o e seus respectivos recursos Esta rea envolve o desenvolvimento do processo de software para o projeto e o gerenciamento do projeto de software usando este processo O processo de software definido para o projeto uma vers o adaptada do processo padronizado de software da organiza o O projeto planejado e gerenciado de acordo com o processo de software definido para o projeto 15 2 3 7 VERIFICA O DA DOCUMENTA O Segundo a norma ABNT 1998 verifica o da documenta o observa se a documenta o est adequada completa coerente se est sendo desenvolvida no prazo e se o gerenciamento de configura o da documenta o dos documentos segue os procedimentos especificados Conforme Rocha 2001 a documenta o de software uma atividade fundamental no processo de desenvolvimento de software Cabe documenta o registrar a evolu o do software para que sejam criadas as bases necess rias para melhor utiliza o e manuten o do software Tradicionalmente pouca aten o tem sido dada documenta o gerada durante os projetos de desenvolvimento que tem resultado em documento mal elaborados de dif cil compreens o inadequados ou at mesmo incompletos Os maiores especialistas na rea de engenharia de software reconhecem que a falta de um projeto de documenta o tem atrapalhado a manuten o do software durante toda a hist ria da computa o A utiliza o do sof
64. an ar ou implementar esta rea chave s o as seguintes e preparar a integra o para o produto a estrat gia para conduzir a integra o do produto estabelecida e mantida e assegurar a compatibilidade de interface as interfaces componentes do produto tanto internas quanto externas s o compat veis e montar os componentes de produto e entregar o produto os componentes de produto verificados s o montados e o produto integrado verificado e validado entregue O prop sito da ger ncia de requisitos n vel 4 gerenciar os requisitos de produtos do projeto e componentes do produto e identificar inconsist ncias entre o planos de projeto e produtos de trabalho e os requisitos A meta espec fica para alcan ar ou implementar esta rea chave a seguinte gerenciar requisitos os requisitos s o gerenciados e inconsist ncias com planos de projeto e produtos de trabalho s o identificados O prop sito do planejamento de projeto n vel 4 estabelecer e manter planos que definam as atividades de projeto As metas especificas para alcan ar ou implementar esta rea chave s o as seguintes e estabelecer estimativas estimativas de par metros de planejamento de projeto s o estabelecidas e mantidas e desenvolver um plano de projeto um plano de projeto estabelecido e mantido como a base para gerenciar o projeto eobter compromisso para o plano compromissos para o plano de projeto s o estab
65. ar compreender implementar e manter uma pol tica de qualidade definir responsabilidade e autoridade para pessoas que gerenciam projetos verificar a qualidade do servi o identificar e providenciar recursos para a verifica o Com o grande crescimento de produ o de sistemas necess rio estabelecer um sistema de gest o de qualidade e fornecer orienta o para a garantia da qualidade de software Ela relata sobre as defini es de software produto de software item de software desenvolvimento fase verifica o de software e valida o para software Barbaresco 2000 20 O fornecedor deve elaborar as atividades de verifica o de cada fase A verifica o do desenvolvimento deve estabelecer que as sa das de cada fase atendam aos requisitos de entrada correspondentes mediante a ado o de medidas de controle de desenvolvimento tais como a an lise cr tica do desenvolvimento em pontos apropriados b compara o do novo projeto com um projeto semelhante j comprovado caso haja algum dispon vel c realiza o de ensaios e demonstra es Os resultados da verifica o e quaisquer a es suplementares requeridas para assegurar que os requisitos especificados foram atendidos devem ser registrados e verificados quando da conclus o destas a es Segundo Fernandes 1995 a norma ISO 9000 3 o fornecedor deve definir e documentar uma pol tica da qualidade A pol tica deve ser entendida por todos na
66. as revis es O contrato deve prever crit rios de aceita o do software tratamento de mudan a dos requisitos do comprador durante o desenvolvimento o tratamento de problemas detectados ap s a aceita o as atividades a serem desempenhadas pelo comprador no que concerne a especifica o dos requisitos a defini o das facilidades ferramentas e itens de software a serem fornecidos pelo comprador procedimentos e padr es a serem usados e requisitos de replica o do software Devem ser designadas pessoas de ambas as partes para o estabelecimento das especifica es dos requisitos do comprador O plano de desenvolvimento deve conter a defini o do projeto em termos de objetivos e relacionamento com outros projetos do comprador ou do fornecedor a organiza o dos recursos para o projeto incluindo estrutura da equipe responsabilidades uso de subcontratados e recursos materiais as fases de desenvolvimento o cronograma do projeto e a identifica o de planos correlatos como plano da qualidade plano de ger ncia de configura o plano de integra o e plano de teste O plano de desenvolvimento deve ser atualizado na medida do progresso do projeto para cada fase do desenvolvimento devem ser estabelecidas as entradas e sa das O plano dever prever tamb m como o projeto ser gerenciado O plano deve identificar as regras pr ticas conven es ferramentas t cnicas e a ger ncia de configura o O fornecedor deve verificar a
67. assaram da melhor maneira poss vel todos seus conhecimentos e orienta es A Adriana pelo amor e incentivo nas horas dif ceis deste trabalho e tamb m da minha vida Volto a agradecer aos meus pais pelo incentivo e apoio que sempre obtive e com certeza sempre o terei iv SUM RIO LISTA DE FIGURAS E TABELAS sans puta da a erra VII ABSTRAC T IX a GU 1 Ed OBJETIVOS a a OA 3 1 2 ESTRUTURA DO TRABALHO sa 3 2 VERIFICA O DE SOPEMARE caraca a LENA faia NA ada 4 II CONCENT OS 4 2 2 ROTEIRO DE VERIFICA O SOFTWARE 6 2 3 ATIVIDADES RELATIVAS VERIFICA O 9 2 3 1 VERIFICA O DO CONTRATO us aaa a o do a 9 2 3 2 VERIFICA O DO PROCESSO asd ES O 11 2 3 3 VERIFICA O DOS REQUISITOS iremos eee terrace 11 2 3 4 VERIFICA O DO PROJETO 0 aU ana 13 2 3 5 VERIFICA O DO CODIGO Des si ei sa 13 2 3 6 VERIFICA O DA 14 2 3 7 VERIFICA O DA 15 3 NORMAS E MODELOS 17 3 1 NORMA SQ EE SUR e a Dn E E O 17 3
68. belecido s o encorajadas a adotar padr es Como conseq ncia da ado o dos padr es espera se uma redu o significativa de ocorr ncia dos erros de programa o mais comuns Os padr es estabelecem um estilo de programa o uniforme A Para poder assegurar n veis de qualidade satisfat ria necess rio atuar sobre o processo de desenvolvimento de modo que se comentam poucos erros idealmente nenhum Em particular necess rio atuar sobre o processo de codifica o de modo que entre outros requisitos de qualidade os programas estejam quase corretos por constru o e que sejam de f cil compreens o e manuten o O benef cio de um padr o somente ser percebido caso seja efetivamente adotado por todos os participantes do desenvolvimento A ado o comprovada verificando a conformidade dos artefatos com os padr es Em uma grande parte das vezes os controles de conformidade s o realizados por meios de inspe es 2 3 6 VERIFICA O DA INTEGRA O Segundo Rocha 2001 verifica o da integra o observa se os componentes e unidades de c digo bem como itens de hardware e software foram integrados completa e corretamente de acordo como um plano de integra o Conforme Anacleto 1996 o gerenciamento integrado de software tem o prop sito de integrar as atividades de engenharia e gerenciamento de software em um processo de software coerente e definido que adaptado a partir do processo padroniz
69. consulta begin TbRes Append incluir pergunta selecionada TbRes FieldByName Pergunta asString FrmConResCod TbPerl FieldByName Pergunta asString TbRes Post grava a pergunta na tela de sele o end FrmConResCod Free fecha a tela de consulta TbRes Append end Na figura 15 apresenta a tela de Consulta da Pergunta do Contrato Nesta tela ser o mostradas todas as perguntas cadastradas na tela cadastro da Pergunta do Contrato conforme j mostrado na figura 11 Esta tela acionada ao clicar no bot o Inserir Nova Pergunta da tela da Sele o da Pergunta da Atividade do Contrato Para inserir uma pergunta na tela onde ser o armazenadas as perguntas que ir o ao checklist basta dar dois clique r pidos na pergunta escolhida 44 FIGURA 15 TELA DA CONSULTA DAS PERGUNTAS DA ATIVIDADE DO CONTRATO Consulta Da Pergunta Do Contrato iof x Pergunta 2 4 o fomecedor tem a capacidade de atender os requisitos 5 os requisitos est o consistentes e cobrem as necessidades do usu rio E a empresa opera com procedimentos formalizados 7 s o empregados m todos de estimativas de custo prazos e recursos 8 os requisitos est o consistentes e cobrem as necessidades do usu rio 9 crit rios e procedimentos de aceita o est o estipulados de acordo com os requisitos ILE resultados reais e desempenho do fornecedor contratado s o acompanhados com base n 11 a metodologia de desenvolvimento est clarame
70. da qualidade uma ferramenta para a avalia o constante e sistem tica da manuten o da qualidade S o Paulo Makron Books 1994 P DUA Wilson P Filho Engenharia de software fundamentos m todos padr es Rio de Janeiro LTC 2001 POMPILHO S An lise essencial Rio de Janeiro Infobook 1994 PRESSMAN Roger S Engenharia de software S o Paulo Makron Books 1995 ROCHA Ana R Cavalcanti da MALDONADO C Jos WEBER C Kival Qualidade de software teoria e pr tica S o Paulo Prentice hall 2001 SOMMERVILLE Ian Software engineering Harlow Addison Wesley 2001 STAA Von Arndt Programa o modular desenvolvendo programas complexos de forma organizada e segura Rio de Janeiro Campus 2000 10 11 12 13 14 15 16 17 18 19 20 53 ANEXO CHECKLIST VERIFICA O DO CONTRATO o fornecedor tem a capacidade de atender os requisitos os requisitos est o consistentes e cobrem as necessidades do usu rio procedimentos adequados para tratar altera es nos requisitos e prioriza o de problemas est o estipulados procedimentos e sua abrang ncia para intera o e coopera o entre as partes s o estipulados incluindo propriedade garantia direitos autorais e confidencialidade crit rios e procedimentos de aceita o est o estipulados de acordo com os requisitos a empresa opera com procedimentos formalizados um procedimento documentado utilizado
71. dades deste trabalho foi a constru o do checklist para o processo de verifica o Isto porque necessitou se de uma ampla pesquisa para encontrar as perguntas para cada atividade do processo de verifica o da norma ISO IEC 12207 exigiu a necessidade de verificar se existiam perguntas iguais ou semelhantes e outra dificuldade foi a necessidade de formular novamente algumas perguntas pois deveriam seguir apenas um tipo de resposta A atividade de verifica o essencial ao desenvolvimento de software pois procura garantir o desenvolvimento de produtos de software de alta qualidade e de baixo custo com base em um processo de software bem estabelecido com alta qualidade e produtividade A qualidade de software determinada pela qualidade dos processos utilizados para o desenvolvimento Deste modo a melhoria da qualidade de software obtida pela melhoria da qualidade dos processos Ap s o estudo das normas chegou se a conclus o que a norma ISO IEC 12207 a mais completa relativa ao processo de verifica o de software por ter se mostrado mais abrangente no aspecto da verifica o de sistemas As outras normas estudadas ISO 9000 3 ISO IEC 15504 e o modelo CMMI foram utilizadas no comparativo pelo motivo de que boa parte de seus processos s o contemplados pela norma ISO IEC 12207 Na cria o das perguntas do checklist foi bastante til para o comparativo O processo proposto tomou como base a norma ISO IEC 12207 para auxiliar o pr
72. de implementa o das solu es 4 1 1 2 1 a realiza o de testes e est relacionado aos processos ENG 1 6 teste de software para verificar atendimento aos requisitos inclui regress o e ENG 1 7 integra o e teste de sistema obs toda a parte de verifica o semelhante ao processo SUP 4 Pode tamb m fazer uso de t cnicas como peer reviews provas formais e an lise de rastreabilidade SUP 4 5 verifica o da integra o Observa se os componentes e unidades de c digo bem As atividades de verifica o devem incluir inspe o ensaio e Verificar desempenho verificar conformidade dos processos com padr es e Integra o de produto tem como objetivo montar o produto dos componentes de produto assegurar que 28 como itens de hardware e software foram integrados completa e corretamente de acordo como um plano de integra o etc 6 4 2 6 monitoriza o de processos e produto de projeto produ o instala o e de assist ncia t cnica an lises criticas de projeto 4 1 1 2 2 procedimentos verificar conformidade dos produtos verificar correteza e completeza do software entregue SUP 4 2 o produto como integrado funcione corretamente e entregar o produto Preparar a integra o para o produto Assegurar a compatibilidade de interface Montar os componentes de produto e entregar o produto n vel 3
73. de manuten o de software padronizado e documentado em cada projeto existe um programa de treinamento de engenharia de software exigido para os profissionais de software existe um programa de formal de treinamento para os l deres de revis o de projetos e codifica o as coberturas de revis o de c digo e projeto s o medidas e registradas a cobertura de testes medida e registrada em cada fase de testes funcionais as an lises de erros s o conduzidas para determinar suas causas relacionadas ao processo as tarefas s o definidas e colocadas em sequ ncia adequadamente o paralelismo razo vel dados os recursos dispon veis a base para a estimativa de custos razo vel a estimativa de custos foi desenvolvida usando se dois m todos independentes foram usados dados de produtividade e de qualidade hist ricos as diferen as de estimativas foram conciliadas os or amentos e prazos finais predefinidos s o real sticos o cronograma consistente existe uma pol tica documentada definindo os objetivos e o compromisso para com a qualidade esta pol tica compreendida implementada e mantida em todos os n veis da organiza o est o definidas as responsabilidades e autoridades de todo o pessoal que administra desempenha e verifica atividades que influem na qualidade os requisitos recursos e pessoal treinado para atividades de verifica o est o identificados o sistema da qualidade analisado criticame
74. dimento para que um exame met dico de artefatos de software selecionados seja efetuado por parte de parceiros do produtor de maneira a identificar defeitos e reas onde s o necess rias corre es ou melhorias os drivers de teste foram identificados e o trabalho para desenvolv los foi planejado o teste de fadiga para o software foi especificado procedimento de teste foram especificados tanto testes de caixa branca como de caixa preta foram testados todos os caminhos l gicos independentes foram identificados e listados casos de teste com seus resultados esperados o tratamento de erros ser testado os valores limites ser o testados a temporiza o e o desempenho ser o testados foi especificada uma varia o aceit vel dos resultados esperados h auditorias internas da qualidade para verificar a efic cia do sistema da qualidade as auditorias s o programadas com base na import ncia das atividades relativas qualidade as auditorias e a es de acompanhamento s o desempenhadas de acordo com procedimentos documentados os resultados das auditorias s o documentados e levados aten o do pessoal que tem responsabilidade pela rea auditada na a o corretiva mantida documenta o e procedimentos para investigar as causas de n o conformidades do produto e a a o corretiva necess ria para prevenir a repeti o s o analisados todos os processos opera es de trabalho concess es registros
75. e acompanhamento da efic cia da reutiliza o mecanismos e responsabilidades s o estabelecidas para assegurar que os profissionais sejam treinados e capazes de desempenhar preven o de defeitos e que sejam pessoalmente comprometidos com as melhorias do processo o apoio da tecnologia inclui a an lise de cada tarefa para determinar o apoio requerido os aspectos econ micos deste apoio e a prototipa o de ferramentas e m todos potenciais o conjunto de ferramentas progressivamente aperfei oado para incluir o uso de novas tecnologias e m todos 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 89 h plano de teste para software o plano de teste contempla teste de item de software teste de integra o teste de sistema e teste de aceita o o plano de teste contempla casos de testes dados de testes e resultados esperados o plano de teste contempla tipos de testes a serem desempenhadas ou seja funcional testes de interfaces testes de desempenho teste de usabilidade o plano de teste contempla ambiente de teste e ferramentas de testes o plano de teste contempla os crit rios pelos quais o t rmino do teste ser julgado o plano de teste contempla documenta o do usu rio durante o teste levado em considera o o registro dos resultados dos testes os respons veis s o notificad
76. e n meros de magnitudes muito diferente 156 evitar compara o de igualdade 157 tratar possibilidades de overflow e underflow 158 tratar possibilidades de erro de arredondamento 159 no caso de caracters e texto considerar usar constantes em lugar de literais 160 agrupar as constantes de textos em um arquivo de recursos para facilitar mudan a e tradu o 161 no caso de vari veis booleanas observar fazer com que as vari veis booleanas ajudem a documentar o programa 162 substituir testes complicados por vari veis booleanas intermedi rias 163 criar seu pr prio tipo booleano se n o existir na linguagem 164 no caso de vari veis enumeradas observar usar enumera es para facilitar a leitura 165 usar enumera es para aumentar a confiabilidade promovendo checagens em tempo de compila o 166 usar enumera es para facilitar modifica es 167 usar enumera o para generalizar vari veis booleanas para mais de dois resultados poss veis 168 testar valores inv lidos 169 reservar uma entrada para representar valores inv lidos 170 se a linguagem n o tiver enumera es simula la por meio de uma conven o de denomina o 171 no caso de arranjos observar usar arranjos apenas para acesso seqiiencial e n o rand mico de prefer ncia 172 checar os pontos extremos dos arranjos 173 em arranjos multidimensionais checar a ordem dos subscritos 174 em malhas aninhadas cuidado com as confus es entre
77. elecidos e mantidos 25 O prop sito do controle e monitoramento de projeto n vel 4 prover conhecimento no progresso do projeto par que a es corretivas apropriadas possam ser tomadas quando o desempenho do projeto divergir significativamente do plano As metas espec ficas para alcan ar ou implementar esta rea chave s o as seguintes e monitorar o projeto defronte ao plano o desempenho atual e o progresso do projeto s o monitorados contra o plano de projeto e gerenciar a o corretiva at sua conclus o s o administradas a es corretivas e gerenciadas at sua conclus o quando o desempenho do projeto ou resultados divergem significativamente do plano O prop sito da ger ncia de contrato de fornecedor n vel 4 gerenciar a aquisi o de produtos e servi os de fornecedores externos ao projeto para os quais existem um acordo formal As metas espec ficas para alcan ar ou implementar esta rea chave s o as seguintes e estabelecer contratos com fornecedores s o estabelecidos e mantidos contratos com os fornecedores esatisfazer os contratos com fornecedores contratos com os fornecedores s o satisfeitos por ambos o projeto e o fornecedor O prop sito da an lise causal e resolu o n vel 5 identificar causas de defeitos e outros problemas e tomar a es para lhes evitar de acontecer no futuro As metas espec ficas para alcan ar ou implementar esta rea chave s o as seguintes e dete
78. em de forma completa e acurada a entidade que representam 198 todos os identificadores representam palavras ou frases do idioma utilizado 199 separado as palavras constituintes dos nomes longos 200 abrevia es s o evitadas se a linguagem o permitir 201 0s nomes s o pronunci veis 202 05 nomes s o diferenci veis pelos seus primeiros caracteres 203 evitado o uso da nota o h ngara e de outras nota es que denotem informa es de baixo n vel 204 evitado a ocorr ncia de identificadores com nomes que possam ser confundidos 205 evitado o uso de nomes predefinidos no ambiente de desenvolvimento a n o ser que estejam sendo redefinidos 206 quando existe uma segii ncia correta de execu o das instru es ela facilmente reconhec vel pela leitura do c digo 207 0 c digo organizado de foram que possa ser lido de cima para baixo 208 instru es correlatas est o agrupadas e os grupos s o separadas por linha em branco e linhas de coment rio 209 n o utilizar o else final de uma cadeia de ifs para tratar um caso restante reserva lo para tratar condi es de exce o 210 ao utilizar sele es m ltiplas case switch classificado os casos por ordem alfab tica num rica ou por frequ ncia de ocorr ncia mantendo entretanto juntos os casos cujo tratamento usa o mesmo c digo 211 usado sempre o tipo de malha mais adequado l gica da itera o 212 malhas tipo for s o usadas quando se
79. em produtos pendente as certifica es internas foram assinadas e recebidas existem comprometimentos internos pendente todas as unidades de trabalho e pedidos foram conclu dos se houver um per odo de contrato h alguma op o ao terminar o contrato a identifica o do item de software propicia o relacionamento com os requisitos estabelecidos em contrato s o estabelecidos e mantidos procedimentos para revis o de contrato e para a coordena o destas atividades quanto aos contratos o escopo do contrato e os requerimentos s o definidos e documentados as conting ncias e riscos poss veis s o identificados as informa es propriet rias s o adequadamente protegidas os requerimentos que diferem daqueles na proposta s o resolvidos as responsabilidades com subcontratos est o definidas a terminologia a ser empregada entendida por ambas as partes em rela o aos itens da qualidade no contrato est o definidos os crit rios de aceita o est definido o tratamento de mudan a nos requisitos do cliente durante o desenvolvimento est definido o tratamento de problemas detectados ap s a aceita o do produto servi o incluindo reclama es e queixas do cliente acerca de itens relacionados com a qualidade as atividades a serem desempenhadas pelo cliente especialmente s relativas a especifica o de requisitos instala o e aceita o est o definidos as facilidades ferramentas e itens de so
80. equisitos SUP 4 6 A ger ncia de requisitos tem como objetivo gerenciar os requisitos de produtos do projeto e componentes do produto e identificar inconsist ncias entre o planos de projeto e produtos de trabalho e os requisitos n vel 4 verifica o do projeto Observa se o projeto est correto e coerente com os requisitos se ele implementam apropriadamente as sequ ncias de eventos entradas sa das requisitos de seguran a com m todos rigorosos etc O fornecedor deve elaborar um plano para verifica o de todas as sa das ao final de cada fase de desenvolvimento compara o do novo projeto com um projeto semelhante 14 aprovado caso haja algum dispon vel assegurar que os requisitos especificados foram O prop sito do controle e monitoramento de prover conhecimento no progresso do projeto para que a es corretivas apropriadas possam ser tomadas quando o desempenho do projeto divergir significativamente do plano Monitorar o projeto defronte ao plano Gerenciar a o corretiva at sua conclus o 6 4 2 3 atendidos n vel 4 5 6 2 verifica o do Observa se o Desempenha e Normalmente envolve c digo c digo est de acordo com os requisitos se test vel e correto se est de acordo com os requisitos e padr es de codifica o se implementa requisitos cr ticos e de seguran a com m todos rigorosos etc 6 4 2 5 verifica atividades
81. es est o tratadas de forma precisa 142 todas as quebras dos relat rios est o demonstradas 143 existe quebras de controle de detalhes pequenos e grandes e quebra final de controle 144 95 arquivos est o criados de acordo com as especifica es do projeto 145 05 tamanhos de campos nos arquivos est o adequados e n o h truncamento inesperado ou perda de d gitos significativos 146 existe precis o matem tica arredondamento 147 relat rios est o de acordo com o layout do projeto 148 relat rios est o de acordo com o layout do projeto 149 a numera o de p ginas do relat rio esta precisa 150 a ortografia dos t tulos e dos cabe alhos est correta 151 tamanhos de campos est o adequados nos relat rios 152 dados para auditoria totais de controle est o precisos 153 0s tempo de execu o aceit vel de acordo com padr es preestabelecidos 154 a situa o de aus ncia de arquivo vazio s o testadas em todos os passos do sistema 155 existe meios dispon veis de verifica o cruzada dos resultados do sistema exaustivamente testados 156 s o realizados relat rios diferentes com as mesmas informa es ou informa es derivadas 157 todas as interface est o funcionando de modo preciso entre programas 158 todas as interface est o funcionando de modo preciso entre subsistemas 159 todas as interface est o funcionando de modo preciso entre outro sistemas 160 todas as interface est o funcionando de modo preciso com sis
82. es s o estabelecidos para assegurar que cada requisito do produto seja test vel mecanismos e responsabilidades s o estabelecidos para assegurar a produ o de padr es do processo bem como relat rios de custos mecanismos s o estabelecidos para assegurar que os padr es do processo de software sejam inteiramente revistos e que sua ado o seja aceita pela comunidade t cnica da empresa 67 68 69 70 71 T2 73 74 75 76 77 78 79 80 81 82 83 84 85 86 mecanismos e responsabilidades s o estabelecidos para a revis o da efic cia do grupo de engenharia do processo de software mecanismos do processo s o estabelecidos para assegurar a valida o da abordagem do projeto contra as necessidades dos usu rios um plano de inser o de tecnologia estabelecido o ambiente de desenvolvimento de software estabelecido e instalado um conjunto de padr es de ferramentas compat veis definido e est dispon vel os projetos de desenvolvimento de software s o organizados de acordo com um roteiro metodol gico que represente um modelo de ciclo de vida as atividades relacionadas com a qualidade s o planejadas e implementadas com rela o ao modelo de ciclo de vida usados nas especifica o dos requisitos do cliente os requisitos do cliente abrangem itens como desempenho seguran a confiabilidade e privacidade estes requisitos s o c
83. existe uma nica interpreta o de cada item da especifica o de requisitos o significado de cada item compreendido e a especifica o f cil de ser lida 100 todo item da especifica o de requisitos pertinente ao problema e sua solu o 101 durante o desenvolvimento de programas e testes de aceita o ser poss vel determinar se o item da especifica o foi satisfeito 102 cada item da especifica o de requisitos pode ser rastreado at sua origem no ambiente do problema 103 cada item da especifica o de requisitos pode ser implementado com as t cnicas ferramentas recursos e pessoal dispon veis dentro do custo estimado e limita es do cronograma 104 as especifica es de requisitos s o uma declara o dos requisitos que devem ser satisfeitas pela solu o do problema e n o obscurecidas pelas solu es propostas para o problema 105 as especifica es de requisitos s o expressas de maneira que cada item possa ser modificados sem um impacto excessivo sobre os demais itens 106 voc se preocupou com as pessoas que ter o de usar o sistema 107 voc se preocupou com as pessoas que ter o de operar o sistema 75 108 voc se preocupou com as pessoas que ter o de manter o sistema 109 se voc fosse uma dessas pessoas voc alteraria algo no projeto para facilitar sua vida 110 todos elemento da especifica o deixa clara a sua inten o 111 foram tiradas as redund ncia da especifica
84. far o 99 100 99 os verbetes encontram se sob os t tulos corretos 100 existem t tulos alternados para os verbetes que podem ser acessados atrav s de terminologia diferente 101 0s verbetes importantes e n o importantes para os mesmos termos est o diferenciados 102 0s termos est o segmentados adequadamente ou existem muitas refer ncias s p ginas sob um nico termo indicando a necessidade de subcategorias 103 existem verbetes sup rfluos 104 existe uma bibliografia de publica es de pr requisitos 105 se n o existem pr requisitos isto est expresso 106 a bibliografia est onde ela ser encontrada antes que se tente ler todo o documento 107 as refer ncias est o completas o suficiente para localizar as publica es 108 existem coment rios para ajudar o leitor a escolher a publica o adequada 109 existe uma bibliografia de publica es complementares que podem conter informa o adicional 110 se o documento for a nica fonte de informa o isto est expresso 111 as refer ncias s o completas o suficiente para a localiza o das publica es 112 existe coment rios para ajudar o leitor a escolher a publica o adequada 113 a organiza o dos documentos propriamente contribui para facilitar a localiza o das informa es 114 a numera o das p ginas sensata 115 a numera o das p ginas completa 116 existe uma esquem tica de programa 117 documentos padr o s o usados 118 a docu
85. ftware a serem entregues ao cliente est o definidas os padr es e procedimentos a serem utilizados est o definidos os requisitos para replica o do software est o definidos quanto requerido por contrato h procedimentos para o tratamento ap s a entrega do produto h procedimentos para assegurar que produtos ou servi os adquiridos para agregar ao produto estejam em conformidade com os requisitos h registros sobre a qualifica o de desempenho de subcontratados 45 46 47 48 49 50 51 92 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 de ordens de compra ou subcontratos para assegurar que as se es de trabalho respons veis pela verifica o dos bens ou servi os sendo comprados est o conforme o padr o o presente padr o tem por objetivos assegurar a exist ncia e facilitar a manuten o de informa es gerenciais relativas aos m dulos e demais arquivos que comp em programas assegurado a exist ncia e a facilita o da manuten o de especifica es detalhadas relativas aos diferentes componentes de um m dulo os m dulos tenham um estilo de documenta o consistente uniforme e independente do autor a uma facilidade a modifica o de programas redigidos por outrem sem que isto acarrete perda de qualidade o projeto interno as unidades de trabalho incompletas foram documentadas e justificadas a ger ncia foi not
86. gem utilizada dos padr es adotados etc Depende pois da organiza o respons vel pelo desenvolvimento dos programas 1 1 OBJETIVOS O objetivo deste trabalho especificar e implementar um software que auxilie o processo de verifica o baseado na norma ISO IEC 12207 Os objetivos espec ficos do trabalho s o a comparar as atividades de verifica o previstas em normas conhecidas como ISO 9000 3 ISO IEC 15504 e modelo CMMI visando ampliar as atividades de verifica o previstas na norma ISO IEC 12207 b criar instrumentos para facilitar a ado o do processo de verifica o como a utiliza o de checklists 1 2 ESTRUTURA DO TRABALHO A seguir apresentada uma s ntese dos pr ximos cap tulos constantes desse trabalho O segundo cap tulo apresenta conceitos estudados do processo de verifica o da norma ISO IEC 12207 e um roteiro mostrando a especifica o do processo e suas atividades O terceiro cap tulo apresenta as tr s normas e o modelo de qualidade estudados demonstrando detalhadamente o processo de verifica o de software de cada alternativa e mostra tamb m um comparativo entre as mesmas O quarto cap tulo trata da especifica o do software de apoio a verifica o de software onde constam a lista de eventos diagrama de contexto diagrama de fluxo de dados e o diagrama de entidade e relacionamento DER O quinto cap tulo apresenta a implementa o do software de apoio a verifica
87. gerente do projeto h um detalhamento das atividades e estrutura o anal tica do projeto a programa o das atividades no tempo dispon vel ou necess rio a determina o dos resultados tang veis a s o alcan ados durante a execu o do projeto a programa o da utiliza o e aprovisionamento dos recursos humanos e materiais necess rios ao gerenciamento e execu o do projeto delineamento do procedimentos de acompanhamento e controle a serem utilizados na implanta o do projeto estabelecimento e estrutura org nica formal a ser utilizada para o projeto a alguma estrutura o do sistema de comunica o e de decis o a ser adotado designa o e comprometimento dos t cnicos que participar o do projeto existe treinamento do envolvidos com o projeto o plano de desenvolvimento deve contem a defini o do projeto em termos de objetivos e relacionamento com outros projetos do comprador ou do fornecedor a organiza o dos recursos para o projeto inclui estrutura da equipe responsabilidades uso de subcontratados e recursos materiais as fases de desenvolvimento utilizado o cronograma do projeto e a identifica o de planos correlatos como plano da qualidade plano de ger ncia de configura o plano de integra o e plano de teste 60 88 o plano de desenvolvimento atualizado na medida do progresso do projeto 89 para cada fase do desenvolvimento estabelecidas as entradas e sa das
88. gnifica perder trabalho j feito desfazer algumas coisas e remendam outras A boa engenharia de requisitos reduz a instabilidade destes ajudando a obter os requisitos corretos em um est gio anterior ao desenvolvimento Entretanto altera es dos requisitos s o s vezes inevit veis A engenharia de requisitos sujeita a limita es humanas e mesmo que o levantamento seja perfeito podem ocorrer altera es de requisitos por causas externas aos projetos Note se que defeitos incluem situa es de falta de conformidade com requisitos expl citos normativos e impl citos Os defeitos associados a requisitos s o os mais dif ceis de tratar Eles levam a desentendimentos sem solu o entre o fornecedor e o cliente do produto Al m disso c o esses requisitos por defini o n o s o documentados bastante prov vel que eles n o tenham sido levados em conta no desenho do produto o que tornar a corre o dos defeitos particularmente trabalhosa O fluxo de requisitos re ne as atividades que visam a obter o enunciado completo claro e preciso dos requisitos de um produto de software Estes requisitos devem ser levantados pela equipe do projeto em conjunto com representantes do cliente usu rios chaves e outros especialistas da rea de aplica o O conjunto de t cnicas empregadas para levantar detalhar documentar e validar os requisitos de um produto forma a engenharia de requisitos O resultado principal do fluxo dos
89. houver um per odo de contrato h alguma op o ao terminar o contrato Atende as informa es propriet rias s o adequadamente protegidas Aende exitem produtos pendentes Atende se houver um per odo de contrato h alguma op o ao terminar o contrato Page 1 of 1 h De acordo com o roteiro da figura 1 o sistema de apoio ao processo de verifica o de software consegue atender todas as atividades do roteiro atrav s de um checklist espec fico para cada uma das reas de verifica o Seguindo o roteiro foram criados os cadastrados da organiza o e do avaliador para a verifica o de um software al m do plano de verifica o que faz o gerenciamento de todo o ciclo de vida do produto gerenciando as atividade perguntas e os relat rios 48 6 CONCLUS ES O objetivo inicialmente proposto foi realizado visto que o software implementado consegue atender ao conjunto de atividades presentes no processo de verifica o de software que s o a verifica o do contrato requisito projeto c digo integra o e documenta o Assim o software especificado e implementado mostrou se eficaz no aux lio ao processo de verifica o de softwares Este tipo de verifica o ajuda os desenvolvedores n o cometerem erros em novas aplica es com feedback de problemas passados para auxili los em dificuldades futuras Al m disso o software pode ser usado como guia para a realiza o de auditorias Uma das principais dificul
90. i veis test veis e refletem precisamente os requisitos do sistema os requisitos de software relacionados prote o seguran a e aos fatores cr ticos est o corretos conforme demonstrado por m todos adequadamente rigorosos as fases de teste importantes foram adequadamente identificadas e dispostas segiiencialmente a capacidade de acompanhar os crit rios requisitos de valida o foi estabelecida como parte da an lise de requisitos de software sua organiza o desenvolve e mant m um processo padronizado do software a organiza o coleta revisa e torna dispon veis informa es relacionadas ao uso do processo padronizado de software da organiza o por exemplo estimativas e dados reais de tamanho de software esfor os e custos dados de produtividade e avalia es de qualidade as a es associadas a defeitos identificados nos produtos intermedi rios de software durante as revis es s o acompanhadas at que os defeitos sejam resolvidos as atividades executadas para desenvolver e melhorar o processo de software s o revisadas periodicamente pela ger ncia superior medidas s o usadas para determinar a funcionalidade e qualidade dos produtos de software por exemplo quantidade tipos e gravidade dos defeitos identificados medidas s o usadas para determinar o estado das atividades de revis o por exemplo n mero de revis es executadas esfor os dispendidos nestas revis es e o n mero de produtos intermedi
91. ica o e definir um plano de verifica o O esfor o relativo devotado verifica o depende do tipo do sistema a ser desenvolvido e da t cnica organizacional 2 2 ROTEIRO DE VERIFICA O DE SOFTWARE A seguir demonstrado um roteiro proposto para a verifica o de software segundo a norma ISO IEC 12207 que demonstrada no trabalho de Frare 1998 Este roteiro ser adotado para fundamentar o software de apoio O roteiro facilita a interpreta o da ado o do processo de verifica o definido na norma ISO IEC 12207 A figura 1 utiliza uma representa o baseada em fluxograma bastante difundida e acess vel para interpreta o As atividades citadas s o referenciadas pelo n mero original na norma FIGURA 1 ROTEIRO DE VERIFICA O DE SOFTWARE Para determinar se o projeto justifica um esfor o de verifica o voc deve analisar os requisitos do projeto em fun o dos fatores cr ticos Estes fatores podem ser aferidos nos seguintes termos o potencial de que um erro n o detectado em um requisito do sistema possa causar danos graves riscos com a tecnologia utilizada entre outros 6 4 1 1 O projeto justifica um esfor o de verifica o Voc j possui um Sua organiza o plano para executar vai executar este este processo processo Um plano de verifica o deve ser Deve ser selecionada uma desenvolvido e documentado O plano organiza o qualificada deve indicar por exemplo as atividades respon
92. idade portabilidade modularidade 93 124 h um exame desses modelos deve incluir tanto o modelo funcional quanto os modelos de dados relacionais 125 existem estimativas de custo tempo e outros recursos que ser o necess rios para implementa o da alternativa 126 essas estimativas s o acompanhadas de uma descri o da t cnica utilizada para a estimativa 127 h uma identifica o daqueles m dulos que ser o implementados como hardware e aqueles que ser o implementados como software alguns ser o uma combina o de hardware e software 128 a recomenda o da equipe de projeto preliminar est adequadamente fundamentada 129 as informa es apresentadas no documento do projeto preliminar e durante a revis o do projeto preliminar lhe d o a seguran a de que o sistema de computador poder ser implementado para satisfazer os requisitos de forma a convence lo a utilizar o sistema proposto 130 0 sistema permite sa das e devolu o de rotinas fornecidas pelo usu rio 131 0 sistema pode processar mais de um arquivo ao mesmo tempo 132 0s arquivos do usu rio s o reformatados antes do processamento 133 no caso de reformata o gerado um novo arquivo 134 h alguma restri o especial 135 mais de um arquivo de sa da ode ser gerado durante uma nica rodada 136 0s formatos s o restritos 137 com rela o s sa das impressas s o de formatos razoavelmente flex veis 138 0 sistema permite o uso de fun es de
93. idade e per odos de utiliza o 160 efetuado as reprograma es no projeto segundo seu status e adotando os planos e programas iniciais com diretrizes 161 marcada pela dificuldade na manuten o das atividades dentro do que foi planejado e pelo desligamento gradual de empresas e de t cnicos do projeto 162 h uma acelera o das atividades que eventualmente n o tenham sido conclu das 163 realoca o dos recursos humanos do projeto para outras atividades ou projetos 164 elabora o de relat rios e transfer ncia dos resultados finais do projeto 165 emiss o de avalia o globais sobre o desempenho da equipe do projeto e os resultados alcan ados VERIFICA O DO C DIGO 1 o c digo rastre vel para projeto e para os requisitos test vel correto e aderente aos requisitos e padr es de codifica o 2 o c digo implementa a segii ncia de eventos apropriada interfaces consistentes dados e fluxo de controle corretos completeza aloca o de tempo e de or amentos apropriada e defini o isolamento e recupera o de erros o c digo selecionado pode ser originado a partir do projeto ou dos requisitos 4 o c digo implementa prote o seguran a e outros requisitos cr ticos corretamente conforme demonstrado por m todos adequadamente rigorosos 5 o projeto foi adequadamente traduzido em c digo os resultados do projeto procedimental devem estar dispon veis durante esta revis o 6 h erro
94. ifica o 125 s o feitas revis es de projeto 126 existem teste e monitora o de projeto produ o instala o e processos de servi o ou revis es de projeto do produto e auditoria do sistema da qualidade dos processos ou do produto 127 os planos de projeto demonstram ader ncia aos objetivos do plano de desenvolvimento e aos requisitos dos procedimentos 2 128 0s inputs de projeto s o identificados e documentados e sua sele o revisada para comprovar a adequa o 129 05 resultados do projeto detalhado para a especifica o precisa de cada fun o 130 existe defini o precisa do cabe alho de cada fun o classe e tipo de dados 76 131 0 projeto da estrutura de cada pacote est definindo precisamente os algoritmos 132 0 registrado do hist rico do projeto foi integrado base dos hist ricos de outros projetos 133 existe uma an lise dos hist ricos que permite atuar sobre o processo eliminando a defici ncia observadas 134 0s objetivos do projeto preliminar encontra se claramente definidos 135 no controle de limites todas as responsabilidades est o definidas 136 todas as pessoas est o de acordo com o grupo 137 cada imput fun o ou output est claramente definido por uma parte espec fica e identific vel do sistema 138 quanto interface homem m quina esta tudo conforme por parte do homem ou da m quina n o existe nenhuma diverg ncia 139 a uma adapta o por parte d
95. ificada quanto disponibilidade do pessoal do projeto a ger ncia foi notificada quanto disponibilidade das instala es do projeto o plano do projeto foi arquivado com todos os dados de suporte os excedentes do projeto foi arquivado com todos os dados de suporte os excedentes de material do projeto foram administrados o projeto externo foi obtido acordo com o propriet rio do projeto sobre a disposi o dos produtos restantes as certifica es e autoriza es externas foram assinadas e aprovadas os fornecedores foram notificados quanto a compromissos pendentes est o todas as partes cientes do encerramento pendente as instala es do projeto foram fechadas os procedimentos de auditoria e manuten o foram conduzidos o pessoal interno as preocupa es da equipe do projeto referentes a empregos futuros foram abordados a equipe est dedicada a manter os compromissos restantes do projeto ainda existem fatores de motiva o presentes para as tarefas e obriga es restantes as preocupa es referentes identidade da equipe foram abordadas o pessoal foi recolocado ou notificado da metodologia de realoca o o pessoal externo est o sendo feitos esfor os para assegurar que o interesse do contratante permane a atendido 68 69 70 71 T2 73 74 75 76 77 56 est o sendo feitos esfor os para assegurar que as atitudes e percep es do contratante referentes ao pro
96. j devem ter sido conclu dos O avaliador dever executar os seguintes passos a clicar no bot o Incluir b selecionar a organiza o a ser avaliada c informar a data da verifica o d informar a hora da verifica o e selecionar os avaliadores que executar o a verifica o f selecionar as atividades que dever o ser acordados pelas partes envolvidas na verifica o s apenas aquelas atividades escolhidas ir ativar as telas correspondente a esta atividade O avaliador s vai poder passar para a pr xima tela se alguns campos das atividades foram selecionadas FIGURA 12 TELA DE REGISTRO DO PLANO DE VERIFICA O Em seguida dever o ser selecionadas as quest es propostas para avalia o do processo de verifica o do software com base na estrutura anteriormente informada para a norma 42 ISO IEC 12207 Cada pergunta dever estar relacionada a uma atividade espec fica do processo a fim de verificar se a mesma est sendo contemplada ou n o pela organiza o No menu Configura o de Perguntas s aparecer o as atividades ativas escolhidas na tela anterior do Cadastro do Plano de Verifica o Ao clicar na op o do menu ativado ser aberto a tela de Sele o das Perguntas da Atividade do Contrato Nesta tela ser poss vel incluir apenas as perguntas requeridas pelo avaliador Ao entrar nesta tela j ser dado o nome da organiza o a ser avaliada e o nome do avaliador Para inserir u
97. jeto permane am est veis as quest es de transfer ncia de pessoal est o sendo abordadas com o contratante do projeto o pessoal chave e o contratante est o sendo notificados sobre os status do projeto existe uma metodologia de comunica o para manter as rela es entre o contratante e os gerentes do projeto seu e do contratado o fornecedor desempenha revis es e assegura que os requisitos sejam atendidos e que os m todos de projeto e implementa o sejam adequadamente utilizados o fornecedor mantem registros documentados de tais revis es antes das atividades de aceita o o cliente auxiliado na determina o de prazo o cliente auxiliado na determina o dos procedimentos de avalia o o cliente auxiliado na determina o do ambiente de hardware e software necess rio para a avalia o de aceita o o cliente auxiliado na defini o dos crit rios de aceita o VERIFICA O DO PROCESSO os requisitos de planejamento do projeto est o adequados e oportunos os processos selecionados para o projeto est o adequados implementados sendo executados como planejados e conforme o contrato os padr es procedimentos e ambientes para os processos do projeto est o adequados o projeto disp e de equipe e pessoal capacitado como requerido no contrato o escopo do software definido e delimitado sem ambigiiidades as atividades de revis es s o planejadas a atividade de preven o de defeito
98. laramente definidos de forma a serem validados durante a aceita o do produto h aprova o destes requisitos por parte do cliente antes do desenvolvimento do produto h controle da documenta o relativa aos requisitos do cliente todas as interfaces entre produto de software e outros software ou produtos de hardware s o claramente estabelecidos na especifica o de requisitos durante o desenvolvimento da especifica o dos requisitos h designa o de pessoas de ambas as partes para estabelecer a especifica o de requisitos do cliente durante o desenvolvimento da especifica o dos requisitos h formas e m todos para aprova o das especifica es e para mudan as nas especifica es o esfor o de defini o de requisitos documentado por ambas as partes projeto e implementa o no projeto de desenvolvimento levado em considera o as regras de projeto defini es de interfaces internas projeto e implementa o no projeto de desenvolvimento levado em considera o a metodologia espec fica tendo em vista o tipo de software que est sendo constru do projeto e implementa o no projeto de desenvolvimento levado em considera o a utiliza o de experi ncia passada para evitar a ocorr ncia de problemas similares projeto e implementa o no projeto de desenvolvimento levado em considera o a constru o das especifica es de forma que possam ser facilmente testadas e ma
99. litando uma utiliza o perfeita das capacidade da m quina 271 as sub rotinas padr o s o utilizadas 272 05 nomes padr es para reas s o usadas 273 apresenta o de formato a facilidade de pular para uma nova p gina utilizada para destacar componentes etc 274 linhas em branco s o usada para dividir par grafos etc 275 05 componentes s o de tamanho aceit vel 276 a paragrafa o usada para possibilitar uma maior clareza 277 cada comando com determinada fun o come a em uma nova linha 278 0s coment rios s o usados para possibilitar o entendimento 279 os itens de tipos similares s o alinhados mesma coluna 280 notas e coment rios h o suficiente para facilitar o entendimento 281 existe uma descri o da fun o do programa no seu in cio 282 existe uma descri o inicial no come o de cada componente 283 existe uma descri o para uma codifica o espec fica 284 s o teis claros e concisos 285 s o escritos ao mesmo tempo que o c digo 286 s o imediatamente identificados como notas circundados por asteriscos 6 287 est o em lugares padr es no programa 288 s o utilizadas para fornecer detalhes de m dulos sub rotinas chamados 289 s o usados para fornecer detalhe dos par metros de sub rotina 290 documenta o de programa a listagem de programa realmente existe 291 ela registra sua gera o e data 292 est armazenada no lugar certo 293 possui uma lista de refer
100. m desenvolvimento ou entregue e instalado o sistema controla a atualiza o simult nea de um item de software espec fico por mais de uma pessoa o sistema prov a coordena o para a atualiza o de m ltiplos produtos em uma ou mais instala o quanto requerido este plano contempla a organiza o ou reas envolvidas na ger ncia da configura o e responsabilidades atribu das para cada um h atividades de ger ncia da configura o a serem desempenhadas h ferramentas de ger ncia da configura o t cnicas e metodologias a serem utilizadas existe o est gio que os itens devem ser colocados sob o controle da ger ncia da configura o h procedimentos par identificar os itens de software durante todas as fases de desenvolvimento desde a especifica o at a replica e entrega cada item de software tem uma identifica o nica a identifica o de cada item de software para cada vers o contempla as especifica es funcionais e t cnicas a identifica o de cada item de software para cada vers o contempla todas as ferramentas de desenvolvimento que afetam as especifica es funcionais e t cnicas a identifica o de cada item de software para cada vers o contempla todas as interfaces com outros itens de software e hardware 100 a identifica o de cada item de software para cada vers o contempla todos os documentos e arquivos de computador relacionados ao item de software 101
101. ma pergunta clique no bot o Inserir Pergunta conforme mostra a figura 13 De forma an loga acontecer com as outras atividades selecionadas FIGURA 13 TELA DE SELE O DAS PERGUNTAS DA ATIVIDADE DO CONTRATO Selecionar Pergunta Do Contrato iof x Organiza o Empresa de Vendas de Produtos S A Avaliador Itabora Cordoni Ebertz os requisitos est o consistentes e cobrem as necessidades do usu rio E a empresa opera com procedimentos formalizados E h controle de mudan a E a metodologia de desenvolvimento est claramente estabelecida E s o empregadas t cnicas de inspe o e teste de sistemas E s o empregadas t cnicas de inspe o e teste de sistemas os projetos seguem os custos e prazos planejados as certifica es internas foram assinadas e recebidas E todas as unidades de trabalho e pedidos foram concluidos D se houver um per odo de contrato h alguma op o ao terminar o contrato 5 Inserir Nova Pergunta Salvar Excluir Finalizar Na figura 14 apresentado um trecho do c digo criado para tratar a inclus o da pergunta para a tela de Sele o de Pergunta 43 FIGURA 14 C DIGO FONTE DA IMPLEMENTA O procedure TFrmSelePerCod BitBtn3Click Sender TObject begin FrmConResCod TFrmConResCod Create Self chama a tela de consulta FrmConResCod ShowModal if FrmConResCod Inserir then inserir a pergunta da tabela de
102. menta o dispon vel est atualizada 119 existem documentos espec ficos para pedidos de modifica o corre o 120 s o mantidos procedimentos para controlar todos os documentos relativos ao sistema da qualidade 121 0s procedimentos para controle da documenta o contemplam 122 a determina o dos documentos sujeitos ao controle 123 a aprova o e emiss o de procedimentos 124 0 controle de mudan a nos documentos 125 0 controle de documenta o aplicado a documentos que descrevem o sistema da qualidade aplicado ao ciclo de vida do software 101 126 documentos de produto incluindo entradas para cada fase de desenvolvimento sa das de cada fase de desenvolvimento planos de verifica o e valida o e respectivos resultados manuais e documenta o de manuten o 127 h procedimentos para assegurar que os documentos e respectivas c pias estejam dispon veis em locais apropriados onde opera es essenciais par o efetivo funcionamento do sistema da qualidade s o desempenhadas 128 h procedimentos par que documentos obsoletos sejam removidos dos locais de uso 129 h procedimentos par a revis o e aprova o de mudan as nos documentos 130 h controle das vers es dos documentos 131 0s documentos s o reemitidos ap s determinado n mero de altera es 132 como os requisitos s o documentados 133 a interfaces organizacionais entre os diversos grupos est o definidas de maneira satisfat ria 134 como a
103. n vel de maturidade dos processos outra para o n vel de maturidade da organiza o como um todo Conforme Belloquim 2002 o CMMI al m de incorporar as melhorias propostas aprendidas em mais de uma d cada de uso do modelo SW CMM compatibiliza este modelo como os demais CMMs do SEI e com a ISO IEC 15504 Mas sua contribui o mais importante o grande aumento da flexibilidade na implanta o de projetos de melhoria dos processos de software Com a dupla representa o a implanta o do CMM atinge um ponto em que as necessidades de cada empresa podem ser levadas em conta como nunca Segundo Junior 2000 o CMMI um projeto que envolve um grande n mero de pessoas patrocinado pelo Departamento de Defesa Americano DoD desenvolvido pelo SEI em parceria com organiza es da ind stria e governo O prop sito do modelo CMMI fornecer guias para melhorar os processos organizacionais e a habilidade de gerenciar o desenvolvimento e manuten o de produtos e servi os atrav s da verifica o do status da melhoria de processos do estabelecimento de prioridades para melhoria e da implanta o desses processos O projeto foi constru do para atingir um conjunto inicial de modelos que cobrem tr s disciplinas engenharia de software engenharia de sistemas e desenvolvimento integrado de produto e processo Entre as principais metas tra adas para o modelo CMMI est o a integra o dos modelos de origem eliminando inco
104. ngo de todo o ciclo de vida do processo de desenvolvimento enquanto que os de valida o tendem ao ocorrer de uma forma concentrada e intensiva nas faces que abrange os testes modulares e de integra o J para Hetzel 1987 a verifica o uma avalia o realizada no final de uma fase com o objetivo de confirmar se as necessidades estabelecidas durante a fase anterior foram atendidas Em termos gerais a verifica o diz respeito atividade global de avalia o de software englobando a revis o inspe o teste an lise de desempenho e auditoria Uma preocupa o da verifica o assegurar que a representa o est em conformidade com todos os padr es selecionados Padr es estabelecem restri es de uso das linguagens de representa o Procura se atrav s do uso de padr es reduzir a probabilidade do cometimento de erros Outro objetivo dos padr es atuar sobre o formato ou estilo de apresenta o da representa o assegurando assim completeza legibilidade e uniformidade dos documentos Estas s o caracter sticas muito relevantes ao desenvolver artefatos que dever o ser lidos e mantidos por pessoas diferentes das que desenvolveram o artefato Deseja se em particular eliminar aspectos personalistas dos programas Staa 2000 O processo de planejamento da verifica o deve decidir um padr o e procedimento para a verifica o de software Deve se estabelecer um checklist para guiar a verif
105. nos de a o visando melhoria da qualidade s o produzidos sempre quando o projeto n o atinge as metas da qualidade o desempenho medido em fun o dos planos de qualidade e melhorias as customiza es de cada projeto em rela o aos padr es do processo s o retidas sob o controle da ger ncia de configura o de software as m tricas utilizadas no processo s o mantidas sob controle da ger ncia de configura o de software m tricas de qualidade dos subcontratados s o estabelecidas e acompanhadas o desempenho da rea de garantia da qualidade acompanhado e revisado padr es documentados s o produzidos para inspe es ferramentas e m todos planos de qualidade e monitorando de qualidade por atividade do processo procedimentos documentados s o produzidos para a customiza o do processo e do ambiente procedimentos documentados s o desenvolvidos para os planos de qualidade acompanhamento inspe es e customiza o do processo e do ambiente m todos documentados s o estabelecidos para a prototipa o e avalia o quantitativa do projeto prot tipos s o desenvolvidos para demonstrar a viabilidade de requisitos cr ticos antes que entrem no escopo do projeto medi es e an lise s o feitas sobre os n veis de defeitos nos produtos efici ncia e cobertura das inspe es e testes distribui es dos erros produtividade de tarefas e efic cia das ferramentas um banco de dados sobre o processo
106. nsforma o da informa o ocorrem enganos interpreta es err neas e outras faltas referenciadas neste texto como defeitos ou erros que podem ocasionar o mau funcionamento do sistema ou seja a ocorr ncia de falhas Salienta se que os defeitos podem ser introduzidos ao longo de todo o processo de desenvolvimento de software e necess rio que eles sejam determinados o quanto antes de prefer ncia na pr pria fase em que s o cometidos pois os custos associados s o maiores quando os defeitos s o identificados em fases posteriores Com o uso crescente de software nos mais diversos setores da sociedade a demanda e a preocupa o com a produ o de software de alta qualidade a baixo custo passou a ser um dos motivos que culminou na introdu o de atividades agregadas sob o nome de garantia de qualidade de software ao longo de todo o processo de desenvolvimento de software O objetivo da verifica o assegurar que o software ou uma determinada fun o do mesmo esteja sendo implementado corretamente Premitindo inclusive se os m todos e processos de desenvolvimento foram adequadamente aplicados Em geral s o conduzidas com base em um checklist lista de verifica o ou de confer ncia adequada a cada fase ou produto A pr pria atividade de revis o pass vel de auditoria para certifica o do processo e de evolu o com base na experi ncia da equipe Rocha 2001 Uma outra defini o emitida por Pressman 1
107. nsist ncias e reduzindo duplica es b redu o de custos ao implantar uma melhoria de processos modelo baseada 25 aumento da claridade e compreens o do modelo atrav s de uma terminologia comum estilo consistente regras de constru o uniformes e componentes comuns d necessidade de assegurar aos produtos desenvolvidos para o modelo consist ncia com a futura norma ISO 15504 Sendo assim os principais benef cios apontados s o uma eficiente e efetiva avalia o e melhoria atrav s da disciplina de m ltiplos processos em uma organiza o custos de treinamento e avalia o reduzidos uma vis o comum e integrada de melhoria para todos os elementos de uma organiza o Na representa o por est gios as reas de processo est o agrupadas em est gios n veis de 2 a 5 Cada rea de processo cont m pr ticas atividades a serem implementadas para concluir o prop sito da rea de processo Os n veis de maturidade para tal representa o do modelo CMMI est o assim definidos inicial gerenciado definido quantitativamente gerenciado otimizado 3 6 PROCESSO DE VERIFICA O SEGUNDO O MODELO CMMI Segundo Junior 2000 uma organiza o pode optar por alcan ar a melhoria de processo sob duas abordagens capacita o de processo ou maturidade organizacional O modelo CMMI suporta a capacita o de processo atrav s de uma representa o cont nua e a maturidade da organiza o atrav s de uma
108. nte as Atividade do Contrato Atividade do Processo Atividade dos Requisitos Atividade do Projeto Atividade do C digo Atividade da Integra o e Atividade da Documenta o 46 FIGURA 17 RELAT RIO DAS PERGUNTAS DA ATIVIDADE DO CONTRATO 8 HE me Relatorio Do Contrato Nome Organiza o Empresa de Vendas de Produtos 5 4 Nome Avaliador Itabora Cordoni Ebertz Data Inicio Plano 15 11 2002 Hora In cio Plano 08 00 00 Data Termino Plano 15 11 2002 Hora termino Plano 10 00 00 Descri o do software Sistema de Controles de Vendas S Resposta Atende Atende Atende Atende Atende Atende Atende N o Atende N o Atende N o Atende N o Sabe N o Sabe Pergunta h controle quantitativo est tico da qualidade do sotwae o f omecedor tem a capacidade de atender os requisitos o m todo de embalagem controlado pelo fomecedor os requisitos est o consistentes e cobrem as necessidades do usu rio s o empregadas t cricas de inspe o eteste de sistemas s o empregadas t cricas de inspe o eteste de sistemas a empresa opera com procedimentos formalizados s o empregados m todos de estimetiws de custo prazos e recursos assegurado que tudo o que foi prometido foi fomecido e foi de damente zprowado crit rios e procedmertos de aceita o est o estipulados de acordo com os requisitos a metodologia de desemolhimento est claamente estabelecida as certifca es
109. nte estabelecida 12 h controle quantitativo est tico da qualidade do software 13 s o empregadas t cnicas de inspe o e teste de sistemas 14 o m todo de embalagem controlado pelo fornecedor 15 assegurado que tudo o que foi prometido foi fornecido e foi devidamente aprovado 16 as certifica es internas foram assinadas e recebidas 17 as conting ncias e riscos poss veis s o identificados 18 quanto aos contratos o escopo do contrato e os requerimentos s o definidos e documentado 19 s o estabelecidos e mantidos procedimentos para revis o de contrato e para a coordena o Ap E a a E A E A a E E N Ao clicar no menu Plano de Verifica o s estar o ativadas as atividades selecionadas na tela do Cadastro do Plano de Verifica o e tamb m s vai ser ativada se na tela de Sele o da Pergunta da Atividade foi selecionada alguma pergunta para esta atividade Efetuando se os passos anteriormente apresentados poss vel realizar as respectivas verifica es do processo da atividade de software da organiza o Al m da tela Verifica o do Contrato mostrada na figura 18 existem no menu Plano de Verifica o uma tela de verifica o para cada atividade Verifica o do Processo Verifica o dos Requisitos Verifica o do Projeto Verifica o do C digo Verifica o da Integra o e Verifica o da Documenta o Conforme a figura 16 a tela da Verifica o do Contrato j vem com o
110. nte pela administra o em intervalos apropriados s o mantidos registros destas an lises o comprador quando da contrata o dos servi os designa um representante com autoridade para lidar com os aspectos contratuais revis es conjuntas com o cliente s o realizadas a intervalos programados para verificar conformidades do software com os requisitos verificar resultados de teste de aceita o os resultados de tais revis es s o documentadas 46 47 48 49 50 51 52 53 54 53 56 57 58 59 60 61 62 63 64 65 66 67 58 uma pol tica da empresa estabelecida requerendo que cada novo produto ou release seja medido uma pol tica da empresa estabelecida requerendo que todos os projetos estabele am planos para aperfei oar os m todos padr es a nfase organizacional sobre o planejamento e acompanhamento da qualidade recursos s o dispon vel para apoiar a introdu o de tecnologia cada grupo de desenvolvimento principal conduz periodicamente um trabalho de avalia o revis es gerenciais peri dicas s o realizadas para avaliar o desempenho em termos dos planos de qualidade e a es de melhoria da qualidade s o oferecidos cursos padr es sobre planejamento da qualidade ger ncia quantitativa de processo m todos avan ados de desenvolvimento prototipa o planos de qualidade s o produzidos para cada projeto pla
111. nterfaces organizacionais 6 t cnicas responsabilidades organizacionais 6 controle da execu o 5 5 2 Confirmar que cada produto de trabalho ou servi o resultado de um processo reflete corretamente s especifica es de entrada do processo SUP 4 3 SUP 4 4 Planejamento do projeto de software tem o prop sito de estabelecer planos razo veis para a execu o de atividades de engenharia de software e para o gerenciamento do projeto de software Esta rea envolve o desenvolvimento de estimativas para o trabalho a ser executado o estabelecimento de compromissos necess rios e a defini o de um plano de execu o do trabalho n vel 3 27 verifica o dos requisitos Observa se os requisitos do sistema s o coerentes s o fact veis e test veis se os requisitos do software s o coerentes s o fact veis e test veis e se refletem com precis o os requisitos do sistema etc 6 4 2 3 A verifica o do desenvolvimento deve estabelecer que as sa das de cada fase atendam aos requisitos de entrada correspondentes mediante a ado o de medidas de controle de desenvolvimento 5 4 6 Envolve a defini o de uma estrat gia de verifica o de crit rios de verifica o para todos os produtos de trabalho e para as atividades de verifica o para confirma que cada produto de software e ou servi o de um processo ou projeto est o de acordo com os r
112. ntidas na implementa o levado em considera o as regras de programa o linguagens de programa o conven es de identifica o de atributos tabelas ndices arquivos 74 87 na implementa o levado em considera o metodologias de implementa o 88 h revis es para assegurar que os requisitos est o sendo atingidos e que os m todos de projeto e implementa o est o sendo empregados 89 estas revis es impedem o prosseguimento do projeto antes que as defici ncias sejam efetivamente sanadas 90 a verifica o deve inclui os programas correspondem ao tamanho e desempenho estimados 91 o rendimento satisfat rio pode ser aperfei oado posteriormente 92 houve alguma altera o no n mero de transa es ou no tamanho dos arquivos 93 a sa da est de acordo com as necessidades 94 existem pontos speros que possam ser suavizados 95 realizado alguma a o de emerg ncia de revis o 96 todos os itens necess rios para a especifica o de requisitos para a solu o do problema foram inclu dos 97 todo item constante da especifica o de requisitos encontram se livre de erros 98 cada item da especifica o de requisitos exato e n o vago existe uma nica interpreta o de cada item da especifica o de requisitos o significado de cada item compreendido e a especifica o f cil de ser lida 99 cada item da especifica o de requisitos exato e n o vago
113. ntific veis considere o uso de defaultes Fa a ambos repercutirem no output 138 certifique se de que todas as varia es sejam inicializadas antes de serem utilizadas 139 n o perca tempo com um bug 140 use compiladores com facilidades de deputa o 141 cuidado com erros que provoquem o t rmino do programa na primeira execu o 142 atente para os desvios certos em fun o da igualdade 143 teste os programas em seus valores limites 144 certifique se de que c digo de coment rio apenas fa a cada coment rio valer 145 formate um programa para ajudar o leitor a compreende lo 146 documente seus layouts de dados 147 existe um objetivo de diretrizes para facilitar a manuten o do c digo promovendo sua legibilidade e desestimulando as constru es mais propensas a erros 148 a codifica o de software o padr o descreve um conjunto de diretrizes que devem ser seguidas na implementa o de software 149 algumas diretrizes para o uso de tipos num ricos em geral usar constantes no lugar de literais exceto no caso de 0 e 1 82 150 verificar se o valor dos divisores n o pode ser 03 151 explicar todas as convers es de tipo 152 evitar compara o de tipos mistos 153 no caso de inteiros considerar tratar possibilidades de truncamento 154 tratar possibilidade de estouro overflow inclusive em resultados intermedi rios 155 no caso de n meros de ponto flutuante considerar evitar somas e subtra es d
114. o A futura norma ISO IEC 15504 define processos e pr ticas que podem ser implementados para estabelecer e aprimorar a capacidade de aquisi o desenvolvimento manuten o opera o e suporte de software em organiza es Estas pr ticas s o organizadas utilizando se uma arquitetura que combina duas perspectivas uma perspectiva funcional an loga perspectiva da norma ISO IEC 12207 compreendendo quais os processos que devem existir numa organiza o e uma outra perspectiva que avalia o n vel de capacita o de cada um destes processos an loga ao CMMI O uso da norma permite que as organiza es possam perceber a exist ncia ou n o de processos espec ficos bem como a capacita o dos que existem tra ando um caminho para melhoria Al m dos processos o SPICE define tamb m os seis n veis de capacita o de cada processo que pode ser incompleto executado gerenciado estabelecido previs vel e otimizado 3 2 PROCESSO DE VERIFICA O SEGUNDO A NORMA ISO IEC 15504 Conforme Emam 1998 o processo de verifica o se encontra na categoria de suporte 4 que descreve como executar a verifica o dos produtos de trabalho e inclui atividades como 18 confirmar se cada produto de software e ou servi o de um processo ou projeto est o de acordo com os requisitos confirmar se cada produto de trabalho ou servi o resultado de um processo reflete corretamente s especifica es de entrada do processo
115. o uma das principais causas de insucesso n o s financeiro como tamb m t cnico A falta de uma especifica o de boa qualidade a falta de uma defini o precisa do que vai ser o resultado do desenvolvimento a falta de um planejamento abrangente e consistente com os requisitos do sistema a desenvolver o acompanhamento inexistente ou errado a falta de controle da qualidade e de controle das altera es s o os principais vil es 2 3 3 VERIFICA AO DOS REQUISITOS De acordo com Rocha 2001 verifica o dos requisitos observa se os requisitos do sistema s o coerentes s o fact veis e test veis se os requisitos do software s o coerentes s o fact veis e test veis e se refletem com precis o os requisitos do sistema Segundo P dua 2001 os requisitos s o as caracter sticas que definem os crit rios de aceita o de um produto Uma especifica o de requisitos pode conter requisitos incompletos inconsistentes ou amb guos Alguns desses problemas decorrem da pr pria linguagem natural 12 z que normalmente usada para express los Outros decorrem de t cnicas deficientes de elabora o dos requisitos Um problema comum no desenvolvimento de software a instabilidade dos requisitos que ocorre quanto cliente e usu rios trazem novos requisitos ou altera es de requisitos quando o desenvolvimento j est em fase adiantada A instabilidade dos requisitos costuma ter um custo muito alto geralmente si
116. o de software apresentando as principais telas e relat rios Por fim mostra se no sexto cap tulo a conclus o com principais resultados do trabalho e as sugest es para poss veis melhoramentos 2 VERIFICA O SOFTWARE Este cap tulo oferece uma vis o geral sobre o processo de verifica o de software onde ser o enfocados assuntos como conceitos roteiro e atividades 2 1 CONCEITOS O processo de verifica o de software tem o objetivo de detectar erros o mais breve poss vel no ciclo de vida de software que constitui uma tentativa de introduzir a verifica o em todo o desenvolvimento do software Conforme citado por Sommerville 2001 verifica es de software s o representa es de an lise e checagem de sistemas semelhantes aos documentos requeridos projetos de diagramas e o c digo fonte de programas Pode ser aplicado em todo os est gios do processo Enquanto uma nova organiza o ganha experi ncia no processo de verifica o pode usar resultados daquele processo como um significado de um processo de melhoramento Sempre que poss vel o processo poderia ser modificado para eliminar as raz es de defeitos Assim eles n o iriam mais ocorrer novamente em sistemas futuros Segundo Rocha 2001 os produtos de software consistem em um conjunto de informa es em diferentes n veis de abstra o e num conjunto de transforma es e decis es associadas a essas transforma es No processo de comunica o e tra
117. o de desenvolvimento atualizado na medida em que o projeto avan a 103 antes do in cio de cada fase h uma revis o e aprova o dos produtos da fase anterior 104 h uma metodologia claramente definida para o desenvolvimento do produto 105 nesta metodologia h a identifica o das fases de desenvolvimento a serem executadas 106 h identifica o das entradas para cada fase 107 h identifica o das sa das requeridas de cada fase 108 h procedimentos de verifica o a serem realizados em cada fase 109 h an lise de problemas potenciais associados com as fases de desenvolvimento e com a constru o dos requisitos 110 0 plano de desenvolvimento estabelece como os projetos devem ser gerenciados incluindo a identifica o de cronograma de desenvolvimento e implementa o os produtos a serem entregues o controle do progresso as responsabilidades organizacionais os recursos e atribui o de tarefas equipe do projeto bem como os interfaces t cnicos e organizacionais entre diferentes grupos 111 0 plano de desenvolvimento identifica as regras pr ticas e conven es par o desenvolvimento as ferramentas e t cnicas e a ger ncia de configura o 112 revis es de progresso planejadas 113 as revis es de progresso s o documentadas 114 as entradas para cada fase de desenvolvimento s o definidas e documentadas 115 cada requisito pode ser verificado quanto a sua consecu o 116 as sa das requeridas de
118. o projeto onde todas as faces do projeto receberam a nfase do que parecia merecer 140 tudo o que foi considerado defeito a altera o foi feita 141 0 projeto reflete o equipamento no qual ser executado 142 seu projeto independente da linguagem de programa o que ser usada voc disp e de recursos para depura o 143 0 projeto todo foi implementado 144 0 c digo executa o que o projeto requer o projeto foi traduzido corretamente 145 0 projeto est correto e completo 146 as atividades t pica dessa fase foram identificadas conforme a necessidade ou oportunidade 147 foi feito algum equacionamento e defini o do problema 148 todos sabiam as determina es dos objetivos e metas a serem alcan ados 149 foi feito uma an lise do ambiente do problema 150 foi feito uma an lise das potencialidades ou recursos dispon veis 151 existe uma avalia o da viabilidade de atingimento dos objetivos 152 existe uma estimativa dos recursos necess rios 153 existe uma elabora o da proposta do projeto 154 existe uma apresenta o da proposta e venda da id ia 155 existe uma avalia o e sele o com base na proposta submetida T11 156 existe uma decis o quanto execu o do projeto 157 ativada a comunica o entre os membros da equipe do projeto 158 executada as etapas previstas e programadas 159 utilizado os recursos humanos e materiais sempre que poss vel dentro do que foi programado quant
119. o suporte ao processo de revis o e inspe o de software que completaria o processo de verifica o 50 REFER NCIAS BIBLIOGR FICAS ABNT ASSOCIA O BRASILEIRA DE NORMAS T CNICAS NBR ISO IEC 12207 tecnologia de informa o processos do ciclo de vida do software Rio de Janeiro 1998 ABNT ASSOCIA O BRASILEIRA DE NORMAS T CNICAS NBR ISO 9000 3 Normas de gest o da qualidade e garantia da qualidade diretrizes para aplica o da NBR 19001 desenvolvimento fornecimento e manuten o de software Rio de Janeiro 1993 ANACLETO Ana L cia Mensura o do processo de software baseado no modelo CMM SEI 1999 93 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau BARBARESCO A Eduardo Software de apoio ao processo de gerencia da configura o segundo normas e modelos da qualidade 2000 64 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau BELLOQUIM tila Qualidade de Software o que h de novo no mercado Revista Developers Rio de Janeiro n 68 p 11 abr 2002 BIZZOTO Carlos E Negr o Influ ncia da utiliza o de metodologia de desenvolvimento sobre a qualidade do software um enfoque quantitativo 1992 139 f Disserta o Mestrado em Engenharia da Produ o De
120. ocesso de verifica o de software como p de se observar no decorrer deste estudo A norma apesar de flex vel quanto ao uso sem o uso de um roteiro de implanta o exige um alto grau de dificuldade para sua ado o A proposta 49 deste trabalho de criar um software para o apoio ao processo de verifica o baseou se no roteiro de Frare 1998 que facilitou a implanta o e a compreens o da mesma Atualmente as normas e modelo n o possuem nenhum tipo de question rio por isso optou se pela utiliza o de checklist conseguindo assim facilitar o processo de verifica o A base para identifica o das atividades foram realizadas pela norma ISO IEC 12207 Apesar de extenso o checklist est sujeito a pequenas corre es no que diz respeito a melhor formula o do questionamento ou at sua adequada classifica o O software permite a inclus o e altera o das perguntas o que torna o processo mais din mico de fundamental import ncia para a ado o da proposta apresentada o uso do checklist dispon vel no anexo Eles foram especificados para abranger todas as atividades da norma ISO IEC 12207 contempladas na proposta garantindo dessa maneira uma verifica o em todo o ciclo de vida do software Como sugest o para trabalhos futuros o software poderia ser testado em v rias empresas que desejam realizar a verifica o de software visando uma maior valida o do trabalho Uma outra sugest o seria a inclus o d
121. olha nomes para as vari veis que n o sejam confusos 116 evite desvios desnecess rios 117 n o use desvios condicionais como substitutos par uma express o l gica 118 se uma express o l gica for dif cil de ser compreendida tente modifica la 119 utilize arrays de dados pra evitar segii ncias de controle repetitivas 120 escolha uma representa o de dados que torne o programa simples 121 escolha uma representa o de dados que torne o programa simples 122 use if else para implementar desvios de m ltiplos caminhos 123 usado sub rotinas 124 use gotos somente para implementar uma estrutura funcional 125 evite completamente o uso de gotos se voc puder manter o programa leg vel 126 n o conserte c digo ruim reescreva o 127 escreva e teste um programa grande em pequenas partes 128 use procedimentos de recursividade para estruturas de dados definidas recursivamente 129 teste inputs visando que sejam plaus veis e v lidos 130 certifique se que de as entradas n o infringem os limites do programa 131 termine a entrada atrav s de um end of file ou um marcador e n o por um contador 132 identifique os inputs inconsistentes recupere os se poss vel 133 torne as entradas f ceis de serem preparadas e as sa das auto explicativas 134 utilize formatos uniformes de entradas 135 torne os inputs prova de erros de leitura 136 use inputs de formato livre sempre que puder 137 use inputs auto ide
122. organiza o As responsabilidades e autoridades quanto s atividades relativas qualidade na organiza o devem estar claramente definidas Os recursos e pessoal para verifica o do sistema da qualidade devem estar definidos O fornecedor deve indicar um representante da administra o com responsabilidade e autoridade para assegurar que o sistema da qualidade esteja em opera o conforme os requisitos da norma O fornecedor e o comprador devem realizar revis es conjuntas para verificar ader ncia do software s especifica es e resultados de teste O fornecedor deve estabelecer documentar e manter procedimentos para investigar causas de n o conformidade do produto analisar processos iniciar a es preventivas aplicar controles para que as a es corretivas sejam realizadas e implementar e registrar mudan as nos procedimentos em fun o dos resultados da a o corretiva Na revis o do contrato o fornecedor deve estabelecer e manter procedimentos para a revis o do contrato e para a coordena o dessas atividades O fornecedor deve revisar cada contrato para assegurar que o escopo e requisitos sejam definidos e documentados que as conting ncias sejam identificadas que informa o propriet ria seja adequadamente protegida que quaisquer requisitos diferentes daqueles na proposta sejam solucionados que a responsabilidade do fornecedor com subcontratos esteja definida O fornecedor deve manter 2 registros dess
123. os seus requisitos de modo a assegurar que implementam exatamente todos os requisitos especificados sua organiza o segue um plano documentado de atividades para desenvolvimento e melhoria do processo de software o projeto segue uma pol tica organizacional documentada para executar revis es voc mant m um registro do tempo gasto e dos recursos utilizados durante o teste servindo para calcular o custo do teste voc arquiva e guarda casos de testes e massas de dados para uso futuro voc mant m sempre um registro dos problemas operacionais usando o para avaliar e aumentar a efic cia dos procedimentos de teste a organiza o prov um procedimento documentado para executar um plano de testes direcionado valida o do software e seus componentes quanto a sua adequa o para o uso em seu pretendido ambiente operacional um sistema de ger ncia de configura o e de controle de mudan a estabelecido para requerimentos codifica o e resultados de testes padr es documentados s o produzidos para estimativas de tamanho de software proje o de recursos prazos e planos de produto guias de estilo de produto s o desenvolvidos para orientar as atividades de projeto e codifica o procedimentos documentados s o produzidos para o desenvolvimento e aprova o dos planos do produto aprova o para mudan as nos requerimentos projetos ou c digo condu o de auditorias e revis es gerenciais os m
124. os para a resolu o de problema os respons veis s o notificados para a resolu o de problema feita uma valida o do software antes da entrega para o cliente em termos de sua opera o e quando poss vel em condi es reais s o especificadas as fun es a serem testadas s o definidas as responsabilidades de ambas as partes na avalia o do teste h a restaura o do ambiente do usu rio ap s o teste quando o teste sob condi es de campo exigido replica o entrega e instala o no caso de reaplica o do software especificado o n mero de c pias do software especificado o tipo de meio para cada item de software incluindo formato e vers o especificado a documenta o requerida como manuais e guias do usu rio especificado termos de licenciamento s o especificados os aspectos relativos a cust dia e back up de c pias especificado a obriga o de reposi o de c pias ao cliente h procedimentos para verificar a exatid o das c pias ap s sua replica o durante a instala o do software as responsabilidades de ambas as partes s o definidas em termos de cronograma incluindo fins de semana durante a instala o do software as responsabilidades de ambas as partes s o definidas em termos de acesso s instala es do cliente f sicas password etc 63 64 65 66 67 68 69 70 71 72 73 74 TX 76 TT 78 79
125. partamento de Engenharia de Produ o e Sistemas Universidade Federal de Santa Catarina Florian polis BENTO S Deisy Software de apoio ao processo de aquisi o segundo normas de qualidade 2000 49 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau DUARTE S Alexandre Software de apoio ao processo de documenta o baseado em normas de qualidade 2000 66 f Trabalho de Conclus o de Curso Bacharelado em 51 Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau EMAM Khaled El Spice the theory and practice of software process improvement and capability determination Los Alamitos Calif rnia IEE Computer Society 1998 FERNANDES Aguinaldo Aragon Ger ncia de software atrav s de m tricas garantindo a qualidade do projeto processo e produto S o Paulo Atlas 1995 FRARE Alexandre Proposta de roteiro de implanta o da norma internacional ISO EC 12207 processos do ciclo de vida de software 1998 97 f Trabalho de Conclus o de Curso Bacharelado em Ci ncias da Computa o Centro de Ci ncias Exatas e Naturais Universidade Regional de Blumenau Blumenau FREEDMAN P Alexandre GERALD M Weinberg Manual de walkthroughs inspe es e revis es t cnicas de especifica es de sistemas e programas S o Paulo Makron Books
126. plementado a documenta o t cnica corresponde exatamente ao que est implementado a documenta o e todo o c digo est catalogado e acess vel equipe de manuten o foram considerados poss veis efeitos colaterais associados a mudan a a solicita o de mudan a foi documentada avaliada e aprovada a mudan a uma vez feita foi documentada e relatada a todas as partes interessadas uma revis o de aceita o final foi realizada para ter a garantia de que todo o software foi adequadamente atualizado testado e substitu do o documento de projeto preliminar cont m uma descri o dos procedimentos utilizados para elabora o do projeto preliminar ou existe alguma refer ncia a tais procedimentos este procedimento deve incluir uma descri o da t cnica de projeto utilizada existe uma explica o da representa o do projeto h uma descri o dos procedimentos de testes casos de testes resultados de testes e an lise dos testes utilizados h uma descri o dos procedimentos avalia o e dos crit rios utilizados todas as fases do ciclo de vida da documenta o foram consideradas 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 Si 58 59 60 61 62 63 64 65 66 67 68 69 98 existem condi es para o feedback do usu rio existem condi es pra se fazer mudan as eventuais modifica es no sistem
127. programa o s o realizados teste de unidade em rela o de faltas e defici ncias encontradas pelas ferramentas de apoio ao desenvolvimento s o feitos defini o dos casos de teste existe algum m todo os dados de teste escolhidos para cada caso de teste ao ter os resultados obtidos ao executar os testes s o constru dos laudos de avalia o dos testes relat rios de problemas indicando o estado do problema a causa do problema e a solu o dada Este relat rio cumulado e descreve a hist ria de evolu o do m dulo assegurado que cada programa adequado ao usu rio assegurado que cada programa opera exatamente conforme a sua especifica o o conjunto de programas interagem conforme especifica o a documenta o t cnica e de uso aux lios manuais tutoriais existem est completa e consistente como o que se encontre implementado existe alguma prepara o aos testes aloca o de tarefas equipe de testes todas as condi es foram testadas identificadas e documentadas s o feitas cria o dos arquivos de testes para execu o de todas as fun es do sistema 100 a seqii ncia de arquivos est o corretas 101 estabelecimento de valores iniciais s o significativos 102 todos os tipos de registros est o inclu dos 103 0 volume de arquivo grande o suficiente para demonstrar grupos de controles totais quebras de p ginas nos relat rios 104 estabelecimento de per odo
128. projeto selecionado pode ser originado a partir dos requisitos 4 o projeto implementa proje o seguran a e outros requisitos cr ticos corretamente conforme demonstrado por m todos adequadamente rigorosos 5 os requisitos de software se refletem na arquitetura de software 6 os grupos de engenharia identificam acompanham e resolvem problemas entre os grupos por exemplo incompatibilidade de cronogramas riscos t cnicos ou problemas a n vel de sistema 7 o projeto conduz reuni es para an lise de causas para identificar causas comuns dos defeitos 8 conseguida uma efetiva modularidade 9 os m dulos s o funcionalmente independentes 10 as atividades para desenvolvimento e melhoria dos processos de softwares dos projetos e da organiza o s o coordenadas atrav s da pr pria organiza o por exemplo via um grupo de processo de engenharia de software 11 a ger ncia revisa formalmente os status dos projetos de software 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 71 voc conduz revis es inspe es internas do projeto de software os itens resultantes das a es de revis o de projeto s o feitos integralmente os itens das a es resultantes das revis es de c digo s o feitos integralmente a arquitetura de programa fatorada s o definidas interfaces para os m dulos e par
129. quadamente a entre outros 6 4 2 3 O projeto deve ser verificado considerando os seguintes crit rios o projeto est correto e consistente com os requisitos e rastre vel aos mesmos o projeto selecionado pode ser originado a partir dos requisitos entre outros 6 4 2 4 O c digo deve ser verificado considerando os seguintes crit rios o c digo rastre vel para o projeto e para os requisitos test vel correto e aderente aos requisitos e padr es de codifica o o c digo implementa a segii ncia de eventos apropriada interfaces consistentes entre outros 6 4 2 5 A integra o deve ser verificada de acordo com os seguintes crit rios os componentes de software e unidades de cada item de software foram completa e corretamente integrados dentro do item de software as tarefas de integra o foram executadas de acordo com um plano de integra o entre outros 6 4 2 6 A documenta o deve ser verificada de acordo com os seguintes crit rios a documenta o est adequada completa e consistente a prepara o da documenta o est oportuna a ger ncia de configura o dos documentos segue procedimentos especificados 6 4 2 7 2 3 ATIVIDADES RELATIVAS VERIFICA O O processo de verifica o de software realizado ao longo de todo o desenvolvimento do sistema Podem ser utilizadas para controlar a qualidade de uma variedade de atividades tais como verifica o do contrato verifica o do proces
130. rminar as causas de defeitos as origens de causas de defeitos e outros problemas s o sistematicamente determinadas e endere ar as causas de defeitos as origens de causas de defeitos e outros problemas s o sistematicamente endere adas para prevenir sua ocorr ncia futura 3 7 QUADRO COMPARATIVO Ap s realizado o estudo do processo de verifica o das normas ISO IEC 12207 ISO 9000 3 ISO IEC 15504 SPICE e o modelo CMMI chegou se a um comparativo conforme a tabela 1 Essa tabela apresenta o que cada norma diz a respeito dos processos de verifica o 26 Nesta tabela a primeira coluna indica as atividades que devem ser atendidas pelos processos de verifica o de software e as demais colunas indicam os nomes das normas de qualidade O crit rio adotado para especificar essa tabela foi separar cada atividade do processo de verifica o das normas e modelo de qualidade e coloc los lado a lado para fazer um comparativo para verificar se h pontos em comum nessas normas TABELA 1 COMPARATIVO DO PROCESSO DE VERIFICA O DE SOFTWARE Atividade de verifica o ISO IEC 12207 ISO 9000 3 ISO IEC 15504 SPICE CMMI verifica o do contrato Observa se o fornecedor possui capacidade para satisfazer os requisitos se esses s o coerentes e abrangem as necessidades do usu rio se existem procedimentos adequados para manipular as mudan as nos requisitos crit rios de aceita o etc
131. rquivos cada arquivo tem sua FCB cada arquivo controlado por uma FCB mas uma FCB pode controlar mais de um arquivo o arquivo ser 99 o campo ser 9999999 9 independente do tamanho do campo cada caractere ser um o status de interrup o setado em opcional e nunca mais resetado o status de interrup o setado em opcional cada vez que uma rotina que poderia t lo setado for terminada o status de interrup o setado em opcional todo o tempo um outro lugar onde a informa o de exce o aparece no arquivo xyz um outro tipo de informa o que aparece no arquivo xyz a informa o de exce o a informa o de exce o estar no arquivo xyz tamb m a sequ ncia terminal num flag e tamb m termina fim de arquivo isto a sequ ncia termina ou flag ou num fim de arquivo a segii ncia termina com a condi o dupla de flag mais fim de arquivo uma FCB controla dois arquivos isto ambos os arquivos cada arquivo controlado por um FCB isto existem duas FCBs para os dois arquivos uma para cada um o total de controle extra do do registro que o atual no sentido cont bil o total de controle extra do do registro que est sendo atualmente considerado pelo programa uma tabela atualizada por cada lista cada lista tem sua nica tabela para atualizar cada lista tem sua tabela para atualizar que pode n o ser nica a soma de
132. s vel para conduzir a do ciclo de vida e produtos de software verifica o Esta organiza o sujeitos verifica o as tarefas de deve ter assegurado a verifica o requeridas para cada atividade independ ncia e autoridade para do ciclo de vida e produto de software executar as atividades de entre outros 6 4 1 5 verifica o 6 4 1 3 O contrato deve ser verificado considerando os seguintes crit rios o fornecedor tem a capacidade de atender os requisitos os requisitos est o consistentes crit rios e procedimentos de aceita o est o estipulados de acordo com os requisitos entre outros 6 4 1 3 Voc quer verificar um contrato O processo deve ser verificado considerando os seguintes crit rios requisitos de planejamento Voc quer do projeto adequados e oportunos processos verificar um selecionados para o projeto implementados e processo executados adequadamente entre outros 6 4 2 2 FIGURA 1 ROTEIRO DE VERIFICA O DE SOFTWARE CONTINUA O Voc quer efetuar verifica o dos requisitos Voc quer efetuar verifica o de projeto Voc quer efetuar verifica o do c digo Voc quer efetuar verifica o da integra o Voc quer efetuar verifica o da documenta o O processo deve ser verificado considerado os seguintes crit rios requisitos de planejamento do projeto adequados e oportunos processos selecionados para o projeto implementados e executados ade
133. s atividades Fregiientemente ela utilizada pela indica o de inspe es visuais ou atividades de teste realizadas nas instala es do fornecedor em vez de controles posteriores A verifica o do fornecedor fregientemente constitui um m todo eficaz de assegurar que determinados crit rios estejam sendo observados em vez de adotar uma inspe o de recebimento pelo comprador Uma exig ncia para determinar a adequa o ou conformidade ao v rios controles aplicados ao processo sendo fornecido est agrupada sob o termo verifica o do fornecedor Um caso de avalia o de fornecedor o desenvolvimento de uma lista de fornecedores aprovados pela corpora o A lista forma ent o a base para contactar fornecedores potenciais em rela o a neg cios futuros Cientes de que a compra foi iniciada e que sabem as datas esperadas de recebimento dado in cio aos passos necess rios para a verifica o dos bens e servi os contrato da rea da qualidade do fornecedor verifica o do fornecedor inspe o do fornecedor inspe o de recebimento verifica o de dados gerados pelo fornecedor isto certificados resultados gr ficos de controle de processo De acordo com P dua 2001 o esfor o de uma organiza o para melhorar a qualidade de seus sistemas informatizados pode ser perdido por causa de falhas de contratados Para que isso n o aconte a a organiza o contratante deve estar capacitada em gest
134. s de ortografia ou tipogr ficos 7 as conven es de linguagem foram usadas adequadamente 8 existe concord ncia em rela o aos padr es de codifica o quanto ao estilo de linguagem coment rios e cabe alho do modular 9 h coment rios incorretos ou amb guos 10 os tipos de dados e a declara o de dados s o apropriados 11 as constantes f sicas est o corretas 12 todos os itens da lista de confer ncia do walhthrough de projeto foram reaplicados conforme necess rio 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 20 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 78 s o aplicadas os padr es de exig ncia projetos e revis es de c digos todas as interfaces de usu rio que utilizem sele es por menu t m uma regi o definida no v dio janela onde fica o menu t m t tulos identificadores do menu oferecem uma ou mais listas de op es t m um processo de sele o da op o letra c digo posi o do cursor bem definida existir um e somente um caracter de fim de arquivo alguns caracteres ser o designados como caractere de fim de arquivo haver pelo menos um caracter de fim de arquivo o valor imediatamente ap s a quantidade o n mero de controle que definido por sua posi o se existir um n mero de controle ele vir ap s a quantidade um FCB File Control Block controla todo o conjunto de a
135. s informa es de tempo 122 h dumps de arquivo extra dos ap s a execu o dos testes 123 h disponibilidade dos resultados de execu o paralelas 124 0 tempo de execu o aceit vel de acordo co padr es preestabelecidos 125 h mem ria suficiente dispon vel para execu o e expans o moderada do tamanho de programas 126 5 dados de entrada aceitos s o formatados e sem erros 127 todos os caminhos l gicos est o executados corretamente 128 todos os dados inv lidos foram detectados 129 combina es de transa es inconsistentes foram identificadas 130 mensagens de edi o foram testadas 131 condi es de n o correspond ncia ou invalid key foram testadas 132 execu o de situa o de aus ncia de arquivo existe situa o de arquivo vazio 133 atualiza o de arquivos precisa e completa de acordo com as especifica es 134 processamento correto do primeiro registro 69 135 inclus o de registros antes da leitura do primeiro registro esta feita corretamente 136 l gica de correspond ncia entre arquivos esta funcionando 137 adi o de registros ap s processamento do ltimo registro esta feita corretamente 138 0s campos est o atualizados conforme especificados substitui o de quantidades adi o de qualidade etc 139 elimina o ou adi o de registro est o executada corretamente 140 transa es m ltiplas por registro do arquivo mestre est o executadas corretamente 141 altera es nas chav
136. s s o planejadas uma vez identificadas as causas comuns de defeitos s o priorizadas e eliminadas sistematicamente a terminologia clara os recursos s o adequados para o escopo Os recursos est o prontamente dispon veis os riscos em todas as categorias importantes foram definidos um plano de gerenciamento dos riscos est em andamento Os participantes das revis es recebem o treinamento necess rio para executar tais tarefas voc conduz os testes como uma atividade sistem tica e organizada segundo uma metodologia bem definida e planejada 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 57 os m todos e instrumentos de teste s o bem compreendidos e utilizados nos momentos certos voc usa controle de configura o de software voc revisa formalmente cada contribui o de projeto de software antes de se comprometer voc estima formalmente o tamanho esfor o e custos do software voc planeja formalmente agendas de software voc mede o tamanho e a complexibilidade de cada m dulo de software no decorrer do tempo voc mede e rastreia os erros defeitos atrav s da manuten o do ciclo de vida voc usa um mecanismo para controlar as altera es nas exig ncias do software voc usa um mecanismo para controlar quem altera o c digo e quando voc usa um processo
137. s sa das de todas as fases do desenvolvimento A implementa o o fornecedor deve desempenhar revis es e assegurar que os requisitos sejam atendidos e que os m todos de projeto e implementa o sejam adequadamente utilizados O fornecedor deve manter registros documentados de tais revis es Antes de desempenhar as atividades de aceita o o fornecedor deve assistir comprador na identifica o da programa o da aceita o procedimentos para avalia o o ambiente de hardware software e recursos necess rios e os crit rios de aceita o a serem utilizados Na entrega e instala o deve ser verificada e a determina o do n mero de c pias do software a serem entregues tipo de meio magn tico a ser utilizado incluindo formatos ea estipula o da documenta o requerida e quest es relativas a direitos autorais 22 per odo de obriga o do fornecedor suprir c pias e as c pias a serem entregues dever o ser verificadas quanto a sua completeza eos pap is do fornecedor e comprador dever o estar plenamente estabelecidos quanto instala o 3 5 MODELO CMMI Segundo Junior 2000 foi desenvolvido o modelo CMM Integrated System Software Engineering O CMM SE SW n o apenas uma reuni o dos modelos CMM existentes mas sim um framework que acomoda m ltiplas disciplinas e flex vel o suficiente para suportar duas representa es diferentes de est gios e cont nuo uma para verificar o
138. sam estar numa ordem particular est o seqiienciados corretamente 94 os blocos de coment rios est o inclu dos nas reas funcionais importantes 95 os coment rios s o precisos e significativos 96 num programa segmentado est claro o porqu da segmenta o 97 cada segmento independente ou existe uma forte depend ncia de outros segmentos 98 os grupos then else est o alinhados 99 os ninhos de ifs est o indentados adequadamente 100 0s blocos de coment rios e observa es s o posicionados eficientemente 101 0 projeto todo foi implementado 102 0 c digo executa o que o projeto requer o projeto foi traduzido corretamente 103 cada campo a ser inicializado est definido corretamente 104 antes do primeiro uso de qualquer campo ele foi inicializado adequadamente 105 foi especificado o campo correto 106 cada desvio alvo de uma simples instru o goto est correto e praticado ao menos uma vez 107 0 c digo est codificado idealmente isto com instru es em menor n mero e mais eficientes 108 escreva de forma clara n o seja prolixo 109 diga o que voc quer dizer simples e diretamente 110 utilize fun es de biblioteca 111 evitado vari veis tempor rias 112 escreva de forma clara n o sacrifique a clareza pela efici ncia 113 existe express es repetitivas por chamadas a uma fun o comum 81 114 utilize par nteses pra evitar ambigiiidades 115 esc
139. so verifica o dos requisitos verifica o do projeto verifica o do c digo verifica o da integra o e verifica o da documenta o Estas atividades que agora ser o relatadas servir o para a realiza o do sistema de apoio ao processo de verifica o que ser implementado Para cada uma dessas atividades do processo de verifica o da norma ISO IEC 12207 o software realizar um checklist para verificar se o desenvolvimento da atividade est de acordo com a norma ISO IEC 12207 2 3 1 VERIFICA O DO CONTRATO Segundo Rocha 2001 verifica o do contrato observa se o fornecedor possui capacidade para satisfazer os requisitos se esses s o coerentes e abrangem as necessidades do usu rio se existem procedimentos adequados para manipular as mudan as nos requisitos e crit rios de aceita o Nesta atividade o adquirente deve primeiro estabelecer um procedimento para selecionar o fornecedor incluindo crit rios de avalia o da proposta e de pondera o com rela o ader ncia aos requisitos de aquisi o levantados na fase de inicia o do processo Feito isso ele pode ent o selecionar um fornecedor com base na avalia o das propostas recebidas dos fornecedores das capacidades de cada fornecedor e de outros fatores que tamb m precisam ser considerados Para a fase de adapta o do processo ao projeto o adquirente pode envolver outras partes al m dos fornecedores potenciais antes do fechamento do
140. temas manuais existentes 161 a seqii ncia de execu o fluxo do sistema est precisa 70 162 de procedimentos de corre o de erros est o funcionando 163 0 sistema reinicia os procedimentos de modo satisfat rio 164 procedimentos de recupera o de arquivos satisfat rios 165 avalia o de aceitabilidade de acordo com padr es predeterminados 166 servi os oferecidos pelo sistema de acordo com as defini es originais dos requisitos do usu rio 167 modifica es nos requisitos do usu rio a partir da defini o original 168 teste do sistema julgado completo aprova o dos resultados pelo usu rio 169 0s padr es podem ser revisados separadamente em conformidade com as especifica es 170 c digo e documenta o podem s vezes ser revisados separadamente 171 a efici ncia pode ser revisada separadamente a partir de outras especifica es 172 a interface com o usu rio pode ser revisada separadamente 173 a manutenibilidade pode ser revisada separadamente da conformidade quanto s especifica es funcionais 174 a conveni ncia de opera o pode constituir um item separado de revis o VERIFICA O DO PROJETO 1 o projeto est correto e consistente com os requisitos e rastre vel aos mesmos 2 o projeto implementa uma segii ncia adequada de eventos entradas resultados interfaces fluxo l gico aloca o de tempo e de or amentos e defini o isolamento e recupera o de erro o
141. tiva das atividades de verifica o o estabelecimento de modelos de erros que captem os erros t picos os riscos associados a fregqii ncia de ocorr ncia e outros aspectos de maneira que a experi ncia e o conhecimento de desenvolvimento de software de uma equipe ou empresa sejam utilizados para o planejamento das futuras atividades de desenvolvimento Se essa perspectiva n o for armazenada em uma base hist rica e analisada posteriormente para propiciar a evolu o do processo de desenvolvimento a equipe ou empresa estar fadada inefici ncia e repeti o de erros pr vios z De acordo com Mills 1994 verifica o da qualidade a avalia o cont nua da situa o de procedimentos m todos condi es produtos processos e servi os e a an lise dos registros para assegurar que os requisitos da qualidade ser o satisfeitos Freedman 1993 cita que a verifica o contribui significativamente para redu o do n mero de defeitos contidos em programas Como tende a ser muito demorada e cara a corre o de programas contendo defeitos decorrentes de erros de especifica o arquitetura ou projeto a verifica o contribui ainda para a acelera o do desenvolvimento e para a redu o do custo total do desenvolvimento do programa Durante a verifica o o artefato que um subproduto do desenvolvimento deve ser examinado segundo uma lista de quesitos check list Esta lista depende do tipo de artefato da lingua
142. tivas configura es a que se destina 191 existe um equil brio correto entre a educa o humana e a da m quina 192 05 recursos educacionais constituem um ambiente adequado para o m todo de apresenta o 193 0 equipamento consistentemente confi vel e consistentemente dispon vel 194 0s equipamentos suplementares e os materiais encontram se confi vel e consistentemente dispon veis por exemplo terminais impressoras papel manuais 195 foram alocados tempo suficiente e recursos necess rios para exerc cios e sess es de problemas 196 foi alocado tempo suficiente para problemas e exerc cios de programa o 5 10 11 12 13 14 15 16 17 18 19 96 VERIFICA O DA DOCUMENTA O a documenta o est adequada completa e consistente a prepara o da documenta o est oportuna a ger ncia de configura o dos documentos segue procedimentos especificados todos os projetos produzem e documentam seus planos incluindo proje es do tamanho do produto estimativa de recursos pessoal prazos e pontos de controle revis es gerenciais peri dicas mensais ou trimestrais s o conduzidas para acompanhar o desempenho do projeto em termos de tamanho pessoal cronogramas e pontos de controle mecanismos s o estabelecidos para monitorar e controlar as mudan as no requerimentos existe um processo organizacional documentado para checar o software e seus componentes contra
143. tware tamb m tem sido degradada por n o se ter dispon veis informa es corretas sobre todas as possibilidades oferecidas pelo produto de software desenvolvido Por essas raz es a elabora o de uma documenta o t cnica de qualidade relacionada ao processo de software t o importante quanto qualidade do software em 51 Segundo Inthurn 2001 fornecer documentos completos e consistentes durante todo o ciclo de vida de desenvolvimento do software aumenta as chances de se obter um produto final de alta qualidade Al m disso checar as falhas dos documentos do software antes de continuar com a pr xima fase do desenvolvimento contribui par a qualidade global do software Segundo Freedman 1993 a documenta o certamente uma forma importante que o sistema assume Embora ela possa incluir toda ou parte das especifica es projeto e c digo essas partes n o incluir o geralmente o conjunto completo de documenta o Consegiientemente partes adicionais dever o ser submetidas s revis es de documenta o Al m disso pode ser interessante em alguns casos revisar especifica es projetos ou c digos em termos de sua adequa o documenta o do sistema em contraste com sua adequa o documenta o funcional durante o desenvolvimento 16 Diferentes tipos de documenta o podem ser revisados em diferentes tempos ou mesmo em diversas pocas com objetivos diferentes mas toda a documenta o deve ser re
144. umenta o dos padr es e m todos do processo s o monitorados e revistos as ferramentas e m todos de desenvolvimento de cada projeto s o mantidos sob controle da ger ncia de configura o de software as defini es e padr es do processo para cada projeto s o mantidas sob controle da ger ncia de configura o de software procedimentos formais s o estabelecidos para a subcontrata o de recursos mecanismos e recursos s o estabelecidos para o acompanhamento do desempenho dos subcontratados a rea de garantia da qualidade da empresa monitora a garantia da qualidade do subcontratado padr es documentados s o produzidos para o processo de software como um todo abrangendo tamb m registros de custos m todos de teste e relat rios sobre qualidade dos produtos guias de estilo para desenvolvimento s o utilizados por toda a empresa e para qualquer projeto procedimentos documentados s o estabelecidos para produzir e aprovar padr es de processo e produto as defini es do processo s o adaptadas para dinamicamente atender as conting ncias de cada projeto m todos documentados s o desenvolvidos para o projeto codifica o inspe o e teste m todos s o estabelecidos para identificar e relacionar todos os itens referentes ao projeto e codifica o desde os requisitos at o teste medi es s o feitas sobre os erros encontrados e os custos incorridos pela atividade do processo mecanismos e responsabilidad
145. untas correspondente a atividades que ser o configuradas conforme o avaliador necessitar para a verifica o do processo 6 momento de registrar resposta neste momento o avaliador realizar a verifica o do processo atrav s do checklist para cada atividade escolhida 7 cliente recebe rela o das perguntas selecionadas o cliente do sistema poder emitir relat rios apresentando os resultados obtidos sobre as perguntas da atividade do contrato processo requisitos projeto c digo integra o e documenta o 8 cliente recebe rela o das perguntas por tipo de resposta o cliente do sistema poder emitir um relat rio sobre as perguntas atendidas versos n o atendidas das atividades do processo 4 3 DIAGRAMA DE CONTEXTO O Diagrama de Contexto estabelece os limites entre o sistema e o seu ambiente utilizado para se obter uma vis o macro do software comunica es entre o sistema o ambiente e as entidades com as quais se comunica Na figura 2 apresentado o Diagrama de Contexto do software As ferramentas utilizadas para a especifica o do software foi a ferramenta CASE Power Designer 6 1 da Sybase Inc 31 FIGURA 2 DIAGRAMA DE CONTEXTO Cliente Organiza o Organiza o Plano de Verifica o Rela o das perguntas selecionadas pa Sistema de apoio ao proceso de verifica o de Rela o das perguntas por tipo de resposta
146. uporte e com outros componentes de sistema s o planejados e executados testes de integra o do software e respectivas documenta o de acordo com o processo de software definido do projeto as restri es de projeto foram estabelecidas para cada elemento as melhores alternativas foram selecionadas a solu o tecnologicamente vi vel foi estabelecido um mecanismo de valida o e verifica o para o sistema h consist ncia entre todos os elementos do sistema uma pol tica emitida requerendo que cada grupo de desenvolvimento demonstre um padr o crescente de produtividade uma pol tica da empresa requer que cada grupo de desenvolvimento utilize os m todos e ferramentas oficiais estabelecidos o ponto focal da organiza o o desenvolvimento a introdu o e o apoio reutiliza o de componentes revis es gerenciais peri dicas s o realizadas para avaliar o desempenho da produtividade meios s o estabelecidos para assegurar que o processo de software e as a es de melhorias sejam objetivamente avaliadas reconhecidas e recompensadas 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 88 cursos padr es s o oferecidos para justifica o econ mica projetos avan ados m todos de reutiliza o e m todos de preven o de erros planos de melhoria do processo s o produzidos para cada projeto planos de melhoria de
147. usu rios possuem o mesmo hardware 162 outros usu rios podem se contatados 163 pode ser dada uma demonstra o 164 pode ser dado um julgamento 165 h uma documenta o dispon vel 166 se o fornecedor abandonar o ramo o c digo fonte se mant m dispon vel 167 algum elemento do sistema entra em conflito com a pr tica da instala o 168 ter interface com outro software 169 antes de desempenhar as atividades de aceita o o fornecedor deve assistir o comprador na identifica o da programa o da aceita o procedimentos para avalia o o ambiente de hardware software e recursos necess rios e os crit rios de aceita o a serem utilizados 170 a uma determina o do n mero de c pias do software a serem entregues 171 a estipula o da documenta o requerida 172 quest es relativas a direitos autorais 173 existe um per odo de obriga o do fornecedor suprir c pias 174 as c pias a serem entregues s o verificadas quanto a sua completeza 175 0s pap is do fornecedor e comprador est o plenamente estabelecidos quanto instala o 95 176 0 fornecedor desenvolve um plano de ger ncia de configura o que compreende organiza o e responsabilidades correspondentes relativas ger ncia de configura o atividade a serem desempenhadas ferramentas t cnicas e metodologias a serem usadas e os est gio no qual os itens de software devem entrar sob controle da ger ncia de configura o
148. valia o da facilidade de uso do sistema de computador 115 0 n vel de detalhe necess rio para a pr tica dos procedimentos do usu rio s o empregados para uso do sistema de computador 116 existem modelos ou descri es de todas as outras interfaces do sistema de computador 117 existe um modelo funcional de alto n vel do sistema proposto 118 tal modelo acompanhado de uma descri o operacional 119 0 modelo acompanhado de uma explica o dos procedimentos de testes casos de testes resultados de testes e an lise de testes utilizados para garantir precis o do modelo 120 tal modelo acompanhado de uma avalia o do modelo quanto aos requisitos para garantir que estes sejam satisfeitos o projeto preliminar n o fornece resultados detalhados que permitam uma an lise qualitativa e quantitativa detalhada 121 as principais alternativas de implementa o e suas avalia es encontram se presentes no documento 122 0 modelo preciso e n o amb guo que identifique m dulos conjuntos de imputs e outputs m dulos e crit rios para execu o de cada sequ ncia operacional no modelo 123 existe uma avalia o do modelo que garanta que os requisitos ser o satisfeitos algumas das qualidade que tal avalia o deve conter s o desempenho requisitos de armazenamento qualidade dos resultados facilidade de uso manutenibilidade adaptabilidade generalidade excel ncia t cnica simplicidade flexibilidade legibil
149. verifica o est no pr ximo registro que o de resumos a soma de verifica o est no primeiro registro que se segue ou podem ser v rios registros de qualquer forma o campo ser setado em 2000 que o maior valor esperado nesta aplica o 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 70 73 74 75 76 77 78 79 2 o total de controle extra do a partir do registro ao final do arquivo o total de controle extra do a partir do registro mais recente o total de controle extra do a partir do registro anterior o total de controle extra do a partir do registro que est sendo processado o total de controle extra do a partir do registro com data mais recente o c digo de retorno pode conter um inteiro ou brancos o c digo de retorno pode conter inteiro ou brancos mas tamb m pode conter qualquer outra coisa n o definida aqui somente d gitos podem estar na lista de n mero de pe as a nica lista na qual os d gitos aparecem a lista de n meros das pe as a segii ncia termina num flag num fim de arquivos ou em ambos quando a seq ncia termina uma e somente uma destas condi es sra v lida flag ou fim de arquivo todos os clientes t m o mesmo valor em seu campo de controle todos os campos de controle de cliente t m o mesmo formato um campo usado para todos os clientes
150. visada pelo menos uma vez Por exemplo os coment rios dentro do c digo devem ser revisados mediada que o c digo revisado antes de sua inclus o no sistema Os coment rios s o considerados parte do c digo propriamente mas s o tamb m claramente uma documenta o Na verdade o c digo em si um tipo de documenta o e em alguns casos revisado separadamente quanto sua qualidade como documento Conforme Duarte 2000 manter padr es na documenta o a base para a garantia de qualidade dos documentos Documentos produzidos de acordo com padr es apropriados possuem qualidade estrutura e aspectos consistentes 17 3 NORMAS E MODELOS DE QUALIDADE Este cap tulo trata das outras normas da futura norma ISO IEC 15504 SPICE da norma ISO 9000 3 e do modelo CMMI a norma ISO IEC 12207 j foi comentada no cap tulo 2 Ser apresentada uma breve descri o de cada alternativa assim como uma explica o do processo de verifica o previsto em cada alternativa 3 1 NORMA ISO IEC 15504 De acordo com Iahn 1999 a futura norma ISO IEC 15504 conhecida atualmente como projeto SPICE Software Process Improvement and Capability dEtermination uma norma em elabora o formada pela ISO Intenational Organization for Standardization e pela IEC International Electrotechnical Comission e constitui se de um padr o para a avalia o do processo de software visando determinar a capacita o de uma organiza
151. volvido no ambiente de programa o Visual Delphi 5 0 da Borland Para o armazenamento dos dados foi utilizado o Paradox A seguir ser demonstrado passo a passo o uso do software 5 1 OPERACIONALIDADE DA IMPLEMENTA O Ao executar o aplicativo ser apresentada a tela principal do software que composto de cinco itens no menu principal que dar acesso aos demais recursos do mesmo tais como cadastro configura o das perguntas plano de verifica o relat rios e ajuda conforme a figura 8 FIGURA 8 TELA INICIAL DO SOFTWARE DE APOIO AO PROCESSO DE VERIFICA O DE SOFTWARE Sistema de Apoio ao Processo de Verifica o de Software Cadastro Configura o das perguntas Plano de verifica o Relat rios Ajuda FURB Universidade Regional de Blumenau Trabalho de Conclus o de Curso Ci ncias da Computa o Software de Apoio ao Processo de Verifica o de Software segundo a Norma ISO IEC 12207 Aluno Itabora Cordoni Ebertz Orientador Prof Everaldo Artur Grahl Para iniciar o processo de verifica o em si primeiramente todos os cadastros devem ser preenchidos Os cadastros existentes s o demonstrados a seguir conforme figuras 9 10 11 e 12 A figura 9 demonstra a tela de Cadastro da Organiza o onde s o informados os dados pessoais e jur dicos das organiza es Estas organiza es aqui cadastradas ser o utilizadas no registro do Plano de Verifica o 39 FIGURA 9 TELA DE CADASTRO DA ORGA

da Monografia - Departamento de Sistemas e Computação

Contents

Download Pdf Manuals

Related Search

Related Contents

da Monografia - Departamento de Sistemas e Computa&ccedil;&atilde;o

Contents

Download Pdf Manuals

Related Search

Related Contents

da Monografia - Departamento de Sistemas e Computação