Unidade III QUALIDADE DE SOFTWARE. Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) 1 as seguintes definições: Normalização

1/09/20 10

Unidade III

Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas)1 _{as seguintes definições:}

Normalização

Atividade que estabelece, em relação a problemas existentes ou potenciais, prescrições destinadas à utilização comum e repetitiva com vistas à obtenção do grau ótimo de ordem em um dado contexto.

Objetivos da normalização: • Economia

Proporcionar a redução da crescente variedade de produtos e procedimentos.

• Comunicação

Proporcionar meios mais eficientes na troca de informação entre o fabricante e o cliente, melhorando a confiabilidade das relações comerciais e de serviços.

• Segurança

Proteger a vida humana e a saúde. 1 _{Disponível em: http://www.abnt.org.br}

1/09/20

10

• Proteção do consumidor

Prover a sociedade de meios eficazes para aferir a qualidade dos produtos.

• Eliminação de barreiras técnicas e comerciais

Evitar a existência de regulamentos conflitantes sobre produtos e serviços em diferentes países, facilitando, assim, o intercâmbio comercial.

Na prática, a normalização está presente na fabricação dos produtos, na transferência de tecnologia, na melhoria da qualidade da vida através de normas relativas à saúde, à segurança e à preservação do meio ambiente.

Numa economia onde a competitividade é acirrada e onde as exigências são cada vez mais crescentes, as empresas dependem de sua capacidade de incorporação de novas tecnologias de produtos, processos e serviços. A competição internacional entre as empresas eliminou as tradicionais vantagens baseadas no uso de fatores abundantes e de baixo custo. A normalização é utilizada cada vez mais como um meio para se alcançar a redução de custo da produção e do produto final, mantendo ou melhorando sua qualidade.

A figura 9 mostra que o desenvolvimento de software é composto de diversas fases em seu ciclo de vida e que suas atividades produzem uma sequência de produtos relacionados. Diversos produtos intermediários são gerados e o produto final que será entregue ao cliente/usuário deve atender aos requisitos do sistema. As atividades e os artefatos (produtos) que devem ser criados em um projeto de software são definidos pelas normas ou padrões definidos na organização. 5 10 15 20 25 30

1/09/20

10

Figura 9: Modelo de qualidade

Padrões de desenvolvimento de software Atividades, produtos, métodos, ferramentas... Medidas da qualidade

Requisitos Design Codificação Testes Manutenção

Rastreabilidade Produtividade

Fonte: adaptado de Card (1990).

De acordo com Côrtes & Chiossi (2001), no modelo de qualidade de Card (1990) mostrado na figura 9, padrões e procedimentos definem o processo e o conjunto de expectativas para os produtos. Cada atividade implicitamente inclui um processo e, dependendo da atividade, ela deve observar características tais como produtividade e rastreabilidade. Chama-se produtividade a facilidade de Chama-se estabelecer um processo de produção eficiente e eficaz. A rastreabilidade possibilita que sejam verificados os objetivos funcionais e de desempenho do sistema de software.

Como a qualidade de software envolve tanto o processo de desenvolvimento como os produtos gerados no processo, ela vem sendo ao longo do tempo normalizada e padronizada na busca por torná-la uma verdadeira engenharia.

Existem diversas normas desenvolvidas para a área de software no mundo e no Brasil. Este módulo abordará as principais e mais importantes para processos e produtos de software. Serão apresentadas as normas e padrões: ISO 9000, ISO/IEC 12207 IEEE Std 12207-2008 e NBR ISO/IEC 9126-1. ISO

5

10

15

1/09/20

10

significa International Organization for Standardization e é o nome de um grupo internacional de normalização localizado em Genebra, Suíça, fundado em 23/02/1947 que não possui ligações com órgãos governamentais.

3.1 Norma ISO/IEC 12207 IEEE Std 12207-2008 – engenharia de software e sistemas – processo do ciclo de vida de software

Norma ou padrão internacional que estabelece um framework comum para o processo de ciclo de vida de software.

3.1.1 Resumo

A ISO/IEC 12207 estabelece um framework para o ciclo de vida para o processo de software, com uma terminologia bem definida, que pode ser referenciada pela indústria de software. Ela pode ser aplicada para aquisição de sistemas, produtos e serviços, para o suporte, desenvolvimento, operação, manutenção, tanto para sistemas desenvolvidos internamente como externamente para uma organização.

Esta norma internacional provê um processo que pode ser utilizado para definir e melhorar processos de ciclo de vida de software. Os processos, atividades e tarefas desta norma ou padrão, também podem ser aplicados sozinhos ou em conjunto com a norma ISO/IEC 15288 (processos de ciclo de vida de sistemas) na aquisição de um sistema que contenha software. Ela fornece um modelo de referência de avaliação de processo de acordo com a norma ISO/IEC 15504-2 (avaliação de processo). 3.1.2 Definições

Na norma um produto pode ser entendido como uma parte de um sistema, quando aplicável. A norma apresenta os seguintes termos e definições:

5

10

15

1/09/20

10

Adquirente

Uma organização que adquire ou obtém um sistema, produto de software ou serviço de software de um fornecedor. O adquirente poderia ser: comprador, cliente, proprietário ou usuário.

Acordo

A definição de termos e condições sob a qual o relacionamento de trabalho entre as partes deverá ser conduzido.

Aposentadoria ou retirada de operação

Retirada do software de funcionamento pela organização de operação ou manutenção, com substitução parcial ou total por um novo sistema, ou instalação de um sistema atualizado.

Aquisição

O processo de obtenção de um sistema, produto de software ou serviço de software.

Atividade

Conjunto de tarefas coesas de um processo. Auditoria

Processo conduzido por uma pessoa autorizada com o objetivo de prover um julgamento independente de produtos e processos de software, a fim de avaliar a conformidade com seus requisitos.

5

10

15

1/09/20

10

Avaliação

Uma determinação sistemática do grau de atendimento de uma entidade em relação aos critérios para ela estabelecidos.

Carteira de projetos (portfólio de projetos)

Conjunto de projetos que atenda os objetivos estratégicos da organização.

Ciclo de vida

Evolução de um sistema, produto, serviço, projeto ou entidade de origem humana desde a concepção até a retirada ou aposentadoria do sistema.

Cliente

Organização ou pessoa que recebe um produto ou serviço. Nota 1: Um cliente pode ser interno ou externo à organização.

Nota 2: Adaptado da norma ISO 9000: 2005.

Nota 3: Outros termos comumente usados para o cliente são adquirente ou comprador.

Cobertura de teste

Extenção ou quantidade de casos de teste para os requisitos do sistema ou software do produto.

Contrato

Um acordo realizado entre duas partes, respaldado pela

5

10

15

1/09/20

10

para o fornecimento de serviços de software ou para o fornecimento, desenvolvimento, produção, operação ou manutenção de um produto de software.

Declaração de trabalho

Documento utilizado pelo adquirente como um meio para descrever e especificar as tarefas a serem executadas no âmbito do contrato.

Desenvolvedor

Uma organização que executa atividades de desenvolvimento (incluindo análise de requisitos, projeto, testes até aceitação) durante o processo de ciclo de vida de software.

Elemento de sistema

Membro de um conjunto de elementos que constitui um sistema.

Observação: um elemento de sistema é uma parte distinta de um sistema, que pode ser implementado para cumprir os requisitos especificados. Um elemento do sistema pode ser hardware, software, dados, pessoas, processos (por exemplo: os processos de prestação de serviço para os usuários), procedimentos (por exemplo: as instruções do operador), instalações, materiais e entidades naturais (organismos, por exemplo, água, minerais), ou qualquer combinação.

Estágio

Período dentro do ciclo de vida de uma entidade que mostra o estado de sua descrição ou realização.

5

10

1/09/20

10

Nota 1: como usado nesta norma internacional, estágio relata o progresso e os marcos de progresso da entidade através do ciclo de vida.

Nota 2: estágios podem ser overlapados. Facilidades

Meios físicos ou equipamento para facilitar a realização de uma ação, por exemplo: procedimentos, instrumentos, ferramentas, técnicas etc.

Firmware

A combinação de um dispositivo de hardware e instruções ou dados de computador que residem como um software somente para leitura no dispositivo de hardware. Este software não pode ser diretamente modificado por um programa.

Fornecedor

Organização ou indivíduo que entra em um acordo com o adquirente para o fornecimento de um produto ou serviço.

Nota 1: o “fornecedor” pode ser um empreiteiro, produtor, vendedor ou fornecedor.

Nota 2: às vezes, o adquirente e o fornecedor são parte da mesma organização.

Garantia da qualidade

Conjunto de atividades planejadas e sistemáticas, implementadas no sistema da qualidade e demonstradas como necessárias, para prover confiança adequada

5

10

15

20

1/09/20

10

de que uma entidade atenderá aos requisitos para a qualidade.

Nota 1: tanto interna quanto externamente para fins de garantia de qualidade:

a) garantia da qualidade interna: dentro de uma organização, a garantia da qualidade proporciona confiança para a gestão;

b) garantia da qualidade externa: em situações contratuais, a garantia da qualidade proporciona confiança aos clientes ou outros envolvidos.

Nota 2: algumas ações de controle de qualidade e garantia de qualidade estão interligadas.

Nota 3: a menos que a qualidade não reflita inteiramente as necessidades do usuário, a garantia da qualidade não poderá fornecer proteção adequada confiança.

Implementador

Organização que realize tarefas de implementação. Nota: neste padrão internacional, os termos “desenvolver” e “implementador” são sinônimos.

Item de configuração

Uma entidade dentro de uma configuração que satisfaz uma função de uso final, e que pode ser identificada de forma única em um determinado ponto de referência. Item de software

Código fonte, código objeto, código de controle, data de controle ou uma coleção desses itens.

5

10

15

20

1/09/20

10

Nota: um item de software pode ser visto como um elemento de um sistema, da ISO/IEC 15288:2008.

Item que não será entregue

Hardware ou produto de software cuja entrega não é exigida em contrato, mas pode ser utilizado no desenvolvimento do produto de software.

Linha básica (baseline)

Uma versão formalmente aprovada de um item de configuração, independente de mídia, formalmente definida e fixada em um determinado momento durante o ciclo de vida do item de configuração.

Mantenedor

Uma organização que executa atividades de manutenção. Modelo de ciclo de vida

Uma estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde a definição de seus requisitos até o término de seu uso.

Monitoração

Um exame da situação das atividades de um fornecedor e dos seus resultados, efetuado pelo adquirente ou uma terceira parte.

Operador

Uma entidade que opera o sistema.

5

10

15

20

1/09/20

10

Nota 1: o papel do operador e o papel do usuário podem ser assumidos, simultâneamente ou sequencialmente, pelo mesmo indivíduo ou organização.

Nota 2: no âmbito desta definição específica, a entidade designa um indivíduo ou uma organização.

Organização

Pessoa ou um grupo de pessoas e instalações com um conjunto de responsabilidades, autoridades e relacionamentos.

Nota 1: definição adaptada da ISO 9000:2005.

Nota 2: um grupo de pessoas organizadas para algum objetivo específico, como um clube, sindicato, corporação ou sociedade é uma organização.

Nota 3: uma parte identificada de uma organização (mesmo tão pequena quanto um único indivíduo) ou um grupo identificado organizado pode ser considerado como uma organização se tem responsabilidades, autoridades e relacionamentos.

Nota 4: uma forma de entidade organizacional é frequentemente chamada de uma empresa, por isso os aspectos organizacionais desta norma se aplicam a uma empresa também.

Parceria (parceiros)

Organizações que celebram contrato.

Nota: nesta norma, as partes do contrato são chamadas de adquirente e fornecedor. 5 10 15 20 25

1/09/20

10

Processo

Um conjunto de atividades interrelacionadas, que transforma entradas em saídas. O termo “atividades” engloba a utilização de recursos.

Produto

Resultado da execução de um processo. ISO 9000:2005.

Produto de prateleira

Produto já desenvolvido e disponível para utilização na forma em que se encontra ou com modificação.

Produto de software

Conjunto de programas de computador, procedimentos e dados e documentação associados.

Projeto

Esforço definido para iniciar e terminar as datas empreendidas para criar um produto ou serviço, de acordo com recursos e requisitos específicos.

Nota 1: adaptado de ISO 9000:2005.

Nota 2: um projeto pode ser visto como um processo único, composto por atividades coordenadas e controladas e pode ser composto de atividades do projeto de processos e procedimentos técnicos definidos na presente norma.

5

10

15

1/09/20

10

Propósito de processo

Objetivo de elevado nível de execução do processo e os resultados prováveis da implementação efetiva do processo.

Nota: a implementação do processo deve proporcionar benefícios tangíveis para os participantes.

Qualificação

O processo de demonstrar se uma entidade é capaz de atender aos requisitos especificados.

Recurso

Ativo que é utilizado ou consumido durante a execução de um processo.

Release

Versão particular de um item de configuração que é disponibilizado para um propósito específico (por exemplo: para teste, implantação etc.).

Requisito de qualificação

Um conjunto de critérios ou de condições que, quando atendido, qualifica um produto de software quanto à conformidade das suas especificações e quanto a sua utilização no seu ambiente-alvo.

Segurança

Proteção dos dados e informações de pessoa não autorizada ou sistemas, que não podem ler ou modificá-los. 5 10 15 20 25

1/09/20

10

Serviço

Realização de atividades, tarefas ou direitos associados com o produto.

Sistema

Combinação de elementos em interação organizada para atingir um ou mais propósitos.

Nota 1: um sistema pode ser considerado como um produto ou como os serviços que presta.

Nota 2: na prática, a interpretação do seu significado é frequentemente esclarecida através do uso de um substantivo associativo, por exemplo, sistema da aeronave.

Sistema de permissão

Sistema que dá suporte a um sistema de interesse durante a sua fase do ciclo de vida, mas não contribui diretamente para a sua função durante a operação.

Nota 1: por exemplo, quando um sistema de interesse entra em fase de produção, um sistema de produção de habilitação se torna necessário.

Solicitação de proposta

Documento utilizado pelo adquirente ou cliente como o meio para anunciar sua intenção de adquirir um serviço do sistema especificado, o produto de software ou serviço de software.

5

10

15

1/09/20

10

Stakeholder

Indivíduo ou organização que tem um interesse claro no sistema ou na posse de suas catracterísticas e que deve atender suas necessidades e expectativas.

Tarefa

Exigência, recomendação ou ação permissível que se destina a contribuir para a realização de um ou mais resultados de um processo.

Testabilidade

Medida em que um teste objetivo e factível pode ser projetado para determinar se um requisito é atendido. Unidade de software

Pedaço compilável de software. Usuário

Indivíduo ou grupo de indivíduos que se beneficiam de um sistema durante sua utilização.

Nota: o papel do usuário e o papel do operador podem ser assumidos, simultaneamente ou sequencialmente, no mesmo indivíduo ou organização.

Validação

Confirmação, através da prestação de provas objetivas, que os requisitos para uma determinada utilização ou aplicação foram cumpridos.

[ISO 9000:2005]

5

10

15

1/09/20

10

Nota: num contexto de ciclo de vida, validação é o conjunto de atividades destinadas a assegurar e garantir a confiança de que um sistema é capaz de cumprir sua finalidade, metas e objetivos.

Verificação

Confirmação, através da prestação de provas objetivas, que os requisitos especificados foram cumpridos.

[ISO 9000:2005]

Nota: num contexto de ciclo de vida, é um conjunto de atividades que compara um produto do ciclo de vida contra as características exigidas para esse produto. A verificação pode incluir, mas não está limitada a requisitos, descrição de design e do próprio sistema.

Versão

Instância identificada de um item.

Nota: modificações em uma versão de um produto de software, resultando em uma nova versão, exige uma ação de gestão de configuração.

3.1.3 Categorias de processos do ciclo de vida

Esta normaiInternacional define os grupos de atividades que podem ser realizadas durante o ciclo de vida do software em sete grupos de processo. Cada um dos processos do ciclo de vida dentro desses grupos é descrito em termos da sua finalidade, dos resultados desejados, das atividades e tarefas que precisam ser executadas para atingir esses resultados:

5

10

15

20

1/09/20

10

1. Processos no contexto de sistema a) Processos de acordo (contrato):

- processo de aquisição; - processo de fornecimento; b) Processos organizacionais:

- processo de gerenciamento do modelo de ciclo de vida;

- processo de gerenciamento da infraestrutura; - processo de gerenciamento do portfólio de projetos; - processo de gerenciamento dos recursos humanos; - processo de gerenciamento da qualidade.

c) Processos de projetos:

- processo de planejamento de projeto; - processo de controle e melhoria de projeto; - processo de gerenciamento de decisão; - processo de gerenciamento de riscos;

- processo de gerenciamento de configuração; - processo de gerenciamento de informação; - processo de medição.

d) Processos técnicos:

- processo de definição de requisitos dos stakeholders;

- processo de análise de requisitos de sistemas; - processo de design da arquitetura do sistema;

5

10

15

1/09/20

10

- processo de implementação; - processo de integração de sistema;

- processo de teste e qualificação de sistema; - processo de instalação de software;

- processo de suporte e aceite de software; - processo de operação de software; - processo de manutenção de software;

- processo de eliminação (descarte) de software. 2. Processos específicos de software

a) Processos de software de aplicação:

- processo de implementação de software; - processo de análise de requisitos de software; - processo de design da arquitetura de software; - processo de design detalhado de software; - processo de construção de software; - processo de integração de software;

- processo de teste e qualificação de software. b) Processos de suporte de software support:

- processo de gerenciamento de documentação de software;

- processo de gerenciamento de configuração de software;

- processo de garantia da qualidade de software; - processo de verificação de software;

5

10

15

1/09/20

10

- processo de validação de software; - processo de revisão de software; - processo de auditoria de software;

- processo de resolução de problemas de software. 3. Processos de reuso de software

a) Processos de reuso de software: - processo de engenharia de domínio;

- processo de gerenciamento de ativos reusáveis; - processo de gerenciamento do programa de reuso. Os efeitos e resultados dos processos do ciclo de vida constituem um modelo de referência de processo. O modelo de referência de processo não representa uma abordagem de implementação particular e nem estabelece uma metodologia ou técnicas específicas. Ao contrário, o modelo de referência destina-se a ser adotado por uma organização com base em suas necessidades de negócio e domínio das suas aplicações. O processo definido na organização deve ser adotado pelos projetos da organização no contexto das necessidades do cliente.

Os resultados do processo são utilizados para demonstrar a plena consecução da finalidade de um processo. Isso ajuda o processo de assessoria para determinar a capacidade do processo implementado na organização e ser fonte de material para o plano de melhoria de processos organizacionais.

3.1.4 Processo de gestão da qualidade

Com relação aos processos da qualidade de software, a norma tem como objetivo assegurar que os produtos, serviços e implementações de processos de ciclo de vida de software

5

10

15

20

1/09/20

10

cumpram os objetivos de qualidade organizacional e que levem a satisfação aos clientes.

Como resultado da implementação bem-sucedida do processo de gestão da qualidade, a norma espera que:

• as políticas de organização de gestão da qualidade e procedimentos definidos;

• os objetivos de qualidade da organização são definidos; • a responsabilidade e a autoridade de gestão da qualidade

são definidos;

• o estado de satisfação do cliente é monitorado;

• sejam tomadas medidas adequadas aos objetivos da qualidade, quando estes não forem alcançados.

A organização deve implementar as seguintes atividades e tarefas de acordo com as políticas da organização e procedimentos com respeito ao processo de gestão da qualidade:

1. Gestão da qualidade

Esta atividade consiste das seguintes tarefas:

1.1 A organização deve estabelecer políticas de gestão da qualidade, normas e procedimentos.

Nota 1: um modelo de processo para o sistema de gestão da qualidade pode ser encontrado na norma ISO 9001:2000. Para as organizações que pretendem ir além da ISO 9001:2000, em busca da melhoria contínua do desempenho, são fornecidas orientações da norma ISO 9004:2000.

Nota 2: orientação para a aplicação da ISO 9001:2000 para o software pode ser encontrada na ISO / IEC 90003:2004.

5

10

15

20

1/09/20

10

1.2 A organização deve estabelecer metas de gestão da qualidade e objetivos baseados sobre a estratégia de negócios para a satisfação do cliente.

1.3 A organização deve definir as responsabilidades e autoridade para a implementação da qualidade de gestão.

1.4 A organização deve avaliar a satisfação do cliente e relatá-la.

Nota: a aplicação desta norma estabelece a organização com uma abordagem para a realização da satisfação do cliente.

1.5 A organização deve realizar revisões periódicas dos planos de qualidade de projeto.

Nota: assegurar que os objetivos de qualidade com base nos requisitos das partes interessadas são estabelecidos para cada projeto.

1.6 A organização deve monitorar o status de melhoria da qualidade de produtos e serviços.

2. Gestão da qualidade de ações corretivas Esta atividade consiste das seguintes tarefas:

2.1 A organização deve tomar ações corretivas quando as metas de gestão da qualidade não são alcançadas.

2.2 A organização deve implementar ações corretivas e comunicar os resultados através da organização.

Ainda em relação à qualidade, a norma propõe diversos processos mais específicos dentro dos grupos de processos que

5

10

15

20

1/09/20

10

permeiam as atividades de desenvolvimento de um software, tais como: processo de teste e qualificação de sistema, processo de teste e qualificação de software, processo de garantia da qualidade de software, processo de verificação de software, processo de validação de software e processo de revisão de software.

3.2 Normas da série NBR ISO 9000

As normas da série ISO 9000 descrevem os elementos da garantia da qualidade em termos genéricos, que podem ser aplicados a qualquer negócio independentemente dos produtos e serviços oferecidos. Para se registrar em um dos modelos de sistemas de garantia da qualidade contidos nas normas ISO 9000, o sistema e operações de qualidade da empresa são escrutinados por auditores externos para verificação do atendimento das normas e da efetividade da operação. Após o registro bem-sucedido, a empresa recebe um certificado de um corpo de registro representado pelos auditores. Auditorias de vigilância semestrais garantem a continuidade de conformidade com as normas (Pressman, 2006).

A ISO elaborou normas de aplicação geral neste sentido, que no início foram direcionadas para as áreas de manufatura ou industrial, mas que foram em seguida estendidas a todas as áreas de atividade econômica, dessa forma, essas normas são atualmente aplicadas à indústria e ao setor de serviços de todas as naturezas. A série ISO 9000 é composta de:

a) NBR ISO 9000 – normas de gestão da qualidade e garantia da qualidade. Diretrizes para seleção e uso. Apoia as empresas na seleção da norma mais apropriada para seu negócio e na sua utilização.

b) NBR ISO 9001 – sistemas da qualidade. Modelo de garantia da qualidade em projeto, desenvolvimento,

5 10 15 20 25 30

1/09/20

10

produção, instalação e assistência técnica. É a norma mais geral da série e pode ser aplicável a qualquer empresa ou atividade.

c) NBR ISO 9002 – sistemas da qualidade. Modelo para a garantia da qualidade em produção e instalação. Para empresas que não têm atividades de desenvolvimento. d) NBR ISO 9003 – sistemas da qualidade. Modelo para

garantia da qualidade em inspeção e ensaios em geral. Norma restrita à área de inspeção e testes.

e) NBR ISO 9004 – gestão da qualidade e elementos do sistema da qualidade. Diretrizes. Documento que traz orientações gerais para a implantação de gestão da qualidade.

Para especificamente a área de software, a ISO desenvolveu o guia ISO 9000-3 (diretrizes para aplicação da ISO 9001), ao projeto, desenvolvimento, fornecimento, instalação e manutenção de software. Outra norma para aplicação no desenvolvimento de software é a ISO 12207, que trata dos processos do ciclo de vida de software e tem muitos pontos de contato comuns com a ISO 9000-3. Todas essas normas foram adaptadas pela NBR que manteve os mesmos nomes da ISO.

3.2.1 Norma NBR ISO 9000-3 – projeto, desenvolvimento, fornecimento, instalação e manutenção de software

De acordo com ABNT com relação a NBR ISO 9000-3, o processo de desenvolvimento e manutenção de software é diferente dos demais tipos de produtos industriais, tornando-se necessário prover, nesse campo da tecnologia de desenvolvimento tão rápido, orientações adicionais para o estabelecimento de sistemas de qualidade em que estejam envolvidos os produtos de software, levando-se em conta o estágio atual da tecnologia.

5 10 15 20 25 30

1/09/20

10

3.2.1.1 Termos e conceitos utilizados na norma

A norma NBR ISO 9000-3 define e conceitua os seguintes termos que serão utilizados em seu texto:

• Software: Criação intelectual compreendendo os programas, procedimentos, regras e qualquer documentação correlata à operação de um sistema de processamento de dados.

• Produto de software: conjunto completo de programas de computador, procedimentos e documentação correlata, assim como dados designados para entrega a um usuário.

• Desenvolvimento: todas as atividades a serem realizadas para a criação de um produto de software.

De acordo com a norma, os softwares raramente são submetidos a avaliações formais de qualidade, existindo poucas ações tomadas nessa área, ficando normalmente a qualidade do software dependente das habilidades dos profissionais envolvidos no sistema. Como consequência da pouca atenção dispensada à qualidade do software, mais de 50% do tempo e custos empregados no desenvolvimento de um software se concentram em atividades de teste e manutenção (para ser conservador).

Estamos certos de que o levantamento e a especificação corretos das necessidades ou requisitos dos usuários, dos objetivos da qualidade e dos critérios de aprovação devem reduzir o tempo de desenvolvimento, diminuir custos e por consequência aumentar a lucratividade e a competitividade das empresas de softwares. Os profissionais da área devem se conscientizar de que é necessário uma busca contínua da melhora da qualidade do software, principalmente com a abertura do mercado brasileiro e a chegada do software importado, desenvolvido para usuários com níveis de exigências

5 10 15 20 25 30

1/09/20

10

3.2.1.2 Qualidade de processos

A 9000-3 apresenta diretrizes para aplicação da ISO-9001, ao desenvolvimento, fornecimento e manutenção de software. Ela se aplica aos casos em que existe um contrato formal entre fornecedor e cliente. As diretrizes da ISO-9000-3 cobrem questões como:

• entendimento comum dos requisitos funcionais pelo contratante e contratada;

• uso de metodologia de desenvolvimento de software desde a concepção até a instalação do software;

• metodologia de gerenciamento do projeto. Ela encontra-se dividida em três partes principais: • estrutura do sistema da qualidade;

• atividades do ciclo de vida do software; • atividades de suporte.

3.2.1.3 Estrutura do sistema de qualidade (quality framework)

A ISO-9000-3 descreve as responsabilidades e ações relacionadas à qualidade que devem ser tomadas tanto pelo fornecedor de software como pelo cliente, ao longo das fases do ciclo de vida do software. A aplicação da norma deve propiciar aos fornecedores de software uma política de qualidade formal e documentada, divulgada e compreendida por todos os funcionários.

Esses funcionários precisam ter como parte do trabalho a responsabilidade e a autoridade suficientes para implementar essas políticas. A empresa deve possuir pessoas e recursos para verificar, de forma independente, o emprego correto de suas

5

10

15

20

1/09/20

10

políticas de qualidade. O executor não pode ser seu próprio auditor. A auditoria deve estar a cargo de um setor, de um grupo interno de qualidade ou de uma empresa independente de auditoria especializada.

São quatro os pontos cobertos pelo capítulo da norma que trata da estrutura do sistema da qualidade:

• estabelecimento de responsabilidades gerenciais;

• definição e documentação do próprio sistema da qualidade; • procedimentos para auditoria interna do sistema da

qualidade;

• procedimentos para ações corretivas.

3.2.1.4 Atividades do ciclo de vida do software

O ciclo de vida de um projeto de desenvolvimento de um software é normalmente dividida em fases, etapas e atividades. Existem diversas alternativas de organização do ciclo de vida do desenvolvimento de software, mas basicamente todas elas se encaixam na estrutura abaixo:

• Fase 1 – estudo preliminar (definição do escopo do sistema – requisitos).

• Fase 2 – análise ou especificação do sistema (detalhamento ou elaboração das funcionalidades). • Fase 3 – design ou estruturação física do sistema. • Fase 4 – programação ou construção.

• Fase 5 – implantação ou liberação para produção. • Fase 6 – manutenção.

O sistema da qualidade deve atuar sobre todo o ciclo de vida do software e a qualidade deve ser buscada em cada atividade

5

10

15

20

1/09/20

10

do ciclo de vida e não simplesmente avaliada no final. A norma, independentemente do modelo ou metodologia adotada pela empresa, prevê que as atividades do ciclo podem ser agrupadas em nove grandes categorias:

1. Análise crítica de contrato (contract review)

Aborda os itens padrões que devem constar nos contratos relativos a compra e venda de software:

• abrangência do trabalho; • contigências;

• proteção de informações proprietárias.

2. Especificação de requisitos do comprador (purchaser’s requirements specification)

Trata das especificações de requisitos funcionais que devem ser preparados em conjunto pelo comprador e fornecedor e deve incluir aspectos de:

• perfomance; • confiabilidade; • segurança; • privacidade.

3. Planejamento do desenvolvimento (development planning)

Enfatiza a necessidade e define um plano de desenvolvimento do software. O plano deve incluir:

• a definição do projeto; • organização dos recursos; • fases do desenvolvimento; 5 10 15 20 25

1/09/20

10

• cronogramas; • plano de testes.

Devem ser também contempladas no plano as formas de controle de entrada e saída para cada fase do ciclo de vida e um método de monitorar e verificar o progresso.

4. Planejamento da qualidade (quality planning)

Trata da elaboração de um plano da qualidade específico para o projeto em desenvolvimento e deve englobar itens especiais não cobertos pelo sistema da qualidade geral da empresa.

O plano da qualidade deve tratar dos objetivos de qualidade do produto de software em desenvolvimento, tais como: redução do reprocessamento, redução do número de chamadas da assistência técnica, redução do número de horas de treinamento.

Deve também tratar dos critérios de saída de cada fase e entrada na seguinte, planejamento detalhado de atividades de verificação e validação (homologação de produtos das fases) e responsabilidades específicas para as atividades da qualidade (matriz de responsabilidades).

5. Projeto e implementação (design e implementation) Preconiza uma análise e projeto de software disciplinado, onde comprador e fornecedor concordam previamente com o conjunto de informações que serão fornecidas ao comprador pelo software.

O fornecedor deve usar uma metodologia sistemática, que envolva o comprador o máximo possível nestas

5

10

15

20

1/09/20

10

fases e, dentro do possível, valer-se da experiência passada.

O projeto deve considerar as futuras manutenções e aderir às regras e padrões da empresa quanto às confecções da interface homem/máquina e quanto ao uso dos ambientes de programação.

6. Teste e certificação (test and validation)

Define a necessidade de teste e homologação do software em vários níveis. Um plano de testes deve ser montado cobrindo:

• ambiente; • documentação;

• cases de teste e dados;

• simulação do sistema completo; • testes de campo.

7. Aceitação (acceptance)

Cobre os termos acordados previamente e condições impostas pelo comprador para aceitação do produto. São abordadas questões como: testes de aceitação, procedimentos para avaliação. Ambientes e recursos de software e hardware são definidos nessa categoria. 8. Reprodução, expedição e instalação ( replication,

delivery and installation)

Trata do registro de considerações relativas ao número de cópias, tipo do meio físico utilizado, direitos autorais e licenças, critérios de envio e obrigações do fornecedor e do comprador ligadas à instalação do software desenvolvido. 5 10 15 20 25

1/09/20

10

9. Manutenção (maintenance)

Trata a manutenção como uma questão da qualidade, onde esse serviço é incluso no contrato de compra. Serviços de manutenção normalmente envolvem :

• mudanças no software; • solução de problemas; • correção de defeitos; • modificação de interfaces; • melhorias de desempenho; • expansões funcionais.

A norma propõe a existência de um plano de manutenção, documentação e critérios de liberação em função da incorporação de alterações no software.

3.2.1.5 Atividades de suporte

As atividades de suporte não se encontram atreladas a uma determinada fase do ciclo de vida do software, elas permeiam todas as fases. As atividades de suporte compreendem nove itens, os quais devem ser desenvolvidos e implementados pelo fornecedor do software:

1. Sistema de gestão da configuração

• Gestão de configuração significa identificação, rastreamento e controle de alterações do software. • O sistema de gestão da configuração deve fornecer

um mecanismo para controle e rastreamento do software e seus componentes, de modo que seja possível: 5 10 15 20 25

1/09/20

10

- identificar cada versão;

- controlar a atualização simultânea do software por mais de uma pessoa; - rastrear e identificar todas as alterações resultantes de um pedido de alteração. 2. Controle de documentos

Estabelece que o fornecedor deve manter procedimentos para controlar toda a documentação relacionada à qualidade do software. A norma define os documentos mínimos que devem ser controlados:

• descrição do sistema de qualidade ao longo do ciclo de vida do software;

• documentos de planejamento das atividades do fornecedor e de suas interações com o cliente; • os documentos relacionados ao produto em si. 3. Registros da qualidade

Define que o fornecedor deve manter formas para identificar, coletar, indexar, arquivar, armazenar, manter e dispor dos registros da qualidade, de forma que sejam rapidamente recuperáveis.

4. Medição

Este item trata das métricas e das técnicas de medição estabelecidas para realizar as medições nos produtos e nos processos desde o desenvolvimento até a produção. Apesar da norma reconhecer que não existe indicadores de qualidade de software aceitos universalmente, adverte que deve ser usado algum tipo de indicador para expressar falhas e/ou defeitos que façam sentido do ponto de vista do cliente. 5 10 15 20 25

1/09/20

10

Exemplos de indicadores propostos pela norma:

• número de falhas por dias de uso efetivo do software;

• tempo médio de reparo de problema (MTTR – Medium Time To Repair);

• tempo médio entre duas falhas consecutivas (MTBF – Medium Time Between Failures);

• número de problemas com solução pendente. 5. Regras, práticas e convenções

Estipula que cada fornecedor de software deve definir suas regras, práticas e convenções. Essas regras, práticas e convenções devem ser tal forma que tornem efetivo o sistema de qualidade estipulado na ISO-9000-3.

6. Ferramentas e técnicas

Impõe como responsabilidade do fornecedor a utilização de ferramentas, recursos e técnicas de sua escolha que garantam a efetividade das diretrizes das normas.

7. Aquisição

A norma aborda a avaliação se o hardware, serviços e ferramentas de desenvolvimento necessários para compor o produto final estão de acordo com os requisitos especificados, como forma de garantir a sua qualidade. 8. Produto para ser incluído no software

Trata dos cuidados relativos à qualidade no uso de partes de softwares do próprio comprador ou de terceiros, que serão integradas para compor o software contratado e em desenvolvimento. 5 10 15 20 25

1/09/20

10

9. Treinamento

Apresenta a responsabilidade do fornecedor relativa à identificação das necessidades de treinamento, visando à qualificação do próprio pessoal ou do cliente, visando ao preparo de quem executa tarefas que possam influenciar na qualidade.

3.3 Norma NBR ISO/IEC 9126-1 2003 – engenharia de software – qualidade de produto

De acordo com a norma NBR ISO/IEC 9126-1, os computadores têm sido usados numa variedade de áreas de aplicação cada vez maior e sua correta operação é frequentemente crítica para o sucesso de negócios e para a segurança humana. Deste modo, desenvolver ou selecionar produtos de software de alta qualidade é de primordial importância. Especificação e avaliação da qualidade do produto de software são fatores-chave para garantir a qualidade adequada. Isto pode ser alcançado pela definição apropriada das características de qualidade, levando em consideração o uso pretendido do produto de software. É importante que cada característica relevante de qualidade do produto de software seja especificada e avaliada utilizando, quando possível, métricas validadas ou amplamente aceitas.

A norma tem como objetivo permitir que a qualidade do produto de software seja especificada e avaliada em diferentes perspectivas pelos envolvidos com aquisição, requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia de qualidade e auditoria de software. Pode ser utilizada por desenvolvedores, adquirentes, pessoal de garantia de qualidade e avaliadores independentes, particularmente os responsáveis por especificar e avaliar qualidade do produto de software. 5 10 15 20 25

1/09/20

10

3.3.1 Diretrizes para uso da norma NBR ISO/IEC 9126-1 De acordo com Guerra & Colombo (2009), esta norma pode ser aplicada na avaliação da qualidade nos seguintes momentos ou situações:

• definição dos requisitos de qualidade de um produto de software;

• avaliação da especificação de software para verificar se ele irá satisfazer aos requisitos de qualidade durante o desenvolvimento;

• descrição de particularidades e atributos do software implementado, por exemplo, em manuais de usuário; • avaliação do software desenvolvido, antes da entrega; • avaliação do software desenvolvido, antes da aceitação. 3.3.2 Características da qualidade da norma NBR ISO/IEC 9126-1

A norma apresenta seis características de qualidade para um software, conforme Côrtes & Chiossi (2001):

1. Funcionalidade

Conjunto de funções especificadas para atender aos requisitos do cliente/usuário. Este conjunto de funções caracteriza o que o software deve fazer para satisfazer às necessidades do cliente/usuário.

A funcionalidade pode ser ainda desdobrada nas subcaracterísticas:

• adequação: que significa a garantia de que o software possui as funções que foram especificadas;

5

10

15

1/09/20

10

• conformidade: se os produtos de software foram desenvolvidos observando os padrões, convenções ou regras estabelecidas no projeto;

• acurácia: o produto de software gera resultados precisos ou dentro dos limites esperados;

• segurança de acesso: capacidade do produto de software de prevenir acessos por pessoas ou aplicações não autorizados;

• interoperabilidade: capacidade de interagir com outros sistemas, de acordo com as especificações. 2. Confiabilidade

Medida da capacidade do software de manter seu nível de desempenho dentro de condições estabelecidas entre as partes em um período de tempo.

A confiabilidade pode ser ainda desdobrada nas subcaracterísticas:

• maturidade: indicação de baixa frequência de falhas ou defeitos do produto de software em operação; • tolerância a falhas: indicação que o produto de

software pode manter determinados níveis de desempenho mesmo quando se apresentarem problemas na sua execução;

• recuperabilidade: o produto de software possui capacidade para reestabelecer o nível de desempenho preestabelecido e garantir a recuperação das bases de dados em caso de ocorrência de falhas.

3. Usabilidade

Medida do esforço necessário para o uso do software por um usuário de perfíl determinado de forma explícita

5

10

15

20

1/09/20

10

ou implicitamente. A usabilidade de um software está ligada aos conceitos de ergonomia entre o homem e o computador.

A usabilidade pode ser ainda desdobrada nas subcaracterísticas:

• inteligilidade: medida da facilidade do usuário para reconhecer a lógica de funcionamento do produto e sua aplicação;

• apreensibilidade: medida da facilidade encontrada pelo usuário para aprender a utilizar o produto; • operacionalidade: medida da facilidade para operar

o produto. 4. Eficiência

Determinação da quantidade de recursos utilizada pelo software com relação ao seu desempenho, sob condições de uso preestabelecidas.

A eficiência pode ser ainda desdobrada nas subcaracterísticas: • comportamento com relação ao tempo: medida

do tempo de resposta e de processamento, assim como as taxas de saídas ao executar as funções especificadas;

• comportamento com relação ao uso de recursos: medida da quantidade de recursos necessários (CPU, disco, rede e memória, dentre outros) e a duração do seu uso ao executar as funções especificadas. 5. Manutenibilidade

Medida do esforço necessário (homens/hora) para fazer alterações no software. 5 10 15 20 25

1/09/20

10

A manutenibilidade pode ser ainda desdobrada nas subcaracterísticas:

• analisibilidade: medida do esforço necessário para diagnosticar deficiências, localizar as partes para corrigir os problemas;

• modificabilidade: medida do esforço necessário para remover falhas ou para adequar o produto a eventuais mudanças na tecnologia ou no ambiente operacional;

• estabilidade: medida do risco de efeitos inesperados provenientes de modificações no produto de software;

• testabilidade: medida do esforço necessário para testar o produto de software alterado.

6. Portabilidade

Medida da facilidade de transferir o produto de software de um ambiente operacional para outro diferente.

A portabilidade pode ser ainda desdobrada nas subcaracterísticas:

• adaptabilidade: medida da facilidade de se adaptar o produto de software para funcionar em outros ambientes operacionais;

• facilidade de instalação: medida do esforço necessário para se instalar o produto de software; • capacidade de coexistir: medida do nível de

conformidade do produto de software com padrões referentes à portabilidade;

• facilidade para substituir: medida do esforço necessário para usar o produto em substituição a outro produto, previamente especificado.

5 10 15 20 25 30

1/09/20

10

3.3.3 Visões da qualidade de software da norma NBR ISO/ IEC 9126-1

A norma apresenta três visões da qualidade de software: a visão do usuário, a visão do desenvolvedor e a do gerente de desenvolvimento.

Com relação à visão do usuário, ela discute o interesse do mesmo com relação ao funcionamento do produto de software, no seu desempenho e nos efeitos do seu uso. A norma com relação ao usuário se preocupa com as medidas externas da qualidade, tais como: nas funções que estão disponíveis, na confiabilidade, na facilidade de uso e na portabilidade caso ele necessite trocar de ambiente operacional.

Já quanto à visão do desenvolvedor, a norma se preocupa com a qualidade dos requisitos e na aceitação do produto pelo cliente/usuário. Para que o desenvolvedor dê essas garantias, ele verifica a qualidade dos produtos intermediários através de técnicas da qualidade (verificação, revisão e testes) e usa as chamadas medidas internas. O desenvolvedor deve se preocupar também com as expectativas da qualidade das pessoas que irão dar manutenção no produto do software no futuro.

Com relação à visão do gerente de desenvolvimento, a norma propõe que o mesmo se preocupe em uma medida de qualidade geral para obter uma visão mais próxima dos objetivos do projeto e do produto de software em consonância com os objetivos do negócio da empresa. Ele deve balancear as melhorias da qualidade do produto com a garantia da execução dos cronogramas, previsões de custo e uso adequado dos recursos necessários.

A norma propõe o uso de métricas para se medir as seis características da qualidade de produto de software, todavia ela não apresenta estas métricas e sugere que cada organização

5 10 15 20 25 30

1/09/20

10

desenvolva as suas próprias métricas e seus próprios processos de medição.

A norma, no entanto, define um processo de avaliação da qualidade de produto de software a partir das seis características definidas na própria norma. O processo de avaliação proposto parte da definição dos requisitos da qualidade, aborda a preparação da avaliação e encerra com a avaliação propriamente dita.

3.4 Conclusão

Este capítulo apresentou os conceitos da qualidade de processo e produto de software sob o ponto de vista das normas da série ISO 9000, ISO/IEC 12207 IEEE Std 12207-2008 e NBR ISO/IEC 9126-1. Diversos autores foram utilizados para dar uma visão resumida e abrangente dessas normas. Foram detalhadas as seis características da qualidade de um produto de software e as visões da qualidade por parte do usuário, do desenvolvedor e do gerente de desenvolvimento.

5

10