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 1 SUMÁRIO 1 Proposições da qualidade de software:...................................................................................... 4 2 Princípios de qualidade:............................................................................................................. 5 3 Princípios de gerência:............................................................................................................... 5 4 Princípios de engenharia:........................................................................................................... 5 1 II. -HISTÓRICO DA QUALIDADE......................................................................................... 5 2 III. - PORQUÊ SE PREOCUPAR COM A QUALIDADE DE SOFTWARE ?....................... 7 2.1 ................................................................................................................................................... 2.2 Qualidade x Definição de pré-requisitos................................................................................... 7 2.3 Qualidade e o desenvolvimento software.................................................................................. 8 3 IV. - QUALIDADE E SERVIÇO DE SUPORTE AO USUÁRIO............................................. 8 3.1 O que é um Sistema de Qualidade ?.......................................................................................... 9 3.2 Qualidade Produto x Qualidade Processo.................................................................................. 10 4 VI. - QUALIDADE DE SOFTWARE:...................................................................................... 11 4.1 Engenharia de Software............................................................................................................. 12 4.2 Qualidade de Produtos de Software - ISO 9126........................................................................ 13 5 VII - MÉTRICAS DE SOFTWARE.......................................................................................... 14 5.1 Estrutura do Sistema de Qualidade............................................................................................ 19 6 XIII – GERENCIANDO UM COMPANHIA DE QUALIDADE............................................. 22 6.1 Dedicação à satisfação do cliente.............................................................................................. 22 6.2 Dar ênfase à melhoramentos contínuos..................................................................................... 22 6.3 Tratar fornecedores como parceiros de negócios....................................................................... 22 6.4 Comunicação e time de trabalho................................................................................................ 22 6.5 Atualizando empregados............................................................................................................ 23 6.6 Compromisso da gerência ......................................................................................................... 23 7 XIV. – IMPLEMANTANDO UM SISTEMA DE QUALIDADE............................................. 23 7.1 XIV.1 - UM SISTEMA DE QUALIDADE............................................................................... 23 7.1.1 Aspectos Técnicos..................................................................................................................... 23 7.1.2 Aspectos culturais...................................................................................................................... 23 7.2 XIV.2 – INICIANDO UM SISTEMA DE QUALIDADE......................................................... 24 7.2.1 Preparar uma política de qualidade............................................................................................ 24 7.2.2 Estabelecer uma equipe de suporte em qualidade..................................................................... 24 7.3 XIV.3 - DEFINIR UM PROGRAMA PARA A QUALIDADE................................................. 24 7.3.1 Avaliar a organização................................................................................................................. 24 7.3.2 Projetar um sistema de qualidade.............................................................................................. 25 7.3.3 Planejamento e implementação do programa de qualidade....................................................... 25 7.4 XIV.4. - IMPLEMENTAR UM PROGRAMA CULTURAL.................................................... 26 7.5 XIV.5 - IMPLEMENTAR O PROGRAMA TÉCNICO............................................................. 27 7.5.1 Adotar um ciclo de vida............................................................................................................. 27 7.5.2 Programa de métricas e medidas de software............................................................................ 27 7.5.3 Desenvolvimento....................................................................................................................... 28 7.5.4 Suporte....................................................................................................................................... 28 7.5.5 Treinamento............................................................................................................................... 28 7.6 XIV.6 – REVISÕES DE PROCESSOS E PRODUTO.............................................................. 28 7.6.1 Revisões do projeto.................................................................................................................... 29 7.6.2 Revisões da gerência.................................................................................................................. 29 8 XV. – O FUTURO DA QUALIDADE...................................................................................... 29 9 ................................................................................................................................................... 10 XVI. - BIBLIOGRAFIA............................................................................................................ 30 2 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 5 foi ouvido em sua terra, não foi profeta em sua terra e este "não ouvir Deming" vai custar caro aos americanos, porque em pouco tempo vão perder os maiores mercados do mundo. O Japão, em 1950, convida Deming a fazer uma série de palestras para a J.U.S.E. Hoje esta é uma sigla famosa, que significa União Japonesa de Cientistas e Engenheiros. A JUSE foi responsável pela revolução que o Japão conseguiu implementar. Deming também foi convidado pela Associação Japonesa da Alta Administração, que é composta pelos 45 maiores industriais japoneses. Isto Significava que o maior poderio privado, 89% do dinheiro privado japonês, estava ai, nesses 45 industriais. Deming ensinou seu método e, também, aperfeiçoou-o, desenvolvendo uma nova forma participativa de gerência, a qual tirava proveito dos conhecimentos e habilidades de todos funcionários, em todos os níveis, por meios de equipes e sistemas de sugestões que sempre focalizam o cliente. A psicologia das relações humanas traz o conhecimento do comportamento dos funcionários das organizações e diferente teorias, a da motivação e personalidade de A. Maslow, contribuem com estudos do fator humano, preocupando-se em considerar a satisfação do funcionário como um dos responsáveis pelo aumento da produtividade e de qualidade do produto .A teoria motivação-higiene de Herzberg distingue os fatores do ambiente ( fisiológicos, segurança, social, estima) como fatores provenientes especificamente do serviço ( automatização), mostrando serem esses últimos os motivadores. Em 1980 começam de forma oficial, nas organizações americanas, ao grandes programas de Qualidade. A primeira organização a que Deming atende é a FORD. Os Estados Unidos buscaram, além de Deming outros grandes idealizadores deste processo: J.M. JURAN, PHILIP CROSBY, os famosos gurus da Qualidade também chamados pensadores da Qualidade, que começa a dar consultoria para os Estados Unidos sobre Qualidade Total ou Liderança pela Qualidade. 6 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. 7 • 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-9000 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 10 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: 11 Norma Comentário ISO 9126 Características da qualidade de produtos de software. NBR 13596 Versão brasileira da ISO 9126 ISO 14598 Guias para a avaliação de produtos de software, baseados na utilização prática da norma ISO 9126 ISO 12119 Características de qualidade de pacotes de software (software de prateleira, vendido com um produto embalado) IEEE P1061 Standard for Software Quality Metrics Methodology (produto de software) ISO 12207 Software Life Cycle Process. Norma para a qualidade do processo de desenvolvimento de software. NBR ISO 9001 Sistemas de qualidade - Modelo para garantia de qualidade em Projeto, Desenvolvimento, Instalação e Assistência Técnica (processo) NBR ISO 9000-3 Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para o processo de desenvolvimento de software. NBR ISO 10011 Auditoria de Sistemas de Qualidade (processo) CMM Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de Software do Departamento de Defesa dos USA) para avaliação da qualidade do processo de desenvolvimento de software. Não é uma norma ISO, mas é muito bem aceita no mercado. SPICE ISO 15504 Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software. Ainda não é uma norma oficial ISO, mas o processo está em andamento. Engenharia de Software A disciplina que nos ajuda a entender o processo de desenvolvimento de software é a Engenharia de Software. É através dela que poderemos chegar à qualidade. Existe, entretanto, um grande problema a ser resolvido: tecnicamente, ela não existe. O problema é que, para que uma disciplina seja considerada realmente uma Engenharia, é necessário atender a alguns requisitos básicos que a Engenharia de Software, pelos menos até agora, não atende. A seguir a definição de Engenharia: "A Engenharia deve criar soluções com uma relação custo-benefício adequada para problemas práticos, pela aplicação de conhecimentos científicos, para construir coisas a serviço da humanidade" Dentro destes conceitos, a Engenharia de Software falha principalmente no que diz respeito à adequação do custo-benefício e à aplicação, em toda a sua extensão, de conhecimentos científicos. Atualmente, estes requisitos são atendidos apenas em parte. É necessário definir, portanto, o que é exatamente a Engenharia de Software. A seguir algumas tentativas de definição: "...é a disciplina que integra métodos, ferramentas e procedimentos para o desenvolvimento de software para computadores." "...é uma coleção de processos de gerenciamento, ferramental de software e atividades de projeto para o desenvolvimento de software. " "...é um termo usado para referir-se a modelos de ciclo de vida, metodologias de rotina, técnicas de estimativa de custo, estruturas de documentação, ferramentas de gerenciamento 12 métricas externas (relativas ao uso do produto) e métricas internas (relativas à arquitetura do produto). A seguir algumas das modificações previstas para esta revisão: Algumas novas subcaracterísticas: Conformidade fará parte de todas as características. Atratividade será uma subcaracterística de Usabilidade. Capacidade de coexistir será uma subcaracterística de portabilidade. A norma será dividida em três partes. A primeira (9126-1) incluirá definições e características. As duas seguintes descreverão métricas externas (9126-2) e internas (9126-3). A versão brasileira da revisão desta norma deverá ser chamada de NBR 9126-1, 9126-2 e 9126-3, segundo a numeração original da ISO/IEC. VIII - GUIAS PARA AVALIAÇÃO DA QUALIDADE - ISO 14598 Nota-se a necessidade de mais detalhes sobre como avaliar a qualidade de um software. As características e subcaracterísticas da norma ISO/IEC 9126 apenas começaram o trabalho. Faltava definir, em detalhes, como atribuir um conceito para cada item. Afinal, sem uma padronização, que valor teria uma avaliação? A ISO, consciente deste problema, está finalizando o trabalho em um conjunto de Guias para a Avaliação da Qualidade segundo a norma ISO/IEC 9126. Estes guias descrevem, detalhadamente, todos os passos para que se avalie um software. Embora o trabalho nesta norma ainda não esteja totalmente pronto, já existem informações detalhadas sobre o que será esta norma, quando for oficialmente publicada. Esta nova norma trará muitos recursos interessantes aos avaliadores, já que trata o processo de avaliação em grande detalhe. Ela leva em conta a existência de três grupos interessados em avaliar um software, o que define os três tipos básicos de certificação: Certificação Quem realiza Finalidade de 1a. parte Empresas que desenvolvem software Melhorar a qualidade de seu próprio produto de 2a. parte Empresas que adquirem software Determinar a qualidade do produto que irão adquirir de 3a. parte Empresas que fazem certificação Emitir documento oficial sobre a qualidade de um software Esta norma se constituirá, na verdade, de seis documentos distintos, relacionados entre si, como demonstrado a seguir: Norma Nome Finalidade 14598-1 Visão Geral Ensina a utilizar as outras normas do grupo 14598-2 Planejamento e Gerenciamento Sobre como fazer uma avaliação, de forma geral 14598-3 Guia para Desenvolvedores Como avaliar sob o ponto do vista de quem desenvolve 15 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. 16 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 17 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. 20 Infra-estrutura Fornecimento de recursos para outros processos. Inclui: hardware, software, ferramentas, técnicas, padrões de desenvolvimento, operação ou manutenção. Melhoria Atividades para estabeler, avaliar, medir, controlar e melhorar um processo de ciclo de vida de software. Treinamento Atividades para prover e manter pessoal treinado. A norma detalha cada um dos processos acima. Ela define ainda como eles podem ser usados de diferentes maneiras por diferentes organizações (ou parte destas), representando diversos pontos de vista para esta utilização. Cada uma destas visões representa a forma como uma organização emprega estes processos, agrupando-os de acordo com suas necessidades e objetivos. As Visões têm o objetivo de organizar melhor a estrutura de uma empresa, para definir suas gerências e atividades alocadas às suas equipes. Existem cinco visões diferentes: contrato, gerenciamento, operação, engenharia e apoio. Na figura abaixo se encontra como estas visões se relacionam aos processos. A ISO/IEC 12207 é a primeira norma internacional que descreve em detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de software. A principal finalidade desta norma é servir de referência para os demais padrões que venham a surgir. Lançada em agosto de 1995, ela é citada em quase todos os trabalhos relacionados à Engenharia de Software desde então, inclusive aqueles relativos à qualidade. A futura norma ISO 15504 (SPICE), por exemplo, organiza seu trabalho segundo o que está descrito na 12207. A versão brasileira da norma foi encaminhada para votação na ABNT em junho de 1997 e a expectativa da comissão encarregada da tradução é que ela se transforme em norma brasileira ainda em 1997. 21 XIII – GERENCIANDO UM COMPANHIA DE QUALIDADE Gerenciar uma companhia de qualidade é mais do que implementar um sistema de qualidade consistindo de um conjunto de técnicas do padrão Iso. É a criação da “cultura da qualidade” que permeia toda a organização. A seguir, mostraremos algumas idéias práticas que podem vir a ajudar na realização de trabalho com mais qualidade. Dedicação à satisfação do cliente Qualidade fala sobre a satisfação do cliente. Produzir um produto de qualidade é uma parte importante para garantir a satisfação e atenção do cliente. Isto inclui: • Esforçar-se ao máximo para entender as necessidades do cliente no produto e no suporte; • Escrever um contrato que reflitas estas necessidades; • Prever suporte pós-venda para igualar requisitos ou expectativas; • Vigiar os contatos com os clientes. A primeira impressão é a que fica. Dar ênfase à melhoramentos contínuos O fim da qualidade total nunca será alcançado, será sempre possível fazer as coisas um pouco melhor ou mais rápido. A melhor coisa a ser feita é fazer a organização se tornar uma “Organização do aprendizado” que constantemente pesquisa e renova recursos e experiências de todo o pessoal envolvido para aumentar a qualidade, reduzir custos e responder rapidamente às necessidades dos clientes. Tendo se tornado uma organização do aprendizado, aprenda como aprender mais rápido do que os concorrentes. Tratar fornecedores como parceiros de negócios Esta filosofia de parceiros de negócios pode ser estendida a outros com uma participação no sucesso do seu negócio. As empresas de desenvolvimento devem considerar que seus agentes e distribuidores devem ser considerados como parceiros do negócio para benefício mútuo. E o mesmo pode ser aplicado a grandes consumidores, que estão procurando relacionamentos. Decisões em negócios de parcerias não tem razões idealistas, mas têm no gerenciamento do negócio a luz da realidade estratégica e comercial. Eles refletem o fato de o negócio não ser uma coisa qualquer e que é geralmente em seu próprio interesse promover o sucesso dos outros. Em outras palavras é criada uma situação “Vencedor- Vencedor”. Comunicação e time de trabalho É importante criar uma cultura na empresa no qual indivíduos e departamentos pensem que eles mesmos são seus próprios consumidores dentro da organização. Este supridores internos tentam entender e suprir as necessidades de seus consumidores internos e estes trabalham com seus supridores internos para ajudá-los. 22 Esta organização vai entrar dentro da empresa e começar a verificar e definir padrões e regras que devem ser cumpridas para se conseguir o certificado. Esta organização que estará sendo avaliada, vai reorganizar-se de acordo com as normas a serem ditadas. As normas podem variar de acordo com a necessidade da empresa e ser aplicado padrões internacionais, tais como ISO 9000 ou CMM , Projetar um sistema de qualidade Nesta parte da implementação, a empresa vai definir quais os seus objetivos perante a qualidade que se quer alcançar. Alguns dos objetivos mais comuns que as empresas querem para se adaptar ao mercado, é: • Reduzir o número de erros e defeitos encontrados na fase de teste e na implantação do software; • Aumentar a produtividade; • Reduzir o tempo de desenvolvimento; • Diminuir o tempo de resposta às requisições do cliente; • Melhorar as estimativas de custo e agendamento de tarefas para se entregar ao usuário; • Alcançar a certificação necessária. Todos os objetivos e partes do projeto devem ser colocados em um manual que, mais tarde deverá conter todas as resoluções que foram feitas durante todo o projeto. Este “Manual da Qualidade” deverá, depois de pronto, ser publicado para todas as pessoas da empresa para entendimento e retirada de dúvidas. Neste manual, poderá conter: • A política de qualidade e objetivos da empresa; • A estrutura da organização mostrando as responsabilidades de todos que gerenciam, fazem e verificam o trabalho que afetará a qualidade; • Uma descrição do ciclo de vida da qualidade na empresa (será visto mais à frente); • Uma visão geral do sistema de qualidade; • relacionamento do sistema de qualidade com o padrão internacional adotado; • Referência completa a procedimentos e padrões detalhados. Planejamento e implementação do programa de qualidade Após a conclusão do “Manual de Qualidade” e sua aprovação pelo pessoal da empresa, a comissão de organização da qualidade determinará a quantidade de serviço que deverá ser necessário para implementar o programa de qualidade. A comissão deverá desenvolver um plano de implementação detalhando tarefas, atividades, marcos e recursos para a implantação. Normalmente, as tarefas mais comuns a serem realizadas são as seguintes: • implementar um programa cultural; • Adotar um ciclo de vida; 25 • Desenvolver um sistema de controle de qualidade; • Desenvolver e documentar procedimentos e padrões para todas as atividades de cada ciclo da implementação; • Definir e implementar um programa de medidas; • Rever e, se necessário revisar o manual de qualidade; • Apreciação da qualidade e treinamento do sistema de qualidade; • Um programa de auditoria da qualidade; • Revisões gerenciais; • Avaliação ISO 9000. XIV.4. - IMPLEMENTAR UM PROGRAMA CULTURAL O programa cultural deverá ser implementado em conjunto com o programa técnico. O programa cultural consiste em conscientizar as pessoas da empresa da necessidade de se ter qualidade de alto nível. Normalmente, se utiliza do treinamento de qualidade e profissional (aprendizado de novas e melhores ferramentas de desenvolvimento) e realização de Workshop para discutir qualidade e necessidades da empresa e das pessoas que estão envolvidas. Também faz parte do programa cultural, as iniciativas da gerência e do pessoal da empresa para poder melhorar e aumentar o incentivo das pessoas para realizarem uma tarefa melhor e mais bem feita. As iniciativas da gerência dão ênfase a análise de defeitos e suas causas e a definição de marcos que devem ser alcançados em certo período de tempo. Já as iniciativas dos funcionários da empresa são voltadas para sugestões de como realizar tarefas e procedimentos de forma a retornar mais qualidade e mais serviço. 26 XIV.5 - IMPLEMENTAR O PROGRAMA TÉCNICO O programa técnico consiste em: Adotar um ciclo de vida Toda empresa de software, grande ou pequena, deve possuir um ciclo de vida para o desenvolvimento do produto. Muitos tipos de ciclo de vida têm sido implementados e testados para atender a determinadas circunstâncias. A empresa deverá adotar um ciclo de vida e, então adequá-lo às suas necessidades. O ciclo de vida é dividido em etapas. Em cada etapa poderá ser feito uma revisão do que já foi feito e rever o que vai ser feito na próxima etapa. Desenvolver procedimentos e padrões Algumas empresas trabalham com o máximo possível de procedimentos e padrões definidos rigorosamente. É comum aos desenvolvedores não se acostumarem facilmente com estes novos padrões. No caso da empresa estar implantando pela primeira vez um sistema de qualidade, os desenvolvedores estarão sujeitos a não aceitarem o que foi dito e a empresa vai demorar muito tempo tentando conscientizá-las. Os procedimentos e padrões devem ser identificados da maneira como são utilizados e, depois, alterá-los, se necessários e divulgá-los pela empresa toda. Estes, normalmente, sofrem a interferência de padrões internacionais como ISO e CMM e devem ser desenvolvidos e utilizados pelas pessoas que já os utilizavam. Caso a empresa venha implantar novos procedimentos e padrões, eles devem ser feitos de maneira gradual. Se implementar tudo de uma vez, a resistência será maior e a empresa poderá perder por causa disto. Selecionar métodos e ferramentas. Os métodos e ferramentas a serem utilizados devem ser padronizados. Esta padronização deverá levar em consideração dicas dos desenvolvedores e diretores que estão envolvidos diretamente com o processo de desenvolvimento do software. Estes devem ser utilizados em todos os projetos da empresa e ter uma variação pequena de um projeto para outro. Aconselha-se que as ferramentas de desenvolvimento devem ser de um mesmo fornecedor para evitar conflitos, atrasos, defeitos inesperados e correções mal feitas para se adaptar as ferramentas diversas ao sistema. Programa de métricas e medidas de software É dito que, se você não pode medir, então você não pode gerenciar. Esta frase pode não estar muito certa, mas se a empresa conseguir “medir” a funcionalidade e a qualidade de seu produto e dos concorrentes, poderá saber se o seu produto está melhor ou pior do que o outro. Neste caso, as medidas são muito importantes. Quando adotado nas empresas, elas procuram as medidas que devem: 27 XVI. - BIBLIOGRAFIA SANDERS, Joc e CURRAN, Eugene. Software Quality. AddisonWesley, 1994. 30 Glossário de Termos da Qualidade Ação Corretiva Ação implementada para eliminar as causas de uma não-conformidade, de um defeito ou de outra situação indesejável existente, a fim de prevenir sua repetição. [NBR ISO 8402] Ação Preventiva Ação implementada para eliminar as causas de uma possível não-conformidade, defeito ou outra situação indesejável, a fim de prevenir sua ocorrência. [NBR ISO 8402] Analisador de Código Software que percorre um trecho de código, uma rotina ou um programa, com a finalidade de coletar métricas de complexidade ou de elaborar um grafo ou outra descrição da lógica do código percorrido. Análise Crítica (Review) Avaliação profunda e global de um projeto, produto, serviço, processo ou informação com relação a requisitos, objetivando a identificação de problemas e a proposição de soluções. [Critérios de Excelência da Fundação para o Prêmio Nacional da Qualidade – FPNQ] Análise Crítica de Contrato Atividades sistemáticas executadas pelo fornecedor, antes da assinatura do contrato, para garantir que os requisitos para a qualidade estão adequadamente definidos, sem ambigüidade e documentados, e que os mesmos possam ser atendidos pelo fornecedor. [NBR ISO 8402] Análise Crítica de Projeto Exame documentado completo e sistemático de um projeto para avaliar sua capacidade de atender os requisitos para a qualidade, identificar problemas, se houver, e propor o desenvolvimento de soluções. [NBR ISO 8402] Análise Crítica de Requisitos Processo ou reunião durante o qual os requisitos para um sistema, item de hardware ou item de software são apresentados aos desenvolvedores, gerentes, usuários, clientes, ou outros interessados para comentários e aprovação. Aqui também estão incluídos análise crítica de sistema e análise crítica de software. [IEEE Std 610.12] Análise de Pontos por Função Técnica de avaliação de um sistema, conhecida como FPA – Function Point Analysis, baseada na medição do valor das funções executadas pelos programas, ao invés de utilizar como base o volume ou a complexidade do código dos programas. A técnica está baseada na visão externa do usuário, sendo portanto, independente da linguagem utilizada, permitindo calcular o esforço de programação e auxiliando o usuário final a melhorar o exame e avaliação de projetos. Análise de Requisitos Conjunto de atividades que permite identificar as necessidades do usuário de modo a obter uma definição clara das características (requisitos) de um sistema. Essas características descrevem o sistema em termos de funcionalidades, desempenho esperado, restrições de projeto, níveis de qualidade esperados, interface com outros elementos do sistema. Processo de estudar as necessidades do usuário para se chegar a uma definição dos requisitos de sistema, hardware ou software. [IEEE Std 610.12] ASQ - American Society for Quality Entidade norte-americana que congrega profissionais interessados na engenharia da qualidade e na gestão da qualidade. Oferece diversas certificações profissionais, entre as quais a de engenheiro da qualidade (Certified Quality Engineer - CQE), engenheiro de confiabilidade (Certified Reliability Engineer - CRE), auditor da qualidade (Certified Quality Auditor - CQA), administrador da qualidade (Certified Quality Manager - CQM) e engenheiro da qualidade em software (Certified Software Quality Engineer - CSQE). No Brasil, os exames para certificação são aplicados pela Associação Brasileira de Controle da Qualidade - ABCQ. Auditoria Exame sistemático e independente, para determinar se as atividades da qualidade e seus resultados estão de acordo com as disposições planejadas, se estas foram implementadas com eficácia e se são adequadas à consecução dos objetivos. [NBR ISO 8402] Avaliação 31 Exame sistemático do grau em que um produto, processo ou serviço atende aos requisitos especificados. Avaliação de Terceira Parte ou Independente Avaliação feita por pessoa ou organismo reconhecido como independente das partes envolvidas. CASE - Computer Aided Software Engineering Ferramenta de apoio ao desenvolvimento de software. Em linhas gerais, apóia a execução de atividades do desenvolvimento do software de forma automatizada. Em alguns casos, implementa um ambiente relativamente refinado no qual várias atividades de especificação ou codificação são apoiadas por recursos computacionais.Dependendo do tipo de atividade suportada podem ser classificados em Lower CASE, provendo suporte à codificação, teste, depuração e manutenção do código ou Upper CASE, suportando diversas tarefas de análise e projeto de sistemas.Eventualmente, ferramentas CASE podem ser integradas em ambientes de desenvolvimento de software. Neste caso, apoiando parte das atividades previstas em um processo de desenvolvimento de software. Certificação Modo pelo qual uma terceira parte dá garantia escrita de que um produto, processo ou serviço está em conformidade com os requisitos especificados. [ABNT ISO/IEC GUIA 2] Certificação de Software Emissão de um certificado de conformidade de um software a um certo conjunto de normas ou especificações, comprovada por testes de conformidade e por testes de campo. CMM - Capability Maturity Model Modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos. O CMM prevê cinco níveis de maturidade: inicial, repetível, definido, gerenciado e otimizando. O modelo foi proposto por Watts S. Humphrey, a partir das propostas de Philip B. Crosby, e vem sendo aperfeiçoado pelo Software Engineering Institute - SEI da Carnegie Mellon University. [http:// www.sei.cmu.edu/cmm/cmm.html] Confiabilidade Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido. [NBR 13596]. Tem como subcaracterísticas: maturidade, tolerância a falhas e recuperabilidade. Configuração Relação entre versões de um objeto composto, ou seja, configuração é uma instância do sistema composta da união de uma versão específica de cada objeto componente.Arranjo de um sistema computacional ou de seus componentes como definidos pelo seu número, natureza e interconexão de suas partes constituintes. [IEEE Std 610.12] Controle de Versão Procedimento de gestão do ciclo de vida de um produto. Consiste na identificação formal de modificações solicitadas ou efetuadas e no seu agrupamento, de modo a que fiquem incorporadas, todas elas, em uma determinada configuração do produto, num certo momento. Essa configuração recebe o nome de versão. Custos da Qualidade Custos relacionados com as perdas em função da qualidade insuficiente de processos, produtos ou serviços (custos da não-conformidade) ou com os investimentos em atividades que eliminem falhas ou elevem a qualidade de processos, produtos ou serviços (custos da conformidade).A identificação e a apropriação contábil desses custos permite que o administrador possa fazer uma análise do nível de qualidade de sua produção e possa tomar decisões para melhorar esse nível. Declaração de Conformidade Declaração, emitida pelo fornecedor ou pelo produtor de um software, assegurando que este opera em conformidade com certas normas ou especificações preestabelecidas. Depurador Interativo Software para apoio a testes, cuja função é permitir a visualização passo a passo da execução de uma rotina ou programa e do comportamento de seus elementos antes, durante e após a execução. Dicionário de Dados 32 ISO 9002 Quality systems – Model for quality assurance in production, installation and servicing.Norma internacional da série ISO 9000. Modelo para garantia da qualidade na produção, instalação e serviços associados. ISO 9003 Quality systems – Model for quality assurance in final inspection and testing. Norma internacional da série ISO 9000. Modelo para garantia da qualidade em inspeção e ensaios finais. ISO/IEC 9126 Information technology - Software quality caracteristics and metrics.Norma que define as características da qualidade de software, para fins de sua avaliação. Será complementada com outras normas que definirão guias para avaliação do software, hoje na forma de drafts.A norma brasileira correspondente é a NBR 13596. ISO 9241 Ergonomic requirements for office work with visual display terminals (VDTs). Norma que define requisitos ergonômicos para o trabalho de escritório com computadores (VDT – Visual Display Terminals), objetivando promover a saúde e a segurança de usuários de computadores e garantir que eles possam operar esses equipamentos com eficiência e conforto. ISO/IEC 12119 Information technology - Software packages - Quality requeriments and testing.Norma que estabelece os requisitos da qualidade e testes em pacotes de software. Seu escopo refere-se a pacotes de software, na forma oferecida no mercado, e não aos processos de desenvolvimento e fornecimento de software. A norma brasileira correspondente é a NBR ISO/IEC 12119. ISO/IEC 12207 Information technology – Software life cycle process. ISO/IEC 14598 Information technology – Software product evaluation.Família de normas que tratam do processo de avaliação de um produto de software e complementam o modelo apresentado na norma ISO/ IEC 9126, hoje na forma de drafts. ISO/IEC 15504 Information technology – Software process assessment. Futura norma internacional para avaliação de processos de software, em desenvolvimento pelo projeto SPICE (Software Process Improvement and Capability dEtermination), o que a torna conhecida também como Modelo SPICE. Atualmente está publicada como um relatório técnico (ISO/IEC TR 15504) da ISO/IEC com previsão de ser publicada como norma em 2002. Define um modelo de referência com processos e níveis de capacidade, orientações sobre como utilizá-lo para melhoria contínua ou determinação da capacidade, e um modelo exemplo compatível . JAD - Joint Application Design Conjunto de sessões intensivas e mediadas entre usuários e analistas de um sistema, com o objetivo de explicitar os seus requisitos.A técnica, desenvolvida nos anos setenta pela IBM do Canadá, voltou a ficar em voga com o uso do RAD - Rapid Application Development, metodologia que combina o JAD (para definir rapidamente a especificação do sistema) com o uso de ferramentas CASE e de metodologias de prototipação, para chegar a um produto final em menor tempo. Lead Assessor Certificação que qualifica um auditor a atuar na avaliação de empresas segundo as normas ISO 9000. A obtenção desse título depende da participação em cursos e da realização de um número de horas de auditoria, acompanhando auditores já certificados. Manutenibilidade Conjunto de atributos que evidenciam o esforço necessário para fazer modificações especificadas no software. [NBR 13596].Tem como subcaracterísticas: analisabilidade, modificabilidade, estabilidade e testabilidade. Medição Ação de aplicar uma métrica de qualidade de software a um produto de software específico. [NBR 13596] Medição de Linhas de Código ( LOC ) 35 É a métrica de código mais básica. A definição mais comum de LOC estabelece que qualquer linha do programa que não seja comentário ou linha em branco, independente do número de sentenças (lógicas ou operações) estão presentes naquela linha. [Marciniak J.J., Encyclopedia of Software Engineering] Melhoria de Processos de Software (Software Process Improvement) Uma abordagem (SPI) para melhoria das organizações que desenvolvem e mantêm software. É baseada na melhoria da capacidade de processos fundamentais para organizações de software. Utiliza como referência um modelo de processo, como por exemplo, o CMM e a ISO/IEC 15504- SPICE. Métricas de Complexidade Grandezas coletadas através do exame da especificação do código de um sistema, programa com rotina e que refletem o seu tamanho e a sua complexidade lógica. Diversos modelos existem para relacionar métricas de complexidade com tempo ou esforço de desenvolvimento e com o número de erros embutidos no produto. Métrica de Qualidade de Software Método e uma escala quantitativa que podem ser usados para determinar o valor que uma particularidade (feature) recebe em um produto de software específico. [NBR 13596] NBR ISO 8402 Gestão da qualidade e garantia da qualidade – Terminologia, Brasil. NBR ISO 9000-3 Normas de gestão da qualidade e garantia da qualidade - Parte 3: Diretrizes para a aplicação da NBR 19001 (ISO 9001) ao desenvolvimento, fornecimento e manutenção de software, Brasil. NBR ISO 9001 Sistemas da qualidade - Modelo para garantia da qualidade em projetos, desenvolvimento, produção, instalação e serviços associados, Brasil. NBR ISO 9002 Sistemas da qualidade – Modelo para garantia da qualidade em produção e instalação e serviços associados, Brasil. NBR ISO 9003 Sistemas da qualidade – Modelo para garantia da qualidade em inspeção e ensaios finais, Brasil. NBR ISO/IEC 12119 Tecnologia de informação – Pacotes de software – Testes e requisitos de qualidade, Brasil.Norma que estabelece os requisitos de qualidade para pacotes de software e instruções de como testar um pacote de software com relação aos requisitos estabelecidos. NBR ISO/IEC 12207 Tecnologia de informação – Processos de ciclo de vida de software, Brasil.Norma que estabelece uma estrutura comum para os processos de ciclo de vida de software, com terminologia bem definida, que pode ser referenciada pela indústria de software. NBR 13596 Tecnologia de informação – Avaliação de produto de software – Características de qualidade e diretrizes para o seu uso, Brasil. Versão brasileira da norma ISO/IEC 9126. Otimizador Software, usualmente embutido no compilador que otimiza o código gerado a partir do exame do programa a ser compilado, eliminando redundâncias, código inacessível, etc. Peer-review Técnica de revisão de um produto, na qual um colega (peer) do projetista ou do programador revisa o produto desenvolvido, buscando encontrar erros ou oferecer sugestões de melhoria. Política da Qualidade Intenções e diretrizes globais de uma organização relativas à qualidade, formalmente expressas pela alta administração. [NBR ISO 8402] Portabilidade Conjunto de atributos que evidenciam a capacidade do software de ser transferido de um ambiente para outro. [NBR 13596].Tem como subcaracterísticas: adaptabilidade, capacidade para ser instalado, conformidade e capacidade para substituir. Processo Conjunto de recursos e atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas). [NBR ISO 8402].Agrupamento em seqüência de todas as tarefas destinadas a 36 obter um determinado resultado. É a combinação de equipamentos, instalações, mão-de-obra, métodos, técnicas, ferramentas, procedimentos e outros fatores, com a finalidade de elaborar um produto ou alcançar um resultado preestabelecido. Processo de Software Conjunto de atividades, métodos, práticas e transformações que as pessoas empregam para desenvolver e manter software e os produtos associados (por exemplo, planos de projeto, documentos de projeto/design, código, casos de teste, manual do usuário). Programação Orientada a Objetos Técnica de programação que enfatiza a descrição dos conceitos envolvidos com o domínio do problema (objetos) através de seus dados e operações, encapsulados e representados através de classes. Cada objeto é criado como pertencendo a uma classe. A utilização de um objeto, e sua eventual mudança de estado, se dá a partir de mensagens enviadas a ele, representadas pelas operações encapsuladas na classe. Novas classes podem ser criadas a partir de classes existentes e organizadas através de um processo de classificação e hierarquização, explorando o conceito de herança.Os programas são construídos como organizadores da ativação de mensagens para os objetos, desta forma fazendo com que as funcionalidades de um sistema sejam obtidas através da cooperação dos objetos. Projeto da Interface com o Usuário O processo global para projetar uma interface com o usuário inicia-se com a criação de diferentes modelos de função do sistema. Quatro diferentes modelos entram em cena quando uma HCI vai ser projetada. O engenheiro de software cria um modelo de projeto; um engenheiro humano estabelece um modelo de usuário, o usuário final desenvolve uma imagem mental que muitas vezes é chamada modelo do usuário ou de percepção do sistema e os implementadores do sistema criam uma imagem do sistema. [Pressman R. S., Engenharia de Software, 1995] Projeto de Software Envolve tipicamente análise, especificação, projeto (design), desenvolvimento, teste e/ou manutenção dos componentes de software e da documentação associada. [Mark Paulk, 1995] Prototipação Método de desenvolvimento que prevê a execução de vários ciclos de análise, especificação e codificação de um sistema.No primeiro ciclo, gera-se um produto simplificado em pouco tempo, de modo que o usuário possa examiná-lo e refinar as suas demandas.Nos ciclos seguintes, o produto é aperfeiçoado e novas funções são sucessivamente implementadas, até se chegar ao produto final. Prova de Correção Exame de uma especificação descrita segundo regras formais preestabelecidas, de modo a provar matematicamente a sua correção, através do uso de axiomas, teoremas e procedimentos algébricos. QFD - Quality Function Deployment Técnica de planejamento e de especificação de requisitos que consiste em reuniões com técnicos e clientes, nas quais são elaboradas matrizes em que se cruzam informações sobre "o que" é desejado (requisitos) e "como" implementar. É composta por quatro etapas - projeto, componentes, processo e produção, sendo gerada a cada etapa uma matriz, a partir da matriz anterior.As matrizes explicitam relações, conflitos, níveis de dificuldade, estágio tecnológico. Por seu formato peculiar, a matriz do QFD é conhecida como "casa da qualidade". Qualidade (Quality) Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas. [NBR ISO 8402].Entidade pode ser uma atividade ou um processo, um produto, uma organização ou uma combinação desses. Reengenharia de Software Técnica de restruturação ou modificação de um código existente, ou de desenvolvimento de um novo código, preservando-se inalterada a especificação ou o projeto do software. Requisitos (Requirements) Necessidades básicas do cliente, geralmente explicitadas como condição de negócio no contrato com o fornecedor. São características, tais como especificações técnicas, prazo de entrega, garantia, que o cliente "requer" do produto. Uma condição ou capacidade necessitada por um usuário, para resolver um problema ou alcançar um objetivo. [IEEE 83] 37