Apostila - Engenharia de Software - Qualidade de Software, Notas de estudo de Análise de Sistemas de Engenharia

Baixe Apostila - Engenharia de Software - Qualidade de Software e outras Notas de estudo em PDF para Análise de Sistemas de Engenharia, somente na Docsity!

UNIVERSIDADE DE PASSO FUNDO INSTITUTO DE CIÊNCIAS EXATAS E GEOCIÊNCIAS CIÊNCIA DA COMPUTAÇÃO

Qualidade de Software

SUMÁRIO

I. - O QUE É QUALIDADE

Qualidade hoje em dia, não é apenas um diferencial de mercado para a empresa conseguir vender e lucrar mais, é um pré requisito que a empresa deve conquistar para conseguir colocar o produto no Mercado Global. Na área de software, há uma urgente necessidade de uma maior preocupação sobre o tema, mas afinal, o que é qualidade? Existem diversas definições. Algumas pessoas que tentaram uma definição simples chegaram a frases como:

• Qualidade é estar em conformidade com os requisitos dos clientes
• Qualidade é antecipar e satisfazer os desejos dos clientes
• Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito

Segunda a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade é:

A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas

Nota-se que esta definição formal exige alguns complementos, principalmente para definir o que são as entidades , as necessidades explícitas e as necessidades

implícitas.

• A entidade é o produto do qual estamos falando, que pode ser um bem ou um serviço.
• As necessidades explícitas são as próprias condições e objetivos propostos pelo produtor.
• As necessidades implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações éticas, as questões de segurança e outras visões subjetivas.

Por exemplo, a qualidade de um prato de comida (a entidade, o produto) está relacionada com a satisfação de necessidades (requisitos) tais como: sabor, aparência, temperatura, rapidez no serviço, preço, higiene, valor nutricional, etc... Para avaliar a qualidade de um produto, deve-se fazer uma lista destas necessidades e analisar cada uma destas necessidades.

Proposições da qualidade de software:

1. Qualidade é o sucesso para o negócio de softwares, como em qualquer outro;
2. A maneira mais barata de aumentar a produtividade é aumentar a qualidade do software;
3. A qualidade ao suporte do produto é tão importante quanto a qualidade do próprio software, o ambiente de suporte deve ter engenharia tanto quanto o ambiente de desenvolvimento;
4. Para alcançar a qualidade de software, as pessoas e a cultura são tão importantes quanto a tecnologia;
5. O único caminho seguro para aumentar a qualidade do software é melhorar os processos ( o que inclui pessoal, facilidades, equipamentos, tecnologia e metodologia);
6. Aumento de processos é normalmente desnecessário a menos que o gerente demonstre compromisso e liderança;

7. Qualidade e melhoramento dos processos são de difíceis esforços: é sempre possível realizar algo um pouco melhor, um pouco mais rápido e um pouco mais barato;
8. Um sistema de qualidade compatível com ISO9000 é um bom alvo para muitas organizações, mas não para todas;
9. Um sistema de qualidade para uma organização deve ser medido de acordo com suas

necessidades e circunstâncias ou não será eficiente

10. Um sistema de qualidade de software eficiente utiliza de boas práticas da engenharia de software baseado nos seguintes princípios:

Princípios de qualidade:

• Tentar previnir defeitos ao invés de consertá-los;
• Ter certeza dos defeitos que forem encontrados, serem corrigidos o mais rápido

possível;

• Estabelecer e eliminar as causas, bem como os sintomas dos defeitos;
• Auditar o trabalho de acordo com padrões e procedimentos previamente estabelecidos;

Princípios de gerência:

• Definir regras e responsabilidades;
• Planejar o trabalho;
• (^) Trilhar o progressso através de planos e corrigir quando necessário;
• Refinar o plano sempre e progressivamente;

Princípios de engenharia:

• Analisar o problema antes de desenvolver a solução;
• Quebrar problemas complexos em problemas menores;
• Garantir que subproblemas unam-se pelo controle de seus relacionamentos;

II. -HISTÓRICO DA QUALIDADE

Conceituar qualidade se torna uma tarefa muito difícil, pois elementos intrínsecos está enraizado no intelecto de cada ser. Portanto se exercícios forem feitos dando como missão para cada grupo, várias definições são apresentadas, mas o que mostra como bem próximo de se considerar é como sendo um método gerencial que através de processos e procedimentos disseminados pôr toda a organização busca uma posição competitiva para propiciar a satisfação da sociedade ao longo do tempo.

A história do desenvolvimento da Qualidade Total como sistema administrativo ter que ser buscado na origem do modelo científico de administração F. Taylor em 1911 publicado em seu livro Princípios da Administração Cientifica em que citava: o aumento da eficiência , a racionalização dos métodos de trabalho, a crença no homem econômico , a divisão e a hierarquização do trabalho , a relevância da organização formal.

Nos anos 30, o Dr. W.A. Shewhart causa uma revolução à teoria científica da administração quando propõe um método voltado para gestão das organizações conhecido como Controle da Qualidade - Controle Estatístico da Qualidade (CEQ) ou Controle Estatístico de Processos (CEP) que se baseava na aplicação de gráficos de controle, na inspeção por amostragem.

A tese de Deming para os industriais do pós guerra , nos Estados Unidos, era a da produção com qualidade. Mas, como muitas vezes acontece, a verdade é que Deming não

III. - PORQUÊ SE PREOCUPAR COM A QUALIDADE DE SOFTWARE?

A qualidade, hoje em dia, é crítica para a sobrevivência e o sucessso do mercado de software que está se desenvolvendo de forma global. Uma organização não sobressairá no mercado global a menos que produza software de boa qualidade e seus clientes vejam produtos e serviços de boa qualidade.

Existem muitas razões que devem ser levadas em conta, a saber:

A) Qualidade é competitividade: a única maneira de diferenciar o produto do competidor

é pela qualidade do software e do suporte que é fornecido juntamente. Como o mercado amadurece, usuários não querem apenas que a empresa fale que tem qualidade, mas que mostre a todos a sua qualidade através de Certificação internacional. Não ter certificação pode acarretar desvantagem competitiva.

B) Qualidade é essencial para a sobrevivência: Clientes estão pedindo por qualidade. Se a empresa não tiver habilidade de sobreviver em um mercado altamente competitivo, ela está em débito com o mercado. A maioria das grandes organizações está reduzindo o número de fornecedores, e um meio de escolher os fornecedores é verificando quais deles têm certificações de qualidade.

C) Qualidade é essencial para o mercado internacional: O mercado de software está, cada

vez mais, se tornando global. A habilidade das empresas de mostrarem qualidade, eventualmente as colocam no mercado global. O mercado local é vulnerável a produtos importados que, normalmente, têm mais qualidade.

D) Qualidade é custo/benefício: um sistema de qualidade direciona para o aumento da

produtividade e permanentemente reduz custos, habilitando o gerenciamento para reduzir a correção de defeitos dando ênfase à prevenção. Todas as empresas sabem que corrigir defeitos após o desenvolvimento do software é mais dispendioso do que corrigi-los depois. Prevenir defeitos primeiramente pode resolver muita coisa depois e economizar bastante.

E) Qualidade retém consumidores e aumenta lucros: pouca qualidade normalmente custa

muito mais do que contratar mais desenvolvedores e ainda continuar sem qualidade. A maioria dos consumidores não tolerarão falta de qualidade e irão procurar outros desenvolvedores. Mais qualidade aumenta a satisfação dos consumidores e assegura os que já são clientes a mais tempo.

Qualidade x Definição de pré-requisitos

O processo de pré-requisitos deve identificar e definir as características de um produto em particular que é de necessidade do cliente e distinguí-los dos menos importantes. É importantíssimo que, na entrega do produto final, o sistema tenha pouquíssimos ou nenhum erro ou falha e seja fácil de utilizá-lo deixando a performance para segundo plano.

A comunicação entre o desenvolvedor e o cliente é a chave para a definição correta. O desenvolvedor deverá trabalhar em conjunto com o cliente, nesta primeira fase, para definir corretamente as especificações do software.

No caso de a empresa não poder entrar em contato direto com o cliente (um produto para vários clientes, como um sistema que vai ser desenvolvido para o mercado SOHO – Small Office/Home Office), a função do marketing da empresa deverá ser tomada como cliente por conhecer o mercado que o produto vai ser lançado.

É aconselhável desenvolver técnicas de prototipagem para isolar e definir as características de qualidade.

O processo de descobrir os pré-requisitos do sistema é geralmente a fase de análise do sistema. O custo/benefício de se aplicar adequadamente os recursos para esta fase é muito grande.

“Pode ser muito caro desenvolver o software errado”

Qualidade e o desenvolvimento software

O processo de desenvolvimento do software é onde os desenvolvedores traduzem os pré-requisitos em software.

É certo que a qualidade do software está diretamente ligada à qualidade dos processos utilizados para o desenvolvimento.

Um bom desenvolvimento de software deve capacitar à organização a definição da consistência do produtos de qualidade. A comunidade de software está vendo que o desenvolvimento do produto deve ser feito de maneira muito rápida. O ciclo de vida do produto é agora um negócio crítico para muitos desenvolvedores.

Os consumidores de software necessitam de produtos cada vez melhores e mais rápidos de serem desenvolvidos para aumentar a sua competitividade no mercado global.

Se estes objetivos forem cumpridos, o desenvolvimento de software, deve:

• Utilizar as melhores práticas da engenharia de software;
• Ser operado por pessoal treinado com responsabilidades e instruções;
• Dar ênfase na prevenção de defeitos assim que forem detectados
• Gerar registro para demonstrar efetividade e eficiência;
• Utilizar destes registros para aumentar a performance no futuro.

IV. - QUALIDADE E SERVIÇO DE SUPORTE AO USUÁRIO

O suporte ao usuário é complexo e deve incluir:

• Documentação para o usuário, incluindo ajuda on-line;
• Empacotamento e distribuição organizados;
• Implementação e customização de serviços e consultas;
• Treinamento;
• Assistência help-desk;
• Relatórios de erros e correções;
• Melhoramento do software.

• O selo do SIF de inspeção da carne
• O selo da ABIC nos pacotes de café
• O certificado da Secretaria de Saúde para restaurantes (classe "A" são os melhores)
• A classificação em estrelas dos hotéis (hotéis com cinco estrelas são ótimos)
• Os certificados de qualidade da série ISO-

Ouvimos muitas propagandas de empresas falando de sua certificação ISO-9000. Isto nada mais é do que um padrão de qualidade (reconhecido mundialmente) pelo qual esta empresa foi avaliada e julgada. Para que seja possível realizar uma avaliação e um julgamento, é necessário haver um padrão ou norma. Existem alguns organismos normalizadores reconhecidos mundialmente:

ISO - International Organization for Standardization IEEE - Instituto de Engenharia Elétrica e Eletrônica ABNT - Associação Brasileira de Normas Técnicas

A norma ISO-9000, por exemplo, foi criada pela ISO para permitir que todas as empresas do mundo possam avaliar e julgar sua qualidade. Existindo um padrão único mundial, uma empresa do Brasil, mesmo não tendo nenhum contato com uma outra empresa na Europa, pode garantir a ela a qualidade de seu trabalho.

A Certificação em uma norma ou padrão é a emissão de um documento oficial indicando a conformidade com esta determinada norma ou padrão. É claro que, antes da emissão do certificado, é preciso realizar todo um processo de avaliação e julgamento de acordo com uma determinada norma. Embora uma empresa possa auto-avaliar-se ou ser avaliada por seus próprios clientes, o termo Certificação costuma ser aplicado apenas quando efetuado por uma empresa independente e idônea, normalmente especializada neste tipo de trabalho.

No Brasil, o INMETRO é o órgão do governo responsável pelo credenciamento destas instituições que realizam a certificação de sistemas de qualidade.

Qualidade Produto x Qualidade Processo

Uma das evoluções mais importantes no estudo da qualidade está em notar que a qualidade do produto é algo bom, mas que qualidade do processo de produção é ainda mais importante. No caso do prato de comida, por exemplo, pode-se dizer mais sobre a qualidade observando como o prato foi preparado do que analisando o produto final.

Afinal, não se consegue ter certeza da higiene ou o valor nutricional apenas comendo o prato.

Esta descoberta aconteceu durante a própria evolução dos conceitos de qualidade, ao longo dos anos. Observe na tabela abaixo como aconteceu esta evolução:

1. Inspeção pós-produção Avalia o produto final, depois de pronto 1900
2. Controle estatístico da produção Avalia os subprodutos das etapas de produção 1940
3. Procedimento de produção Avalia todo o procedimento de produção 1950
4. Educação das pessoas Avalia as pessoas envolvidas no processo 1960
5. Otimização dos processos Avalia e otimiza cada processo 1970

6. Projeto robusto Avalia o projeto de produção 1980
7. Engenharia simultânea Avalia a própria concepção do produto 1990

Hoje em dia, pode-se consultar normas e padrões tanto para produtos quanto para processos. Obviamente, os certificados mais valiosos são aqueles que certificam o processo de produção de um produto e não aqueles que simplesmente certificam o produto.

Entretanto, é comum encontrar empresas que perseguem os dois tipos de padrão de qualidade.

VI. - QUALIDADE DE SOFTWARE:

Agora que se tem o conhecimento sobre o que é qualidade e como ela pode ser avaliada, vamos tentar aplicar estes conceitos aos produtos de software e ao processo de desenvolvimento de software. Inicialmente, vamos encontrar um grande problema: muitas pessoas acham que criar programas é uma arte que não pode seguir regras, normas ou padrões. Isto acontece principalmente porque:

• Produtos de software são complexos, até mais do que o hardware onde executam
• Software não têm produção em série. Seu custo está no projeto e desenvolvimento
• Software não se desgasta e nem de modifica com o uso
• Software é invisível. Sua representação em gráficos e diagramas não é precisa.
• A Engenharia de Software ainda não está madura, é uma tecnologia em evolução
• Não há um acordo entre os profissionais da área sobre o que é Qualidade de Software

Apesar de tudo isso, precisamos entender que o problema não está no Software em si, mas na forma como as pessoas tem desenvolvido software até os dias de hoje. Precisamos nos conscientizar que necessitamos aplicar na indústria de software os conceitos de qualidade, urgentemente.

Atualmente, muitas instituições se preocupam em criar normas para permitir a correta avaliação de qualidade tanto de produtos de software quanto de processos de desenvolvimento de software. Apenas para ter uma visão geral, observe o quadro a seguir, com as principais normas nacionais e internacionais nesta área:

de configuração, técnicas de garantia de qualidade e outras técnicas de padronização da atividade de produção de software."

Qualidade de Produtos de Software - ISO 9126

Quando se pensa em qualidade de um "produto físico", é fácil imaginar padrões de comparação, provavelmente ligado às dimensões do produto ou alguma outra característica física. Quando se trata de software, como podemos definir exatamente o que é a qualidade? Parece difícil...

Felizmente, para nós, a ISO (Organização Internacional de Padrões) já pensou bastante sobre o assunto. O suficiente para publicar uma norma que representa a atual padronização mundial para a qualidade de produtos de software. Esta norma chama-se ISO/ IEC 9126 e foi publicada em 1991. Ela é uma das mais antigas da área de qualidade de software e já possui sua tradução para o Brasil, publicada em agosto de 1996 como NBR

Mas, afinal de contas, o que está escrito nesta norma ISO/IEC 9126 ou na NBR 13596? Bem, estas normas listam o conjunto de características que devem ser verificadas em um software para que ele seja considerado um "software de qualidade". São seis grandes grupos de características, cada um dividido em algumas subcaracterísticas.

Os nomes dados pelo ISO/IEC para as características e subcaracterísticas são um pouco .Entretanto, uma pessoa que trabalha com software não terá dificuldade em entendê- las. Observe na tabela abaixo a lista completa:

Característica Sub-característica Pergunta chave para a subcaracterística Funcionalidade (satisfaz as necessidades?)

Adequação Propõe-se a fazer o que é apropriado? Acurácia Faz o que foi proposto de forma correta? Interoperbilidade Interage com os sistemas especificados? Conformidade Está de acordo com as normas, leis, etc.? Segurança de acesso Evita acesso não autorizado aos dados? Confiabilidade (é imune a falhas?)

Maturidade Com que freqüência apresenta falhas?

Tolerância a falhas Ocorrendo falhas, como ele reage? Recuperabilidade É capaz de recuperar dados em caso de falha? Usabilidade (é fácil de usar?)

Intelegibilidade É fácil entender o conceito e a aplicação?

Apreensibilidade É fácil aprender a usar? Operacionalidade É fácil de operar e controlar? Eficiência (é rápido e "enxuto"?)

Tempo Qual é o tempo de resposta, a velocidade de execução?

Recursos Quanto recurso usa? Durante quanto tempo? Manutenibilidade (é fácil de modificar?)

Analisabilidade É fácil de encontrar uma falha, quando ocorre?

Modificabilidade É fácil modificar e adaptar? Estabilidade Há grande risco quando se faz alterações? Testabilidade É fácil testar quando se faz alterações? Portabilidade (é facil de usar em outro ambiente?)

Adaptabilidade É fácil adaptar a outros ambientes?

Capac. para ser instalado É fácil instalar em outros ambientes?

Conformidade Está de acordo com padrões de portabilidade? Capac. Para substituir É fácil usar para substituir outro?

VII - MÉTRICAS DE SOFTWARE

Embora a atual norma ISO 9126/NBR 13596 enumere as características e sub- características um software, ela ainda não define como dar uma nota a um software em cada um destes itens. A não familiarização com o processo de avaliação de software, pode- se ter dificuldades em tentar utilizar a norma. Se pretende avaliar um software segundo esta norma, deve tentar atribuir valores (como se fossem notas ou conceitos) a cada uma das sub-características.

Algumas características podem ser realmente medidas, como o tempo de execução de um programa, número de linhas de código, número de erros encontrados em uma sessão de teste ou o tempo médio entre falhas. Nestes casos, é possível utilizar uma técnica, uma ferramenta ou um software para realizar medições. Em outros casos, a característica é tão subjetiva que não existe nenhuma forma óbvia de medí-la.

Ficam, portanto, as questões: como dar uma nota, em valor numérico, a uma característica inteiramente subjetiva? O que representa, por exemplo, uma "nota 10" em termos de "Segurança de Acesso"? Quando se pode dizer que a "Intelegibilidade" de um software pode ser considerada "satisfatória"? Criou-se, então, uma área de estudo à parte dentro da Qualidade de Software conhecida como Métricas de Software. O que se pretende fazer é definir, de forma precisa, como medir numericamente uma determinada característica.

Para avaliar uma determinada subcaracterística subjetiva de forma simplificada, por exemplo, pode-se criar uma série de perguntas do tipo "sim ou não". Crie as perguntas de forma tal que as respostas "sim" sejam aquelas que indicam uma melhor nota para a característica. Depois de prontas as perguntas, basta avaliar o software, respondendo a cada pergunta. Se conseguir listar 10 perguntas e o software obtiver uma resposta "sim" em 8 delas, terá obtido um valor de 80% nesta característica.

Obviamente, a técnica acima não é muito eficiente. Para melhorá-la, entretanto, pode-se garantir um número mínimo perguntas para cada característica. Além disso, algumas perguntas mais importantes podem ter pesos maiores. É possível, ainda, criar perguntas do tipo ABCDE, onde cada resposta indicaria um escore diferenciado. Alguns estudiosos sugerem formas diferentes de medir uma característica, baseada em conceitos do tipo "não satisfaz", "satisfaz parcialmente", "satisfaz totalmente" e "excede os padrões". Estes conceitos, embora parecem muito subjetivos, não deixam de ser uma forma eficiente de medir uma característica.

Em todos os casos, um fato fica claro: nada ajuda mais a avaliar características de um software do que um avaliador experiente, que já realizou esta tarefa diversas vezes e em diversas empresas diferentes. Afinal, medir é comparar com padrões e um avaliador experiente terá maior sensibilidade do que um profissional que acaba de ler uma norma pela primeira vez.

Atualmente, a norma ISO/IEC 9126 está sendo revisada. A revisão, que deverá estar pronta nos próximos anos, não deverá modificar nenhuma das características básicas da 9126. A maior modificação será a inclusão de dois documentos adicionais para descrever

14598-4 Guia para Aquisição Como avaliar sob o ponto de vista de quem vai adquirir 14598-5 Guia para Avaliação Como avaliar sob o ponto de vista de quem certifica 14598-6 Módulos de Avaliação Detalhes sobre como avaliar cada característica

Em resumo, esta nova norma complementará a ISO/IEC 9126 e permitirá uma avaliação padronizada das características de qualidade de um software. É importante notar que, ao contrário da 9126, a 14598 vai a detalhes mínimos, incluindo modelos para relatórios de avaliação, técnicas para medição das características, documentos necessários para avaliação e fases da avaliação. Como um exemplo, observe um modelo de relatório de avaliação, segundo um anexo da norma 14598-5:

Seção Itens 1 - Prefácio Identificação do avaliador Identificação do relatório de avaliação Identificação do contratante e fornecedor 2 - Requisitos Descrição geral do domínio de aplicação do produto Descrição geral dos objetivos do produto Lista dos requisitos de qualidade, incluindo - Informações do produto a serem avaliadas - Referências às características de qualidade - Níveis de avaliação 3 - Especificação Abrangência da avaliação Referência cruzada entre os requisitos de avaliação e os componentes do produto Especificação das medições e dos pontos de verificação Mapeamento entre a especificação das medições com os requisitos de avaliação 4 - Métodos Métodos e componentes nos quais o método será aplicado 5 - Resultado Resultados da avaliação propriamente ditos Resultados intermediários e decisões de interpretação Referência às ferramentas utilizadas

As normas 14598-1, 14598-4 e 14598-5 já foram publicadas. As demais estão em

processo de finalização. Está sendo feito pela ABNT um trabalho de tradução desta norma (tanto dos itens já publicados quanto das versões preliminares dos itens restantes). Com isso, esta norma terá sua versão brasileira pouco tempo depois do final de sua publicação pela ISO.

IX - QUALIDADE DE PACOTES DE SOFTWARE - ISO 12119

Esta norma foi publicada em 1994 e trata da avaliação de pacotes de software,

também conhecidos como "software de prateleira". Além de estabelecer os requisitos de qualidade para este tipo de software, ela também destaca a necessidade de instruções para teste deste pacote, considerando estes requisitos. A norma divide-se em itens, da seguinte forma:

Item Descrição

**1. Escopo

2. Definições
3. Requisitos de qualidade** 3.1. Descrição do Produto Descreve o produto, de forma a ajudar o comprador em potencial, servindo como base para testes. Cada declaração deve ser correta e testável. Deve incluir declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 3.2. Documentação do usuário

Deve ser completa, correta, consistente, fácil de entender e capaz de dar uma visão geral do produto. 3.3. Programas e dados Descreve em detalhes cada uma das funções do software, incluindo declarações sobre funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

4. Instruções para teste 4.1. Pré-requisitos de teste Lista de itens necessários ao teste, incluindo documentos incluídos no pacote, componentes do sistema e material de treinamento. 4.2. Atividades de teste Instruções detalhadas sobre os procedimentos de teste, inclusive instalação e execução de cada uma das funções descritas. 4.3. Registro de teste Informações sobre como os testes foram realizados, de tal forma a permitir uma reprodução destes testes. Deve incluir parâmetros utilizados, resultados associados, falhas ocorridas e até a identidade do pessoal envolvido. 4.4. Relatório de teste Relatório inlcuindo: identificação do produto, hardware e software utilizado, documentos utilizados, resultados dos testes, lista de não conformidade com os requisitos, lista de não conformidade com as recomendações, datas, etc.

Um dos grandes méritos desta norma está na profundidade com que são descritas cada uma das características e subcaracterísticas mencionadas na norma 9126. A norma inclui detalhes que devem estar presentes no produto, tais como:

Documentação do usuário de fácil compreensão Um sumário e um índice remissivo na documentação do usuário Presença de um Manual de instalação com instruções detalhadas Possibilidade de verificar se uma instalação foi bem sucedida Especificação de valores limites para todos os dados de entrada, que deverão ser testados Operação normal mesmo quando os dados informados estão fora dos limites especificados Consistência de vocabulário entre as mensagens e a documentação

software. Todas as orientações giram em torno de uma "situação contratual", onde uma outra empresa contrata a empresa em questão para desenvolver um produto de software.

Na tabela abaixo seguem os processos definidos na ISO 9000-3:

Grupo Atividade Estrutura do Sistema de Qualidade Responsabilidade do fornecedor Responsabilidade do comprador Análise crítica conjunta Atividades do Ciclo de Vida Análise crítica do contrato Especificação dos requisitos do comprador Planejamento do desenvolvimento Projeto e implementação Testes e validação Aceitação Cópia, entrega e instalação Manutenção Atividades de Apio Gerenciamento de configuração Controle de documentos Registros da qualidade Medição Regras, convenções Aquisição Produto de software incluído Treinamento

O processo de certificação de uma empresa de software segundo as normas ISO 9001 / 9000-3 segue um conjunto de passos bem definidos:

• A empresa estabelece o seu sistema de qualidade.
• 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 O órgão certificador faz uma visita à empresa, colhe mais dados e explica o processo de certificação O órgão certificador verifica se a documentação do sistema de qualidade está de acordo com a norma ISO 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.
• O órgão certificador emite o certificado de qualidade
• O órgão certificador realiza visitas periódicas à empresa para assegurar que o sistema continua sendo efetivo

XII - ISO 12207 – PROCESSO DE VIDA DO CICLO DE SOFTWARE

Este padrão formaliza a arquitetura do ciclo de vida do software, que é um assunto básico em Engenharia de Software e também em qualquer estudo sobre Qualidade do Processo de Software. Esta norma possui mais de 60 páginas e detalha os diversos processos envolvidos no ciclo de vida do software.

Estes processos estão divididos em três classes: Processos Fundamentais, Processos de Apoio e Processos Organizacionais.

Segue a lista completa dos processos na tabela abaixo:

Processos Fundamentais Início e execução do desenvolvimento, operação ou manutenção do software durante o seu ciclo de vida. Aquisição Atividades de quem um software. Inclui: definição da necessidade de adquirir um software (produto ou serviço), pedido de proposta, seleção de fornecedor, gerência da aquisição e aceitação do software. Fornecimento Atividades do fornecedor de software. Inclui preparar uma proposta, assinatura de contrato, determinação recursos necessários, planos de projeto e entrega do software. Desenvolvimento Atividades do desenvolvedor de software. Inclui: análise de requisitos, projeto, codificação, integração, testes, instalação e aceitação do software. Operação Atividades do operador do software. Inclui: operação do software e suporte operacional aos usuários. Manutenção Atividades de quem faz a manutenção do software. Processos de Apoio Auxiliam um outro processo. Documentação Registro de informações produzidas por um processo ou atividade. Inclui planejamento, projeto, desenvolvimento, produção, edição, distribuição e manutenção dos documentos necessários a gerentes, engenheiros e usuários do software. Gerência de Configuração Identificação e controle dos itens do software. Inclui: controle de armazenamento, liberações, manipulação, distribuição e modificação de cada um dos itens que compõem o software. Garantia da Qualidade Garante que os processos e produtos de software estejam em conformidade com os requisitos e os planos estabelecidos. Verificação Determina se os produtos de software de uma atividade atendem completamente aos requisitos ou condições impostas a eles. Validação Determina se os requisitos e o produto final (sistema ou software) atendem ao uso específico proposto. Revisão Conjunta Define as atividades para avaliar a situação e produtos de uma atividade de um projeto, se apropriado. Auditoria Determina adequação aos requisitos, planos e contrato, quando apropriado. Resolução de Problemas Análisar e resolução dos problemas de Qualquer natureza ou fonte, descobertos durante a execução do desenvolvimento, operação, manutenção ou outros processos.. Processos Organizacionais Implementam uma estrutura constituída de processos de ciclo de vida e pessoal associados, melhorando continuamente a estrutura e os processos. Gerência Gerenciamento de processos.