Universidade Federal do Amazonas Departamento de Cincia da Computao

Pesquisa sobre normas ISO e padres IEEE relacionados Engenharia de Software

Participantes: dipo Maciel 20902181 Diovane Monteiro - 20902238

INTRODUO
No estudo da Engenharia de Software a falta de adoo de mtodos, ferramentas e procedimentos no desenvolvimento de software contribui diretamente para a difcil relao de entendimento entre o usurio com o desenvolvedor. Adotar uma norma permite padronizar os processos de desenvolvimento de software, aumentando a aderncia a uma ferramenta de apoio na modelagem do software. Essa pesquisa visa apresentar uma breve explicao, bem como conceitos e diretrizes de algumas das principais normas e padres de qualidade relacionadas Engenharia de Software.

ISO 900-3 - Aplicao da norma ISO 9001 para o processo de desenvolvimento de software
Em junho de 1993 foi criado o guia ISO 9000-3 com diretrizes para aplicao da ISO 9001 ao desenvolvimento, fornecimento e manuteno de software. Para cada item da ISO 9001 existe um correspondente na ISO 9000-3 que o detalha e o adpata ao software. De fato, a ISO 9000-3 um guia para a aplicao da ISO 9001 para o desenvolvimento, fornecimento e manuteno de software. As diretrizes propostas na ISO 9000-3 cobrem questes como: Entendimento dos requisitos funcionais entre contratante e contratado Uso de metodologias consistentes para o desenvolvimento de software Gerenciamento de projeto desde a concepo at a manuteno. Uma das limitaes da ISO 9000-3 que ela no trata de aspectos como a melhoria contnua do processo de software (SPI Software Process Improvement) como faz o modelo CMM ou a norma SPICE. Desta forma, o que a ISO 9000-3 traz apenas quais processos a organizao deve ter e manter, mas no trata e orienta quanto aos passos que devem ser seguidos para chegar a desenvolver estes processos - nem de como aperfeiolos. A norma ISO 9000-3 tem sofrido algumas atualizaes com o passar dos anos. A primeira edio desta norma surgiu em 1991. Uma atualizao foi lanada em 1994 e outra, a mais recente, em 1997. A norma brasileira equivalente ISO 9000-3 a NBR-ISO 9000-3 de 1993 baseada na edio de 1991 e, portanto, um pouco desatualizada. A primeira edio da ISO 9000-3 (e a NBR-ISO 9000-3 atual) agrupava as diretrizes em trs partes principais: 1. Estrutura: Descreve aspectos organizacionais, relacionados ao sistema de qualidade. 2. Atividades do ciclo de vida: Descreve as atividades de desenvolvimento de software. 3. Atividades de suporte: Descreve as atividades que apiam as atividades do ciclo de vida. Alm disto, a ISO 9000-3 organizava e dava nomes s diretrizes diferentes dos utilizados na ISO 9001. Neste caso era necessrio uma tabela de mapeamento entre as diretrizes da ISO 9000-3 e da ISO 9001 causando uma srie de transtornos. Esta estrutura, nomenclatura e arranjo particular das diretrizes foram abandonados nas edies mais recentes. Esta segue exatamente a estrutura da ISO 9001 e suas diretrizes tm o mesmo nome. A ISO 9001 baseia-se em 20 diretrizes que englobam vrios aspectos da garantia da qualidade:

Responsabilidades de gerncia Requer da gerncia que a poltica de qualidade seja definida, documentada, comunicada, implementada e mantida. Alm disto, requer que se designe um representante da administrao para coordenar e controlar o sistema da qualidade. Requisitos do sistema de qualidade O sistema de qualidade deve ser documentado na forma de uma manual e implementado. Desenvolva um plano de qualidade sempre que voc precisar controlar a qualidade de um projeto, de um produto, ou de um contrato especfico. Seu plano da qualidade deve explicar como voc pretende ajustar seu sistema de qualidade de modo que se aplique a seu projeto, produto, ou contrato especfico. Desenvolva planos de qualidade e procedimentos detalhados para controlar a gerncia de configurao, a verificao do produto, a validao do produto, a no conformidade do produto, e aes corretivas. Reviso dos requisitos de contrato Os requisitos contratuais devem estar completos e bem definidos. A organizao deve assegurar que tenha todos os recursos necessrios para atender s exigncias contratuais. Deve permitir a anlise crtica do contrato. Requisitos de projeto do produto Todas as atividades referentes projetos (planejamento, mtodos para reviso, mudanas, verificaes,etc.) devem ser documentadas. Desenvolver e documentar procedimentos para controlar o processo da fase de projeto e desenvolvimento do produto. Estes procedimentos devem assegurar que todos os requisitos do produto so cumpridos. Controle de documentos e dados Requer procedimentos para controlar a gerao, distribuio, mudana e reviso em todos os documentos. Requisitos de aquisio Deve-se garantir que os produtos e servios adquiridos atendam s exigncias especificadas. Deve haver procedimentos para a avaliao de fornecedores Produtos fornecidos por clientes ou fornecedores Deve-se assegurar que estes produtos sejam adequados ao uso e devidamente mantidos,

Identificao e controle de produtos Requer a identificao do produto por item, srie ou lote durante todos os estgios da produo, entrega e instalao. O produto deve poder ser rastreado atravs desta identificao. Processo de controle de requisitos Requer que todas as fases de processamento de um produto sejam controladas (por procedimentos, normas, etc.) e documentados. Testes e inspees dos produtos Requer que as matrias-primas sejam inspecionadas (por procedimentos documentados) antes de sua utilizao. Controle dos equipamentos de inspeo Requer procedimentos para a calibrao/aferio, o controle e a manuteno destes equipamentos. Inspeo e testes dos produtos Deve haver, no produto, algum indicador que demonstre por quais inspees e ensaios ele passou e se foi aprovado ou no. Controle de no conformidade Requer procedimentos para assegurar que o produto no conforme aos requisitos especificados impedido de ser utilizado inadvertidamente. Desenvolva procedimentos que previna o uso inapropriado do seu produto. Tambm assegure que todos so notificados quando seu produto no se adequa a um requisito especfico. Aes corretivas e preventivas Exige a investigao e anlise das causas de produtos no-conformes e adoo de medidas para prevenir a reincidncia destas no-conformidades. Manuseio, armazenamento e expedio Requer a existncia de procedimentos para o manuseio, armazenamento, embalagem e expedio dos produtos. Controle dos registros da qualidade Devem ser mantidos registros da qualidade ao longo de todo o processo de produo. Estes devem ser devidamente arquivados e protegidos contra danos e extravios.

Requisitos da auditoria interna da qualidade Deve-se implantar um sistema de avaliao do programa da qualidade. Desenvolver procedimentos de auditorias internas da qualidade. Requisitos de treinamento Devem ser estabelecidos programas de treinamento para manter, atualizar e ampliar os conhecimentos e as habilidades dos funcionrios. Requisitos de Manuteno Requer procedimentos para garantir a assistncia clientes. Desenvolva e documente procedimentos de manuteno da qualidade. Tcnicas estatsticas Devem ser utilizadas tcnicas estatsticas adequadas para verificar a aceitabilidade da capacidade do processo e as caractersticas do produto.

ISO 14598 Avaliao do Produto de Software

O padro ISO/IEC 14598 fornece mtodos para medida, coleta e avaliao da qualidade de produtos de software. Entretanto, a norma no descreve mtodos para avaliar o processo de produo de software, nem o para predio de custos de produto. A norma define processos de avaliao para:

Desenvolvedores: organizaes que esto planejando o desenvolvimento de um novo produto de software. Compradores: organizaes que esto planejando a compra de um pacote de software que ser desenvolvido ou j pronto no mercado Avaliadores de software: organizaes que executam avaliaes independentes de produtos de software disponveis no mercado.

A inteno dessa norma propor uma padronizao nesses mdulos de avaliao para que eles possam ser reusveis. Criando assim, bibliotecas desses mdulos. Fornece, tambm, guias para documentao dos mdulos e suporte ao desenvolvimento desses. O modo pelo qual as informaes so manipuladas ou quais informaes so necessrias na realizao da avaliao ilustram o processo de documentao dos mdulos de avaliao.

No ter certificao pode acarretar desvantagem competitiva. Qualidade custo/benefcio: Todas as empresas sabem que corrigir defeitos aps o desenvolvimento do software mais dispendioso do que corrigi-los depois.

Esta nova complementa a ISO/IEC 9126 e permite uma Avaliao Padronizada das Caractersticas de Qualidade de um Software. importante notar que, ao contrrio da ISO 9126, a ISO 14598 desce a detalhes mnimos, incluindo modelos para relatrios de avaliao, tcnicas para medio das caractersticas, documentos necessrios para avaliao e fases da avaliao. A ISO 14598 dividida em 6 normas:
1. 14598-1: Viso Geral 2. 3. 4. 5. 6.

Ensina a utilizar as outras normas do grupo 14598-2: Planejamento e Gerenciamento Sobre como fazer uma avaliao, de forma geral 14598-3: Guia para Desenvolvedores Como avaliar sob o ponto do vista de quem desenvolve 14598-4: Guia para Aquisio Como avaliar sob o ponto de vista de quem vai adquirir 14598-5: Guia para Avaliao Como avaliar sob o ponto de vista de quem certifica 14598-6: Mdulos de Avaliao Detalhes sobre como avaliar cada caracterstica

ISO 12119 Qualidade de Pacotes de Software

Esta Norma foi publicada em 1994 e trata da Avaliao de Pacotes de Software, tambm conhecidos como "Softwares de Prateleira". Alm de estabelecer os Requisitos de Qualidade para esse tipo de Software, ela tambm destaca a necessidade de Instrues para Teste desses Pacotes, considerando os requisitos abaixo. Esta Norma divide-se em itens, da seguinte forma: Item Descrio 1. Escopo 2. Definies 3. Requisitos de Qualidade 3.1. Descrio do Produto Descreve o Produto (Pacote de Software), de forma a ajudar o comprador em potencial, servindo como base para Testes; Cada declarao deve ser correta e testvel; Deve incluir declaraes sobre

3.2 Documentao do Usurio 3.3 Programas e Dados

funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade. Deve ser completa, correta, consistente, fcil de entender e capaz de dar uma viso geral do produto. Descreve em detalhes cada uma das funes do software, incluindo declaraes sobre funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade. Lista de itens necessrios ao teste, incluindo documentos includos no pacote, componentes do sistema e material de treinamento. Instrues detalhadas sobre os procedimentos de teste, inclusive instalao e execuo de cada uma das funes descritas. Informaes sobre como os testes foram realizados, de tal forma a permitir uma reproduo destes testes. Deve incluir parmetros utilizados, resultados associados, falhas ocorridas e at a identidade do pessoal envolvido. Relatrio incluindo: identificao do produto, hardware e software utilizado, documentos utilizados, resultados dos testes, lista de no conformidade com os requisitos, lista de no conformidade com as recomendaes, datas, etc.

4. Instrues para Teste 4.1 Pr-requisitos de Teste

4.2 Atividade de Teste

4.3 Registro de Teste

4.4 Relatrio de Teste

Um dos grandes mritos desta Norma encontra-se na profundidade com que descrita cada uma das Caractersticas e Sub-caractersticas mencionadas na Norma 9126. Ela inclui detalhes que devem estar presentes no Produto de Software, tais como:

Documentao do Usurio de fcil compreenso; Um Sumrio e um ndice Remissivo na Documentao do Usurio; Presena de um Manual de Instalao com instrues detalhadas; Possibilidade de verificar se uma instalao foi bem sucedida; Especificao de Valores Limites para todos os Dados de Entrada, que devero ser testados; Operao Normal mesmo quando os dados informados esto fora dos limites especificados; Consistncia de Vocabulrio entre as Mensagens e a Documentao; Funo de Auxlio com recursos de Hipertexto; Mensagens de Erro com informaes necessrias para Soluo da Situao de Erro;

Diferenciao dos Tipos de Mensagem: confirmao, consulta, advertncia e erro; Clareza nos Formatos das Telas de Entrada e Relatrios; Capacidade de reverter funes de efeito drstico; Alertas Claros para as conseqncias de uma determinada confirmao; Identificao dos arquivos utilizados pelo programa; Identificao da funo do programa que est sendo executada no momento; Capacidade de interromper um processamento demorado.

Outras Caractersticas importantes so: a nfase nos Testes e nos Modelos de Relatrios includos. Tudo isso facilita grandemente o trabalho do avaliador.

IEEE 829 Documentao

Ao longo dos anos uma srie de tipos de documentos foi criada para permitir o controle de testes. Aplicam-se a testes de software de todos os tipos de testes de componentes por meio de liberao de testes. Toda organizao desenvolve estes documentos e d-lhes nomes diferentes e, em alguns casos, confunde o seu propsito. Para fornecer um conjunto comum de documentos padronizados do IEEE desenvolveu o padro 829 de Documentao de Teste de Software para qualquer tipo de teste de software, incluindo o teste de aceitao do usurio. Este artigo descreve cada um dos tipos de documento neste padro e descreve como eles funcionam juntos. Os tipos de documentos H oito tipos de documentos no padro IEEE 829, que pode ser utilizado em trs fases distintas de testes de software:
1. Elaborao das provas

Plano de teste: Plano como o teste vai prosseguir. Especificao do Projeto de teste: Decida o que precisa ser testado. Especificao de Caso de teste: Criar os testes a serem executados. Procedimento de Teste: Descrever como os testes so executados. Relatrio de teste item Transmisso: Especifique os itens liberados para testes.

2. Execuo dos testes

Teste de Log: Anote os detalhes dos testes em ordem de tempo. Relatrio de Teste de Incidentes: Registar os detalhes de eventos que precisam ser investigadas.

3. Concluso do Teste

Relatrio de Teste Resumo: Resumir e avaliar testes.

Documentao para a Elaborao de Testes

A preparao para testes a parte mais importante de qualquer projeto de teste de software e facilmente responsvel pela maior parte do trabalho de papel. O objetivo nesta fase preparar um conjunto eficaz e eficiente de testes, e criar o ambiente para eles a correr dentro
IEEE 829 - Plano de Teste

O Plano de Teste o documento fundamental em torno do qual todos os projetos de teste de software girar. Ela descreve:

o que tem que ser feito, ao que padro de qualidade, com o recurso, o que escala de tempo, e descreve os riscos e como eles poderiam ser superadas.

IEEE 829 - Teste de Especificao do Projeto

Criando o design de teste o primeiro passo para desenvolver os testes para um projeto de teste de software. Ele registra o que precisa ser testado, e derivada a partir dos documentos que entram em fase de testes, tais como requisitos e designs. Ele registra que caractersticas de um item de teste devem ser testados, e como um teste bem sucedido desses recursos seria reconhecido. Como um exemplo, vamos usar um projeto de facturao a partir do qual os requisitos de teste a seguir podem ser definidas:

Um projeto de lei normal pode ser produzido. A conta final pode ser produzida. O desconto de volume devidamente calculado.

O design de teste no registra os valores a serem inseridos em um teste, mas descreve os requisitos para a definio desses valores. Este documento muito valioso, mas freqentemente ausente em muitos projetos. A razo que as pessoas comeam a escrever casos de teste antes de terem decidido o que eles esto indo para teste.
IEEE 829 - Especificao de Casos de Teste

Os casos de teste so produzidos quando o projeto de teste concluda. Especificar casos de teste para cada requisito de teste:

A exata valores de entrada que ser de entrada e os valores de todos os dados de p o que necessrio, A exata valores de sada e as mudanas de valor do estado interno do sistema que so esperados,

E quaisquer medidas especiais para a criao de testes.

Definio dos valores esperados muito importante, pois s fazendo isso pode ser notado discrepncias. No entanto, em alguns projetos que no esto definidos o que resulta em um conjunto muito m qualidade de casos de teste. Uma caracterstica do Design de Teste pode ser testado em mais de um caso de teste, e um caso de teste pode testar mais de um recurso. O objectivo que um conjunto de casos de teste para testar cada recurso do Projeto de Teste pelo menos uma vez. Tomando o exemplo do projeto Billing todos os trs requisitos podem ser testados usando dois casos de teste:

O primeiro caso de teste pode testar tanto que um projeto de lei normal produzido e que um desconto de volume devidamente calculado. Um segundo caso de teste pode verificar se um projeto final produzido e um desconto de volume calculado.

IEEE 829 - Especificao de Procedimento de Teste

Os procedimentos de teste so desenvolvidos a partir de ambos o Teste de Desenho e Especificao de Casos de Teste. O documento descreve como o testador fisicamente executar o teste, o set-up fsico exigido, e as etapas do procedimento que precisam ser seguidas. A norma define dez passos procedimento que pode ser aplicado ao executar um teste.
IEEE 829 - Relatrio de Teste artigo Transmisso

Este documento curiosamente chamado no derivado do plano de teste, mas a entrega de documentos do estgio anterior de desenvolvimento. No teste de aceitao do usurio esta pode ser a concluso dos testes de sistema. Ele descreve os itens que esto sendo entregues para testes, onde encontr-los, o que h de novo sobre eles, e d aprovao para a sua libertao. A importncia do documento fornecer aos testadores uma garantia de que os itens esto aptos a serem testados e d um mandato claro para iniciar os testes. No comear a testar sem receber um!

Documentao para execuo dos testes

Quando os testes foram desenvolvidos em seguida, eles podem ser executados. O cronograma do que casos de teste so executados e quando, definida no Plano de Teste. Os resultados do teste so registrados no Log de Teste, e em relatrios de incidentes de teste.
IEEE 829 - Log de Teste

O Log de Teste registra os detalhes do que casos de teste foram executados, a ordem de sua execuo, e os resultados do teste. Os resultados so o teste passou, o que significa que os resultados reais e esperadas eram idnticos, ou ele falhou e que havia uma discrepncia. Se houver uma discrepncia de um ou mais relatrios de incidentes de teste so criados ou atualizados, e suas identidades registradas no Log de Teste.

O Log de Teste importante, pois permite que o progresso dos testes a serem verificados, bem como fornecendo informaes valiosas para descobrir o que causou um incidente. Se um incidente uma falha de codificao, a falha pode ter ocorrido no no caso de teste que falhou, mas em um que foi executado anteriormente. Assim, a seqncia dos testes permite que a culpa de ser encontrado.
IEEE 829-Relatrio de Incidente de Teste

Este documento deliberadamente nomeado como um relatrio de incidente, e no reportar uma falha. A razo que uma discrepncia entre os resultados esperados e reais pode ocorrer por uma srie de outras razes que no uma falha no sistema. Estes incluem os resultados esperados estar errado, o teste est sendo executado de forma errada, ou inconsistncia nos requisitos que significa que mais de uma interpretao poderia ser feita. O relatrio composto de todos os detalhes do incidente, como os resultados reais e esperados, quando falhou, e quaisquer provas que iro ajudar na sua resoluo. O relatrio tambm incluir, se possvel, uma avaliao do impacto sobre testes de um incidente. A relao entre o Log de Teste e Relatrio de Incidente de teste no 00:59. Um teste no pode levantar mais de um incidente, e, ao mesmo tempo um incidente pode ocorrer em mais de uma falha no teste. Tomando o exemplo do projeto de faturamento, se ambos os casos de teste falhou completamente de trs Relatrios de Incidentes de Teste seria levantada:

A primeira seria por falta de produzir um projeto de lei normal, A segunda seria para o fracasso para produzir um projeto de lei final, O terceiro para a falha para calcular o desconto por volume, tanto para o normal e o projeto de lei final.

importante separar incidentes pelos recursos que esto sendo testados, de modo a ter uma boa idia da qualidade do sistema e permitir que o progresso na fixao de falhas a serem verificados. Um documento til derivados do Relatrio de Incidente de Teste um registro de incidentes de teste para resumir os incidentes e os status. Este no um documento IEEE 829 como todos os valores que podem ser derivadas de relatrios de incidentes de teste.

Documentao para a realizao de anlises

Eventualmente os testes sero concludos de acordo com os critrios especificados no Plano de Teste. Isto , quando o sucesso ou o fracasso do sistema decidido com base nos resultados. O resumo do teste registra essas informaes.
IEEE 829 - Resumo do Teste

O Resumo do Teste rene todas as informaes pertinentes sobre os testes, incluindo uma avaliao sobre quo bem o teste foi feito, o nmero de incidentes levantados e em circulao e, crucialmente, uma avaliao sobre a qualidade do sistema. Tambm registrados para uso no planejamento do projeto futuro detalhes do que foi feito, e quanto tempo levou.

Este documento importante para decidir se a qualidade do sistema bom o suficiente para permitir que ele v para um outro estgio.

Utilizao da norma
A norma genrica para cobrir todos os tipos de testes. Como resultado, permite os documentos a serem adaptadas a cada situao. Isso significa usar a estrutura bsica como dado, mas outros documentos podem ser adicionados a ela, as sees podem ser adicionados a cada documento, e descries mais pode ser escrito. Alm disso, alguns contedos podem ser referenciados em outro documento. Usando o padro significa que qualquer pessoa ingressar em um projeto vai saber o que os documentos esto sendo usados, e para que finalidade, permitindo que eles se tornem produtivos rapidamente.

Atividades VV&T e a Norma IEEE 1012

A qualidade do software est diretamente relacionada satisfao do cliente, sendo assim, as empresas esto percebendo a importncia em produzir software com qualidade. Neste contexto, o teste de software um elemento crtico na garantia da qualidade de software. Nos testes de software, um importante objetivo o de verificar se a aplicao satisfaz os requisitos solicitados pelo cliente. Sabe-se que um software pode conter defeitos, porm, se algum trecho do cdigo nunca for executado, ou se o cdigo no for exaustivamente executado, este defeito poder no aparecer. Os defeitos do software podem ser introduzidos na especificao, no projeto, na construo do cdigo, ou na documentao, isto , em qualquer ponto do ciclo de desenvolvimento ou manuteno do sistema (Pfleeger). A garantia de qualidade de software (SQA) composta por um conjunto de atividades tcnicas aplicadas durante todo o desenvolvimento do software. O objetivo garantir que o processo de desenvolvimento do software e o produto desenvolvido atinjam nveis de qualidade conforme especificado. Dentre essas atividades de garantia de qualidade de software esto as de VV&T (Verificao, Validao e Teste,) com o objetivo de minimizar a ocorrncia de erros a riscos associados. O processo VV&T determina que cada produto principal elaborado durante o ciclo de desenvolvimento do software seja avaliado, verificado, validado e testado em cada fase antes do prosseguimento do desenvolvimento para a fase seguinte, assegurando que os mesmos estejam completos e corretos, seguindo as exigncias de verificao e validao. Verificao um processo para se determinar se os produtos, (executveis ou no executveis) desenvolvidos em uma fase do ciclo de desenvolvimento do software,

cumprem as exigncias estabelecidas durante a fase precedente, e se os mtodos e processos aplicados durante o desenvolvimento estavam adequados. Validao o processo de averiguar se o software que est sendo desenvolvido satisfaz aos requisitos predeterminados pelo usurio (Maldonado). As atividades de VV&T realizadas durante o desenvolvimento do software abrangem atividades de verificao esttica e dinmica, as quais podem ser realizadas de forma manual ou automtica. A verificao esttica no envolve a execuo do software e tem como atividades, anlise de produtos desenvolvidos, construo de prottipos e reviso dos documentos, que devem ocorrer no final de cada fase do ciclo de vida do projeto do software. (Pressman). A verificao dinmica envolve a execuo do cdigo do software com a finalidade de detectar defeitos ou erros. O teste de software pertence s atividades de anlise dinmica do software, sendo que na execuo dessa atividade pode-se utilizar ferramenta de automao de teste. A Norma IEEE 1012- Software Verification and Validation trata da padronizao dos processos de verificao e validao de Software (Standard for Software Verification and Validation) durante o ciclo de vida de desenvolvimento do software, incluindo processo de aquisio, desenvolvimento, operao e manuteno de sistemas (Institute of Eletrical and Eletronics Engineers). O objetivo desta norma estabelecer procedimentos V&V, atividades e tarefas de apoio ao processo de ciclo de vida do software, a fim de garantir que os requisitos do sistema estejam corretos, completos, consistentes e testados, proporcionando a deteco e correo de defeitos nas fases iniciais do projeto, diminuindo o risco operacional do projeto. Alm disso, tem o propsito de avaliar se o sistema pode ser utilizado em uma situao operacional, como tambm, verificar se os produtos de desenvolvimento em determinada atividade esto de acordo com as exigncias dessa fase, e se o software satisfaz as necessidades do usurio. Os processos V&V incluem atividades de anlise, reviso, inspeo, avaliao e teste de software avaliando o software no contexto do sistema, incluindo o ambiente operacional, interface e usurios. A norma possui trs princpios bsicos: 1) Prover um padro mnimo de requisitos que seja escopo do documento denominado Plano de Verificao e Validao do Software - SVVPs (Software Verification and Validation Plans); 2) Definir especificaes mnimas de atividades de verificao e validao (V&V), incluindo os requisitos de entrada e sada, as quais devem ser includas no documento SVVPs; e 3) Sugerir atividades de verificao e validao (V&V) opcionais para serem usadas sob medida no documento SVVPs, conforme os esforos V&V necessrios.

As atividades de V&V so estabelecidas durante o desenvolvimento do projeto, nas fases de requisitos, projeto, implementao, teste, instalao, operao e manuteno. Esta norma recomenda que alguns itens bsicos sejam definidos em cada fase do projeto, tais como: Atividades de Verificao e Validao, Critrios e mtodos, Entradas e Sadas, Cronograma, Recursos, Riscos, Regras e Responsabilidades. Para as atividades V&V associadas fase de teste, a norma recomenda a execuo de testes de unidade, integrao, sistema e aceitao, a documentao dos resultados obtidos e defeitos detectados na execuo dos testes.

O quadro abaixo ilustra algumas atividades/tarefas V&V

Atividade Gerncia de Software Tarefas Planejamento;Monitorao;Avaliao dos resultados da monitorao e o impacto dessas mudanas;Relatrios Gerenciais. Elaborao da documentao de especificao de Requisitos do Software;Anlise de Impacto; Anlise da Interface;Planejamento dos Testes de Sistema. Anlise de Impacto; Desenvolvimento do Projeto do SoftwareAnlise da Interface;Planejamento dos Testes de Unidade;Planejamento dos Testes de Integrao. Desenvolvimento do Cdigo;Anlise da Interface;Complementao dos Testes de Unidade. Execuo dos Testes de Unidade;Registros dos testes executados. Finalizao da preparao dos Testes de Integrao;Execuo dos Testes de Integrao; Registros dos testes executados. Complementeo da preparao dos Testes de Sistema;Execuo dos Testes de Sistema;Registros dos testes executados. Execuo dos Testes de Aceitao;Registros dos testes executados. Anlise de impacto das mudanas;Repetir as atividades de Gerncia de Software;Repetir das atividades tcnicas V&V anteriores.

Requisitos de Software

Projeto do Software

Codificao Teste de Unidade Teste de Integrao

Teste de Sistema

Teste de Aceitao Operao e Manuteno do Software

IEEE STD 1062

A ISO/IEC 12207 considerada de grande importncia para os processos internacionais de aquisio de software. uma norma apropriada para os processos de aquisio porque reconhece as distintas funes existentes para os compradores e fornecedores. Esta norma tem a inteno de ser usada pelas partes quando existir entre elas um acordo ou contrato que define o desenvolvimento, manuteno ou operao de um sistema de software. O processo de aquisio, definido pela ISO/IEC 12207, tem como propsito obter um produto ou servio que satisfaa a necessidade expressa pelo cliente. O processo inicia com a identificao de uma necessidade do cliente e encerra com a aceitao do produto ou servio. Este processo constitudo pelas seguintes atividades: Preparao da aquisio tem como propsito estabelecer as necessidades e os objetivos da aquisio e comunic-los aos fornecedores em potencial. Seleo do fornecedor tem como propsito escolher a organizao que ser responsvel pelo atendimento aos requisitos do projeto. Monitorao do contrato tem como propsito acompanhar e avaliar o desempenho do fornecedor em relao aos requisitos acordados. Aceitao pelo cliente tem como propsito aprovar os produtos entregues pelo fornecedor quando todos os critrios de aceitao so satisfeitos.
I.2 Processo da IEEE STD 1062:1998
Alm da norma ISO/IEC 12207, que a principal referncia para este documento, tambm devem ser considerados outros padres criados por associaes de profissionais, como o caso da norma IEEE STD 1062:1998 [IEEE 1062], que especfica para a aquisio de S&SC. Esta norma conhecida e utilizada internacionalmente, porm no Brasil no existem dados registrados de uso desse padro. H, nos Estados Unidos, cinco organizaes voltadas para o desenvolvimento da tecnologia de processos de desenvolvimento de software. Duas delas so especficas para a aquisio de produtos e servios de software: Outsourcing Center [OUTC, 2002] e COTS Group [COTS, 2002]. Na Europa existe tambm esta preocupao e, como exemplo, h na Unio Europeia o EUROMethod , o European Procurement Handbook for Open Systems - A ISO/IEC 12207 considerada de grande importncia para os processos internacionais de aquisio de software. uma norma apropriada para os processos de aquisio porque reconhece as distintas funes existentes para os compradores e fornecedores. Esta norma tem a inteno de ser usada pelas partes quando existir entre elas um acordo ou contrato que define o desenvolvimento, manuteno ou operao de um sistema de software. O processo de aquisio, definido pela ISO/IEC 12207, tem como propsito obter um produto ou servio que satisfaa a necessidade expressa pelo cliente. O processo inicia com a identificao de uma necessidade do cliente e encerra com a aceitao do produto ou servio. Este processo constitudo pelas seguintes atividades: Preparao da aquisio tem como propsito estabelecer as necessidades e os objetivos da aquisio e comunic-los aos fornecedores em potencial. Seleo do fornecedor tem como propsito escolher a organizao que ser responsvel pelo atendimento aos requisitos do projeto. Monitorao do contrato tem como propsito acompanhar e avaliar o desempenho do fornecedor em relao aos requisitos acordados. Aceitao pelo cliente tem como propsito aprovar os produtos entregues pelo fornecedor quando todos os critrios de aceitao so satisfeitos.

I.2 Processo da IEEE STD 1062:1998

Alm da norma ISO/IEC 12207, que a principal referncia para este documento, tambm devem ser considerados outros padres criados por associaes de profissionais, como o caso da norma IEEE STD 1062:1998 [IEEE 1062], que especfica para a aquisio de S&SC. Esta norma conhecida e utilizada internacionalmente, porm no Brasil no existem dados registrados de uso desse padro. H, nos Estados Unidos, cinco organizaes voltadas para o desenvolvimento da tecnologia de processos de desenvolvimento de software. Duas delas so especficas para a aquisio de produtos e servios de software: Outsourcing Center [OUTC, 2002] e COTS Group [COTS, 2002]. Na Europa existe tambm esta preocupao e, como exemplo, h na Unio Europeia o EUROMethod , o European Procurement Handbook for Open Systems

Caractersticas Escopo

COTS Fixo

MOTS Parcialmente personalizado Demonstrado em aplicaes similares

FD* Totalmente personalizado Sem precedentes

Adequao ao uso

Demonstrado

Manuteno

Sem controle

Controle parcial

Controle total

Prazo de Entrega Custo da aquisio

Imediato Baixo - Mdio

Pequeno - Grande Mdio - Alto

Grande Alto

Qualidade [ABNT NBR ISO/IEC 9126-1]

No controlada

Parcialmente controlada

Controlada em sua maior parte

(*) Parcialmente ou completamente terceirizado

Tabela 2 Caractersticas das classes de produto segundo a IEEE STD 1062:1998

Segundo a norma, o ciclo de vida da aquisio de software representa o perodo de tempo que comea com a deciso de adquirir um produto de software e termina quando o produto tem seu uso descontinuado. Este ciclo de vida representa um framework para a

aquisio. Os resultados, produo ou sada de uma fase so usados como entrada para a fase seguinte. A Tabela 3 apresenta a ilustrao dessas fases.
Fase Incio de Fase Fim de fase Passo no Processo de Aquisio de Software

Planejamento

Desenvolvimento da ideia

Chamada para proposta atualizada

1. Planejamento da estratgia organizacional, 2. Implementao do processo organizacional 3. Definio dos requisitos do software

Contratao

Atualizao da chamada para proposta

Contrato assinado

4. Identificao dos potenciais fornecedores 5. Preparao dos requisitos do contrato 6. Avaliao das propostas e seleo do fornecedor

Implementao do software

Assinatura do contrato

Recepo do software

7. Gerncia do desempenho do fornecedor

Aceitao do software

Recebimento do software

Aceite do software 8. Aceitao do software

Acompanhamento

Aceitao do software

Aposentadoria do software

9. Utilizao do software

Tabela 3 Fases do processo de aquisio de software segundo a IEEE STD 1062:1998

A norma define nove passos que devem ser seguidos para assegurar que os produtos com alto potencial de qualidade sejam devidamente pontuados, contemplados e considerados no processo de aquisio. O resultado esperado deve ser um software de alta qualidade e documentao adequada. Atributos como prazo de entrega e custos so deixados a critrio do usurio da norma. A Tabela 3 apresenta as fases, marcos e indica quais aes devem ser executadas e cumpridas MPS.BR-Guia de Aquisio:2009 77/87

em cada uma das fases. Os passos tm como foco a aquisio de software com um conjunto bsico de funcionalidades com possibilidade de serem desenvolvidas, ou componentes de software acabados. Esses passos so menos adequados para software com necessidade de implementao rpida. Os passos so: 1- Planejamento da estratgia organizacional: rev os objetivos da aquisio e desenvolve uma estratgia para a aquisio do software. 2- Implementao do processo organizacional: estabelece um processo de aquisio de software que atende as necessidades da organizao em obter um produto de qualidade. 3- Definio dos requisitos de software: define o software que deve ser adquirido e prepara os planos com os requisitos de qualidade e de manuteno para a aceitao do software. 4- Identificao dos potenciais fornecedores: seleciona os candidatos potenciais que devero apresentar a documentao de seu software, efetuar a demonstrao dos produtos, e apresentar as propostas formais de fornecimento. A no observao ou desempenho medocre em qualquer uma destas aes considerado como base ou argumento suficiente para a rejeio do potencial fornecedor. 5- Preparao dos requisitos do contrato: descreve a qualidade do trabalho a ser feito em termos de desempenho e critrios de aceitao e prepara as condies contratuais que estabelece a previso de pagamento de acordo com a entrega do software. 6- Avaliao das propostas e seleo do fornecedor: as propostas dos fornecedores so avaliadas, feita a escolha do fornecedor qualificado e o contrato negociado. 7- Gerncia do desempenho do fornecedor: o progresso do trabalho do fornecedor monitorado para garantir o cumprimento dos marcos e para aprovao das partes executadas do trabalho. O comprador ou adquirente deve, nesta fase, providenciar todos os insumos ao fornecedor, quando solicitado. 8- Aceitao do software: devem ser executados testes, conforme estabelece o processo, para garantir que todas as no conformidades sejam corrigidas e que todos os critrios de aceitao sejam satisfeitos. 9- Utilizao do software: so realizados acompanhamento e anlise do contrato de aquisio para avaliar as prticas do contrato, registrar as lies aprendidas e avaliar a satisfao do usurio com o produto. Os dados de desempenho do fornecedor devem ser armazenados. Segundo a norma, o sucesso na aquisio de um software ou servio correlato de alta qualidade pode ser alcanado se as seguintes aes forem executadas: a) identificao das caractersticas de qualidade necessrias para atingir os objetivos do comprador ou adquirente; b) incluso de consideraes de qualidade nas atividades de planejamento, avaliao e aceitao do produto; c) implementao de uma estratgia organizacional para a aquisio de software; d) implementao de um processo de aquisio de software usando os nove passos sugeridos pela norma no texto anterior; e e) colocao do processo em prtica.

A Figura 4 relaciona os passos previstos na norma IEEE STD 1062:1998 com as atividades estabelecidas na ISO/IEC 12207:2008, indicando a possibilidade de complementao do processo estabelecido neste guia, que compatvel com esta norma da ISO/IEC.

Bibliografia
Sociedade Softex. MPS.BR Melhoria de Processo do Software Brasileiro: Disponvel em: http://pt.scribd.com/doc/53463302/33/I-2-Processo-da-IEEE-STD-1062-1998. Acesso em: 22 de agosto de 2011. Ana Maria Dias Igncio, Ps-graduada em Gesto e Tecnologia da Informao. Um processo de seleo de fornecedores de software: Disponvel em: http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/253. Acesso em: 21 de agosto de 2011. Jos Augusto Fabri, Mestre em Cincia da Computao pela Ufscar. A expanso da idia da residncia de software: Disponvel em: http://engenhariasoftware.wordpress.com/category/qualidade-desoftware/. Acesso em: 22 de agosto de 2011. Artigo da revista Engenharia de software. Introduo a inspeo do software: Disponvel em: http://www.devmedia.com.br/articles/viewcomp.asp?comp=8037. Acesso em: 19 de agosto de 2011. A Norma ISO 9000-3. Disponvel em: http://www.geocities.ws/chicorapchan/artigos/9000-3.pdf A Norma ISO 12119 Qualidade de Pacotes de Software. Disponvel em: http://www.comp.ita.cta.br/~cunha/download/CES32CE2302003/Sem03/Aula03.1dCes32Ce23003b %28ISO12119PacotesdeSW%29.pdf ISO 14598. Disponvel em: http://inf.unisul.br/~vera/egs/ISO%2014598.htm Apresentao ISO 9000-3. Disponvel em: http://www2.dem.inpe.br/ijar/Qualidade%20de %20Software/PDFs/apresentacaoISO9000-3.pdf