Baixe o app para aproveitar ainda mais
Prévia do material em texto
Existem diversas definições para qualidade e, na visão simples de algumas pessoas, estas a definem como sendo: Para ajudar nessa questão, a International Organization for Standardization – ISO e a International Electrotechnical Comission – IEC, orgãos normalizadores com importância internacionalmente reconhecida no setor de software, se uniram para editar normas internacionais conjuntas para os mais diversos setores, no mundo inteiro. Essas normas podem ser, no que diz respeito a sua origem: Por ser assim, Pressman (2002) complementa que: Por outro lado, Sommerville (2007) estabelece que o gerenciamento de qualidade está estruturado em três atividades principais: Enfim, nesta visão, os padrões exigidos devem englobar boas práticas para que sejam gerados produtos de alta qualidade. Dessa forma, acredita-se que há muito mais gerenciamento de qualidade do que padrões e burocracia associada para assegurar que os padrões foram seguidos. Complementa o autor que a base do gerenciamento da qualidade advém de aspectos intangíveis tais como a elegância, a capacidade de leitura do código e da documentação de qualidade gerada ao longo da existência de um software. A documentação de qualidade deve variar de acordo com o tamanho do software tendo como propósito a comunicação entre a equipe que participa do desenvolvimento do software. Destaca-se que a qualidade do processo contribui para a melhoria da qualidade do produto, que, por sua vez, contribui para a melhoria da qualidade em uso: Através da adequação dos atributos internos do software atende-se a um pré-requisito para o alcance do comportamento externo desejado, que por sua vez, é um pré-requisito para o alcance da qualidade de uso. Sendo Assim: Reflita... Pensar em desenvolver um software com qualidade é considerar o processo correto pelo qual produtos ou serviços são convertidos em bens materiais. Torna-se relevante considerar que, uma vez o processo realizado corretamente, um bom produto final será desenvolvido. Assim, todos os processos de uma determinada atividade são importantes; se os processos forem desenvolvidos com qualidade, o produto final terá qualidade. Em primeiro lugar, vamos considerar que o efeito da globalização expandiu o elenco de atores no mercado aumentando a oferta de produtos, tornando assim o cliente mais consciente de seu poder. Dessa forma, esse novo cliente vai demandar por produtos e processos de software de melhor qualidade. Em outro momento, os clientes vão buscar responder algumas questões como... Funciona adequadamente em imprevistos, como, por exemplo, efetuar débito em uma conta com saldo insuficiente? As funções requeridas estão disponíveis e são executadas eficientemente? O software é seguro, ou seja, evita que pessoas ou sistemas não autorizados tenham acesso aos dados para leitura ou modificação? Permite que pessoas ou sistemas autorizados para acessar os dados não tenham acesso negado a eles? É fácil de integrar com outros sistemas existentes? O suporte técnico é confiável e atende com a rapidez necessária? É certo que essa mudança de postura do consumo vai exigir melhor qualidade de produtos e processos para atender a esse novo cliente. A utilização de software de qualidade garante a segurança das transações, dos negócios, das pessoas envolvidas e mantém alta disponibilidade dos serviços. Produtos e serviços são considerados aceitáveis se apresentarem desempenho dentro de certos limites. Por fim é relevante afirmar que os esforços pela qualidade nos mais diversos setores organizacionais já provaram que os gastos em qualidade se pagam em muito pouco tempo. Pense nisso... O aumento de qualidade sempre é acompanhado por aumento de produtividade e redução de custos na forma de menos retrabalho e menor índice de perdas. No caso de software, isto pode significar reaproveitamento de códigos de programa, menor prazo de entrega, menor custo de manutenção e maior satisfação do cliente, que vai refletir em maior participação no mercado. Para mais informações, leia agora o capítulo 27 de Gerenciamento de Qualidade – Sommerville (2007, pg. 423-426), e o capítulo 28 de Aprimoramento de Processo – Sommerville (2007, pg. 439-443) Para mais informações, leia agora o texto Diretrizes de revisão. Ao final desta aula, você será capaz de: 1. Descrever os passos necessários para realizar a SQA estatística. 2. Discorrer sobre a diferença entre confiabilidade de software e segurança de software. 3. Abordar os princípios da ISO 9000 e suas vertentes. 4. Discorrer sobre os modelos ISO 9000 para sistemas de garantia da qualidade. A NBR ISO/IEC 9126-1, publicada em 1991, apresenta uma definição de qualidade como sendo a "totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas" (2003, p.17). As necessidades explícitas (ou externas) dependem do que foi especificado nos requisitos referentes às condições em que o produto deva ser utilizado, seus objetivos, funções e o desempenho esperado. Já as implícitas (ou diretas) são necessidades que embora não estejam especificadas nos requisitos, devem ser levadas em consideração, pois se baseiam em princípios básicos e óbvios, necessários para que o usuário execute a sua tarefa. Essas duas necessidades são muito importantes, pois são elas que fornecem subsídios para a criação das validações e verificações que ocorrem durante todo o ciclo de vida do sistema. Dentre elas, pode-se citar o teste de software como uma grande ferramenta para garantir a qualidade do software. No entendimento da NBR ISO/IEC 9126 as necessidades explícitas e implícitas são entendidas como características e subcaracterísticas básicas de um produto de software que vise à presença da qualidade. As definições de características e subcaracterísticas de qualidade nos permitem perceber um possível universo de requisitos que se enquadram no conceito de qualidade. A Norma ISO/IEC 12119 é aplicável a pacotes de software, como por exemplo, pacotes de software voltados para funções administrativas, técnicas ou científicas, comunicação de escritórios e outras finalidades, tal como são produzidos. Outros exemplos, incorporados aos pacotes de software compreendem os processadores de texto, planilhas eletrônicas, bancos de dados, softwares gráficos, programas para funções técnicas ou científicas e programas utilitários. Aplicável à avaliação de pacotes de software na forma em que são oferecidos e liberados para uso no mercado e não aos processos de desenvolvimento e fornecimentos de software. Os requisitos de qualidade incluem que: i) cada pacote de software deve ter uma descrição do produto e documentação do usuário; ii) a descrição de produtos deve conter informações que sejam testáveis e corretas e, iii) requisitos para a documentação do usuário, programas e dados que façam parte do pacote. A descrição do produto inclui as principais propriedades do pacote. A documentação do usuário nada mais é que um documento que será avaliado em relação à sua completitude, correção, consistência, inteligibilidade, apresentação e organização. Programas e dados, na verdade, são os requisitosde programas e dados que devem estar descritos, caso existam, para funcionamento do produto. Um pacote de software está em conformidade com esta Norma se atende a todos os requisitos de qualidade nela definidos. A garantia e controle de qualidade no desenvolvimento de software ao operarem simultaneamente, visam garantir que os artefatos de software sejam desenvolvidos e entregues com melhor aceitabilidade, menos defeitos e menores custos. Modelo de qualidade de software A norma NBR ISO/IEC 9126 apresenta, de certa maneira, os instrumentos necessários para realizar uma avaliação, descrevendo de forma ampla como medir qualitativamente e quantitativamente a “presença” de qualidade, formando assim um modelo de qualidade para produto. De acordo com a Associação Brasileira de Normas Técnicas – ABNT, a série da NBR ISO/IEC 9126 se subdivide da seguinte forma: O modelo de qualidade para produto de software tem como público alvo desenvolvedores de software, adquirentes, equipe de qualidade assegurada e avaliadores. Por adquirente entende-se uma organização que obtém, adquire ou intermedia a compra de um sistema, produto de software ou serviço de software de um fornecedor. O adquirente pode ser um comprador, cliente, proprietário ou usuário. Assim, torna-se interessante considerar o uso de um modelo de qualidade composto de características e subcaracterísticas que podem ser usadas como uma lista de verificação (checklist) de assuntos relacionados à qualidade interna e externa de produtos. Para mais informações, leia agora o texto Características e Subcaracterísticas da Qualidade de Software. Princípios da ISO 9000 Até aqui,conhecemos um pouco mais sobre a garantia estatística da qualidade. A partir de agora, trataremos da abordagem da norma ISO 9000. Então, a avaliação e melhoria de um processo é um meio para melhorar a qualidade do produto, e a avaliação e melhoria da qualidade do produto é um meio de melhorar a qualidade em uso. Similarmente, a avaliação da qualidade em uso pode dar um feedback para melhorar o produto e a avaliação da qualidade do produto pode dar feedback para melhorar o processo. Pense nisso... Os atributos internos adequados do software tornam-se um pré-requisito para alcançar o comportamento externo desejado, que por sua vez, é um pré-requisito para alcançar a qualidade. Os requisitos de qualidade do produto de software geralmente incluem critérios de avaliação para qualidade interna, qualidade externa e qualidade em uso, para corresponder às necessidades dos desenvolvedores e usuários finais. Um processo pode ser avaliado indiretamente pela medição e avaliação do produto, e o produto pode ser avaliado indiretamente pela medição do desempenho da tarefa de um usuário (utilizando métricas de qualidade em uso). Interessante observar que um software nunca é executado sozinho, mas sempre como parte de um sistema maior, que tipicamente, consiste de outros produtos de software que tem sua interface, hardware, operadores e fluxo de trabalho. O produto de software completo pode ser avaliado pelos níveis de métricas externas escolhidas. Nos primeiros estágios de desenvolvimento somente recursos e processos podem ser medidos. Quando produtos intermediários se tornam disponíveis (especificações, código fonte, etc), eles podem ser avaliados pelas métricas internas escolhidas. Essas métricas podem ser usadas para prever valores de métricas externas. Considera-se que a qualidade do usuário pode ser especificada como requisitos de qualidade por métricas de qualidade em uso, por métricas externas e algumas vezes, por métricas internas. Tais requisitos especificados por métricas deveriam ser usados como critério quando um produto é validado. É importante considerar que a qualidade em uso consiste na qualidade percebida pelo usuário e na aferição da qualidade do software em cada contexto específico de usuário. Essas métricas visam descrever a interação com o ambiente e são avaliadas pela observação do software em operação. Qualidade em uso pode ser medida pelo quanto um produto em uso atinge as necessidades do usuário em termos de efetividade, produtividade, segurança e satisfação. A qualidade do usuário pode ser especificada como requisitos de qualidade por métricas de qualidade em uso, por métricas externas e algumas vezes, por métricas internas. Tais requisitos especificados por métricas deveriam ser usados como critério quando um produto é validado. A execução de um produto que satisfaça as necessidades do usuário normalmente requer uma abordagem interativa no desenvolvimento do software, com contínuo feedback da perspectiva do usuário. Para tanto, algumas características de qualidade são pertinentes à aquisição de qualidade de produto de software, na visão do usuário. Qualidade em Uso é a visão de qualidade que o usuário tem do software e é medida em termos do resultado da utilização do software. É a capacidade que o produto de software tem de atender aos anseios e às necessidades dos usuários em seu próprio ambiente de trabalho. É, portanto, a capacidade de software permitir a usuários específicos atingir metas especificadas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado. Estrutura da ISO/IEC 12119 Até aqui, tratamos de modelos de qualidade de produto de software focados na norma NBR ISO/IEC 9126. Agora , focaremos na norma NBR ISO/IEC 12119. IMPORTANTE: será iniciada uma outra norma 12119. Requisitos de Qualidade Instruções para teste Vamos ver todos esses conceitos na prática? Visite uma empresa de desenvolvimento de software e solicite uma participação na equipe de testes para o acompanhamento e levantamento de dados a respeito do tipo e dos tempos entre a ocorrência de falhas, a fim de mostrar se a confiabilidade está aumentando. Elabore uma tabela de tipos e incidência de falhas, de acordo com a tabela apresentada para identificação dos passos para a SQA estatística (aula anterior). Elabore uma análise crítica da qualidade de software utilizando as características e subcaracterísticas pertinentes a NBR ISO/IEC 9126, tais como: Maturidade: capacidade de evitar defeitos no software. Tolerância a Falhas: capacidade de manter um nível de desempenho estabelecido em caso de defeito no software Recuperabilidade: capacidade de recuperar dados diretamente afetados no caso de falhas. Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições similares relativas à confiabilidade. Os anais da International Conference on Software Engineering geralmente contêm bons artigos sobre as mais recentes teorias de teste. Por exemplo, alguns casos de estudo examinam as diferenças entre os testes para aumentar a confiabilidade e os testes para encontrar defeitos. Investigue também sobre o teste de usabilidade. Um sistema correto e confiável, mas difícil de ser utilizado, pode, na verdade, ser pior do que um que seja fácil de ser utilizado, mas não seja confiável. Reportagem do programa Olhar Digital sobre usabilidade. Fonte: http://www.youtube.com/watch?v=_bhxZjIqnIY ISO 9241-11 não cobre os processos de desenvolvimento de sistema. Os processos de projeto centrados no ser humano para sistemas interativos são descritos na ISO 13407. Veja a seguir cada uma das especificações das características de medidas de uso: Não deixe de acompanhar os Fóruns de Discussão de sua disciplina. Aproveite para tiraras suas dúvidas, debater e comentar as respostas dos seus colegas. Para mais informações sobre o assunto de nossa aula, leia: o artigo “Usabilidade de Software”; o artigo “Avaliação da usabilidade de software em SI: o caso do SI Submarino”. O vídeo ilustra como a norma IEC está presente no dia a dia. Deve-se avaliar a qualidade do produto liberado por diversas razões: Pode ser aplicada tanto para produto existente como para produtos em desenvolvimento. Além das partes envolvidas no processo, a norma descreve um procedimento passo a passo dos requisitos de avaliação expressos com as devidas características de qualidade. O processo de avaliação envolve um conjunto de atividades conduzidas pelo requisitante da avaliação e pelo avaliador que iniciam o trabalho a partir do uso dos dados fornecidos pelo requisitante, pelo avaliador ou por outros meios e atividades do conjunto. No final do processo, os resultados esperados da avaliação de produto devem ser compreensíveis, aceitáveis e confiáveis por quaisquer partes interessadas nos papéis de requisitante de uma avaliação ou de avaliador. Dessa forma, espera-se obter um alto nível de objetividade da avaliação. Considera-se que as avaliações de um mesmo produto podem ser executadas a partir de diferentes especificações e, portanto, não comparáveis e com resultados diferentes. Não deixe de acompanhar os Fóruns de Discussão de sua disciplina. Aproveite para tirar as suas dúvidas, debater e comentar as respostas dos seus colegas. Nessa aula, você aprendeu: A norma ISO/IEC 14598 oferece uma visão geral dos processos de avaliação de produtos de software e fornece guias de requisitos para avaliação. Apesar de a norma possibilitar o uso de qualquer modelo de qualidade, a aplicação desse processo de avaliação se torna menos complexa se for utilizada em parceria com a norma ISO/IEC 9126, pois todas as normas da família 14598 estão ligadas a esse modelo. A documentação do processo de avaliação de um produto de software, representado pela ISO/IEC 14598-5, deve englobar um conjunto de métricas que fornecem informações importantes sobre as propriedades do software e devem ser utilizadas de maneira eficiente de tal forma que possibilite a troca de informações sobre avaliações e entre avaliadores. Para tanto, requer que haja uma padronização na forma de documentação o que é feito pela aplicação de módulos de avaliação (M.A.). Para mais informações, leia agora o texto Módulos de avaliação. As diretrizes da ISO 9000-3 A ISO 9001 baseia-se em 20 diretrizes (ou critérios) que englobam vários aspectos da garantia da qualidade. A ISO 9000-3 engloba somente 12 desses elementos. O ponto central dos critérios de um sistema de gestão da qualidade baseada nas normas ISO 9000 é a apropriada documentação desse sistema. A norma brasileira equivalente à ISO 9000-3 é a ISO 9000-3 de 1993, baseada na edição de 1991, e agrupa as diretrizes em três partes principais: > Estrutura – descreve aspectos organizacionais relacionados ao sistema de qualidade. > Atividades do ciclo de vida: descreve atividades de desenvolvimento de software. > Atividades de suporte: descreve atividades que apoiam as atividades do ciclo de vida. A estrutura, nomenclatura e arranjo da atual ISO 9000-3, de 1997, seguem exatamente a estrutura da ISO 9001 e suas diretrizes têm o mesmo nome. Vamos, então, concentrar nossos estudos em duas partes: O segundo nível é composto por dez grupos de processo que são alocados em cada uma das categorias de processo. Cada um é definido por seis níveis de capacidade sequenciais e cumulativos que podem ser utilizados como uma métrica para avaliar como uma organização está realizando um determinado processo. Também podem ser utilizados como um guia para a melhoria cuja utilização tem como referência um modelo de processo que enfatiza a realização de uma avaliação de processo. O guia apresenta oito etapas sequenciais que inicia com a identificação de estímulos para a melhoria e o exame das necessidades da organização. A norma ISO/IEC 15504 define, também, um ciclo de melhorias a fim de identificar novas melhorias, avaliar as práticas correntes em relação à melhoria realizada. Dimensão de Processos A norma ISO/IEC 15504 relaciona as três categorias, os dez grupos e quarenta e oito processos dos modelos de avaliação de processo. A tabela em pdf apresenta detalhadamente cada um desses componentes. Saiba Mais Para aprofundar seus estudos, acesse a tabela Categorias, Grupos e Processos da ISO/IEC 15504-5. A escala representa a capacidade de crescimento do processo implementado, desde não atender ao propósito do processo até atender aos objetivos atuais e projetados do negócio. Trata-se, portanto, de uma métrica para avaliação e um roteiro para melhoria baseados na capacidade do processo. A medida da capacidade está baseada em atributos de processo que medem um aspecto específico da capacidade do processo requerida, conforme apresenta a tabela 2.2. Com isso, a evidência do alcance dos objetivos de negócio será determinada pela efetividade da prática da avaliação do processo em conformidade com os processos da norma ISO/IEC 15504. A figura 3.1 ilustra a interação do processo de avaliação com outros elementos importantes. A coleta de dados deve ser de forma sistemática, utilizando o seguinte: A validação dos dados coletados de acordo com: A pontuação de atributo de processo a partir dos dados validados deve partir de um valor conferido a cada atributo de processo, baseado nos dados validados. Por exemplo: O ideal do nível de capacidade de processo é manter nota “L” ou “F” nos atributos do nível “F” em todos os atributos dos níveis anteriores. A ISO/IEC 15504 não pressupõe modelos de ciclo de vida de software, tecnologias de software ou metodologias de desenvolvimento. Também não define um método explícito de avaliação, mas define os requisitos para o Método de Avaliação de Processos. Na prática, uma avaliação de processos de software é conduzida utilizando o Modelo de Avaliação de Processos e não o Modelo de Referência de Processos. Assim como os demais modelos definem, não é proposta do CMMI definir como o processo deve ser implementado, mas determinar como as características estruturais e semânticas em termos de objetivos e de grau de qualidade devem ser realizadas no trabalho. Para mais informações, leia agora o texto Um paralelo entre CMMI, CMM e ISSO Representações do CMMI Saiba Mais Para aprofundar seus estudos, consulte o texto Vantagens e desvantagens do CMMI. Para aprofundar seus estudos, consulte o texto Vantagens e desvantagens do CMMI. Pesquise, em sites na internet, experiências de empresas públicas ou privadas que implementaram a norma ISO/IEC 15504 e evoluíram para CMMI. Descreva os ganhos e as dificuldades encontradasno processo de melhoria contínua dos processos. Exemplo de Estudo de Caso disponível no trabalho "Melhoria de Processo de Software em uma empresa de pequeno porte: um estudo de caso". Neste estudo, pretende-se enfatizar que o gerenciamento de risco é fator de grande importância e utilidade no alcance da maturidade organizacional. A prática de atividades de identificação, análise, planejamento e monitoração de riscos devem ser realizadas de forma sistematizada e controlada durante todo o processo de desenvolvimento de software. Ressalta-se a necessidade de avaliações constantes e contínuas dos fatores e eventos associados a cada risco priorizado, como uma forma de implementar a melhoria e garantir a qualidade do processo de desenvolvimento de software. Veremos, ainda, alguns dos riscos de software mais comuns de ocorrerem no ambiente organizacional. Conceito de Risco Um risco é qualquer evento ou condição em potencial que, se concretizando, pode afetar positivamente ou negativamente um objetivo do projeto, por exemplo, o software que está sendo desenvolvido ou a organização. O gerenciamento dos riscos do projeto tem por objetivo: À medida que mais informações sobre os riscos se tornarem disponíveis, os riscos deverão ser analisados novamente e novas prioridades deverão ser estabelecidas. Durante o processo de análise de riscos, você deve fazer uma avaliação de sua probabilidade e seriedade. As avaliações não precisam ser numéricas, mas devem basear-se em um número de faixas. Os efeitos do risco podem ser avaliados como catastróficos, sérios, toleráveis ou insignificantes, veja exemplos na tabela abaixo: Após análise e classificação dos riscos, você deve avaliar os mais significativos a partir da combinação da probabilidade da ocorrência do risco e de seus efeitos ou seriedades. O processo de planejamento de riscos requer estratégias para gerenciá-los. Mas o que devo fazer ao detectar os riscos? Veja a seguir a tabela de estratégias de gerenciamento de riscos, com alguns exemplos de riscos e como proceder caso ocorram: A monitoração de riscos envolve a avaliação regular daqueles que forem identificados para decidir se eles estão ou não se tornando mais ou menos prováveis e se os efeitos dos mesmos mudaram. Trata-se de um processo contínuo e, a cada revisão de progresso feita, é necessária a discussão sobre cada um dos principais riscos separadamente. O Instituto de Engenharia de Software (SEI) (1990) define o processo de gerência de risco de software através de um modelo contínuo de gerenciamento de riscos composto por seis fases distintas: Para mais informações, leia agora o texto Aplicação nos modelos de qualidade de processo de software.
Compartilhar