Baixe o app para aproveitar ainda mais
Prévia do material em texto
1 ENGENHARIA E QUALIDADE DE SOFTWARE Unidade II Qualidade, Testes e Manutenção do Software Prof. Me. Edson Quedas Moreno MORENO, Edson Quedas Engenharia e Qualidade de Software (livro-texto I) / Edson Quedas Moreno. São Paulo: Pós-Graduação Lato Sensu UNIP, 2019. 44 p. : il. 1. Qualidade e produtividade de software. 2. Testes de software. 3. Manutenção do software. I. MORENO, Edson Quedas. II. Pós-Graduação Lato Sensu UNIP. III. Título. APRESENTAÇÃO DO PROFESSOR-AUTOR Possui mestrado em Engenharia de Produção pela Universidade Paulista (UNIP), ênfase em Sistemas de Informação (2002), graduação em Engenharia Eletrônica pela Faculdade de Engenharia Industrial (FEI, 1983), ênfase em Computação e pós-graduação lato sensu em Novas Tecnologias de Ensino-Aprendizagem pela UniÍtalo (2011). Atuou na coordenação de cursos de 1989 até 2016, pelas instituições UniÍtalo e Kroton/Anhanguera. É atualmente professor e conteudista de cursos de graduação e pós-graduação, na área de negócios, computação e informação pelas instituições UNIP e UniÍtalo. Exerceu atividades de professor, tutor e conteudista, desde 1989, pelas instituições Senac, Kroton/Anhanguera, FECAP. MBA em Engenharia de Software e da Informação pela UNINOVE. Na parte corporativa: desde 2002, é diretor da empresa ASSERTI, de 2009 até 2012, sócio das empresas Consultoria EaD e ITGVBR, de 1994 até 2000 gerente de sistemas na Panrotas Editora, de 1985 até 1994, analista de sistemas pela Sistemas e Computadores (SISCO) e, de 1983 até 1985, Programador pela Digilab/Bradesco. Áreas de conhecimento: computação e informação – ênfase em engenharia de software, projetos de software e de sistemas e tecnologias de ensino a distância; e em engenharia de produção – com ênfase em administração, projetos, logística e produção. Em aspectos comunitários: de 2005 a 2006 foi gerente do Departamento de Extensões de Assuntos Comunitários pela UniÍtalo (DEAC), em 2006 projetou e efetivou o Projeto Farol Verde (educação para crianças carentes) com apoio do Centro Universitário Ítalo Brasileiro, Prefeitura de São Paulo, em parceria com o 12º BPM/M SP, e, em 2015, projetou e efetivou um Hackathon (maratona de programação de software por 30 horas contínuas com a participação de 200 alunos), com apoio da Kroton / Anhanguera e Microsoft, promovido pela Secretaria Municipal de Promoção da Igualdade Racial da Prefeitura de São Paulo (SMPIR), em conjunto com o Banco Interamericano de Desenvolvimento (BID). SUMÁRIO INTRODUÇÃO .............................................................................................................................. 6 3. QUALIDADE E PRODUTIVIDADE DE SOFTWARE ....................................................... 7 3.1. Qualidade: uma abordagem da engenharia de software ................................................. 7 3.2. Fatores da qualidade de software .................................................................................... 7 3.2.1 Processo de controle da qualidade do software .............................................................. 8 3.2.2 Garantia de Qualidade de Software (GQS) – Software Quality Assurance (SQA) .......... 8 3.2.3 Custo da qualidade ........................................................................................................... 9 3.2.4 Fatores e Métricas da qualidade do software ................................................................ 10 3.2.5 Principais métricas de qualidade do software ................................................................ 11 3.3 Qualidade do produto da engenharia de software: ISO/IEC 9126 e ISO 25000 (NBR 9126-1 ABNT, 2003) 13 3.3.1 Objetivo ........................................................................................................................... 14 3.3.2 Estrutura do modelo de qualidade ................................................................................. 14 3.3.3 Modelo de qualidade para qualidade externa e interna ................................................. 15 3.3.4 Modelo de qualidade para qualidade em uso ................................................................ 16 3.3.5 Norma Square ISO/IEC 25000 – Software Product Quality Requirements and Evaluation 17 3.4 Sistemas da qualidade: ISO 9001 e ISO 90003............................................................. 18 3.4.1 A série ISO 9000 ............................................................................................................ 18 3.4.2 Descrição da série ISO 9000 e outros relacionados ...................................................... 18 3.4.3 ISO 9001 ......................................................................................................................... 19 3.4.4 ISO 90003 ....................................................................................................................... 20 3.5 ISO 12207 – Processos do ciclo de vida do software .................................................... 21 3.6 Modelo de qualidade de software: Capability Maturity Model Integration (CMMI) ......... 23 3.6.1 Os cinco níveis de maturidade ....................................................................................... 24 Fonte: CMMI Product Development Team – SEI (2000) ............................................................ 24 3.6.2 Áreas Chave de Processo (ACP) (Key Process Area – KPA) ....................................... 25 3.7 Modelo de qualidade de software: SPICE – ISO 15504 ................................................ 25 3.7.1 Elementos normativos da ISO 15504 ............................................................................. 26 3.7.2 Dimensão dos processos da ISO 15504 ........................................................................ 27 3.8 Exercício discursivo comentado ..................................................................................... 28 4. TESTES De SOFTWARE ............................................................................................... 30 4.1 Fundamentos dos testes de software ............................................................................ 30 4.2 Verificação e Validação (V&V) ....................................................................................... 30 4.2.1 Atividade de verificação .................................................................................................. 31 4.2.2 Atividade de verificação e depuração de falhas (debug) do código fonte ..................... 31 4.2.3 Engenharia de requisitos e a atividade de validação ..................................................... 32 4.2.4 Critérios de validação ..................................................................................................... 33 4.3 Técnicas de testes de software ...................................................................................... 33 4.3.1 Abordagens top-down e bottom-up ................................................................................ 33 4.3.2 Testes Alfa e Beta .......................................................................................................... 34 4.3.3 Testes Caixa-Branca e Caixa-Preta ............................................................................... 35 4.4 Exercício discursivo comentado ..................................................................................... 36 5 MANUTENÇÃO DO SOFTWARE .................................................................................. 38 5.1 Fundamentos da manutenção ........................................................................................ 38 5.2 Tipos de manutenção .....................................................................................................38 5.3 Procedimentos de manutenção ...................................................................................... 39 5.4 Gerenciamento de mudanças ........................................................................................ 39 5.5 Gerenciamento de versões e releases ........................................................................... 40 5.6 Exercício discursivo comentado ..................................................................................... 41 REFERÊNCIAS ........................................................................................................................... 43 BIBLIOGRAFIA............................................................................................................................ 43 6 INTRODUÇÃO A qualidade do software norteia todos os avanços da engenharia nesta área. O cliente atual é o foco das atenções no avanço da tecnologia. O cliente não quer mais só o software. Ele busca tecnologias atuais com qualidade, a custo baixo e entrega dentro do prazo. A demanda de software aumenta sempre e os produtores de software tem que acompanhar tais mudanças para se manterem no mercado. Consequentemente as empresas competem em inovações, melhorias e suporte ao cliente. Manter o software e adaptá-lo a novas tendências faz desta área uma das mais criativas. A elaboração do software é uma atividade de engenharia, que vai desde a sua concepção, seu desenvolvimento, a entrega e suporte ao cliente. A engenharia de software é apoiada pela qualidade, que se manifesta em todas as fases de seu ciclo de vida. Qualidade para iniciar, desenvolver, testar, implantar e manter o software ativo, atualizado e com bom desempenho. Esta área lida quase que totalmente com o intelecto humano. Novos métodos, ferramentas e técnicas são criados dia a dia, para aumentar a eficiência dos testes e da manutenção. Estes capítulos lidam com a melhoria do produto software, testes, diagnósticos, manutenção e controle das mudanças. Serão abordados os principais modelos da qualidade e suas práticas, métodos avançados de testes, o serviço de manutenção e evolução do software ao longo de seu ciclo de vida. Prof. Me. Edson Quedas Moreno 7 3. QUALIDADE E PRODUTIVIDADE DE SOFTWARE 3.1. Qualidade: uma abordagem da engenharia de software A abordagem da Engenharia de Software trabalha buscando uma única meta: produzir software de alta qualidade. A qualidade é importante, mas se o usuário não está satisfeito, nada mais realmente importa. Principais objetivos da qualidade: Reunir um conjunto de características, regras e procedimentos de modo que o software satisfaça às necessidades de seus usuários; Levar menos tempo para fazer uma coisa correta, do que explicar o porquê foi feito errado; Garantir a qualidade mesmo depois de estar pronto o produto; Estabelecer cronogramas e custos reais. Orientação e estratégia do Programa Brasileiro da Qualidade e Produtividade (PBQP) Avaliação e revisão dos indicadores e métodos de medição da qualidade e produtividade; Desenvolvimento da infraestrutura de serviços tecnológicos; Ampliação e consolidação da qualidade e produtividade na indústria; Melhoria da qualidade e produtividade no comércio; Melhoria da qualidade e produtividade em serviços; Qualidade e produtividade nas micros e pequenas empresas. 3.2. Fatores da qualidade de software Os principais fatores da qualidade de software são: Controle da qualidade; Garantia da qualidade; e Custo da qualidade. Satisfação do usuário = produto adequado + máxima qualidade + entrega dentro do orçamento e do cronograma 8 Processo de controle da qualidade do software O controle de qualidade é um termo usado amplamente na indústria e se refere à definição de processos e padrões a serem estabelecidos na produção. O objetivo é aplicar os processos e padrões, e consequentemente eliminar produtos, que não atingiram o nível de qualidade exigida. A figura 1 mostra como é aplicado o controle da qualidade do software. Figura 1 – Processo de controle da qualidade do software Fonte: elaborado pelo autor, 2019. Garantia de Qualidade de Software (GQS) – Software Quality Assurance (SQA) O propósito da garantia de qualidade de software é fornecer à gerência a visibilidade da eficácia (aquilo que dá bom resultado): Examinar minuciosamente um artefato de software ou estado do projeto com a finalidade de determinar se há algum desvio com relação aos padrões, diretrizes, especificações, procedimentos e planos aprovados; As revisões devem ser aplicadas em vários pontos de função durante o desenvolvimento e servem para descobrir defeitos enquanto estes ainda são relativamente baratos para serem tratados. 9 Custo da qualidade O custo da qualidade pode ser entendido como o preço justo, que o cliente esteja disposto a pagar. Estes custos podem ser divididos em: Custos de prevenção – Planejamento; Revisões; Ferramentas de diagnósticos e testes; e Treinamento. Custos de avaliação – Inspeção infra e inter processos; Precisão e manutenção dos equipamentos. Custos de falha interna – Refazer; Reparar; e Análise do modo como a falha ocorreu. Custos de falha externa – Solução das queixas; Devolução e substituição do produto; Manutenção da linha de suporte; e Trabalho de garantia. Figura 2 – Estudo de Caso sobre a IBM, realizado por Boehm, referente a resultados do controle de Qualidade Fonte: BOEHM, B. W. IEEE Computer1. (Gráfico adaptado) 1 Disponível em: https://www.computer.org/profiles/barry-boehm. Acesso em: nov. 2002. Estudo de Caso: “Os dados relatados por Kaplan, Clark e Tang em 1995, são baseados em trabalhos da instalação de desenvolvimento de software da IBM” 7.053h. foram gastas para inspecionar 200.000 linhas de código, resultando 3.112 defeitos em potencial. Se considerar o custo de programador equivalente a US$ 40,00 por hora, temos que o custo total para prevenir defeitos é igual a US$ 282.120,00, ou seja, aproximadamente US$ 91,00 por defeito; Sem inspeções, mas com programadores supercuidadosos, foram registrados 1 defeito por 1.000 linhas de código. O que significa que 200 defeitos foram corrigidos em campo a um custo de US$ 25.000,00 por defeito. O que reflete um gasto de US$ 5.000.000,00, 18 vezes mais caro do que o custo da prevenção. Os dados relatados por Kaplan, Clark e Tang (1995) são a confirmação do gráfico apresentado pela pesquisa de Boehm (1981), que mostra como o custo da falha aumenta se migrarmos do custo da prevenção até os custos de falhas externas. 10 Fatores e Métricas da qualidade do software “Qualidade de software é uma mistura complexa de fatores que vão variar com cada aplicação diferente e com os clientes que as encomendam” (PRESSMAN, 2002). Os fatores de qualidade do software caracterizam um conjunto de métricas da qualidade (forma de medição) e que podem ser divididos em dois grupos: 1. Fatores que podem ser medidos diretamente. Exemplo: defeitos por ponto de função; 2. Fatores que podem ser medidos indiretamente. Exemplo: usabilidade ou mantenabilidade (ou manutenibilidade). As métricas de qualidade do software são medidas quantitativas que permitem aos desenvolvedores do software ter ideia da eficácia do processo de software e dos produtos que são conduzidos usando o processo como arcabouço. As métricas de qualidade também são usadas para detectar áreas de problemas de maneira que soluções possam ser apresentadas, e que o processo de software possa ser melhorado. São coletados dados básicos de produtividade e qualidade pelos engenheiros de software, esses dados são analisados, comparados com médias anteriores e avaliadospara verificar se ocorreu melhoria ou não pelos gerentes de software. Exemplo de análise: Fatores X Métricas da qualidade do software (PRESSMAN, 2007; SOMMERVILLE, 2011; PAULA FILHO, 2012). MÉTRICA DE QUALIDADE FATORES DE QUALIDADE Confiabilidade Eficiência Mantenabilidade Utilização Autodocumentação X Complexidade X Concisão X X Consistência X X Eficiência de execução X Instrumentação X Modularidade X X Operabilidade X X Precisão X Simplicidade X X Tolerância a erro X 11 Treinamento X Principais métricas de qualidade do software MÉTRICA DEFINIÇÃO Acurácia Capacidade de o produto de software prover, com o grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados. Adaptabilidade Capacidade de o produto de software ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado. Adequação Capacidade de o produto de software prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados. Analisabilidade Capacidade de o produto de software permitir o diagnóstico de deficiências ou causas de falhas no software, ou a identificação de partes a serem modificadas. Apreensibilidade Capacidade de o produto de software possibilitar ao usuário aprender sua aplicação. Atratividade Capacidade de o produto de software ser atraente ao usuário. Auditabilidade Facilidade no atendimento às normas que pode ser verificado. Auto documentação Nível em que o código-fonte fornece documentação significativa. Capacidade Capacidade de o produto de software ser instalado em ambiente especificado e atender aos requisitos de funcionamento. Coexistência Capacidade de o produto de software coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns. Corretitude Satisfação da especificação e cumprimento dos objetivos da missão do cliente. Confiabilidade A efetiva realização das funções de um programa um nível de desempenho e precisão especificadas. Conformidade Capacidade de o produto de software estar de acordo com normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas ao atributo do software. 12 Estabilidade Capacidade de o produto de software evitar efeitos inesperados decorrentes de modificações no software. Eficácia Capacidade de o produto de software permitir que usuários atinjam metas especificadas com acurácia e completitude, em um contexto de uso especificado. Eficiência Quantidade de recursos e códigos de computação para realização da função. Quanto menor a quantidade, maior será o desempenho do software. Expansibilidade Nível em que o projeto arquitetural de dados ou procedimental pode ser estendido. Flexibilidade Esforço necessário para modificar um programa operacional. Funcionalidade Capacidade de o produto de software prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas. Generalidade Âmbito da aplicação potencial dos componentes do programa. Integridade Diz respeito ao acesso do software ou dados por pessoas não autorizadas e que pode ser controlado. Modificabilidade Capacidade de o produto de software permitir que uma modificação especificada seja implementada. Interoperabilidade Capacidade de o produto de software interagir com um ou mais sistemas especificados. Integridade Controle do acesso aos dados de pessoas não autorizadas. Mantenabilidade Esforço necessário para localizar e corrigir erros num programa. Manutenibilidade Capacidade de o produto de software ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais. Maturidade Capacidade de o produto de software evitar falhas decorrentes de defeitos no software. Modularidade Diz respeito à independência funcional dos componentes do programa. Precisão Nível de precisão dos cálculos e do controle que pode ser verificado. Operacionalidade Capacidade de o produto de software possibilitar ao usuário operá-lo e controlá-lo. 13 Produtividade Capacidade de o produto de software permitir que seus usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um contexto de uso especificado. Segurança Capacidade de o produto de software apresentar níveis aceitáveis de riscos de danos às pessoas, aos negócios, da propriedade, do ambiente, de proteger informações e dados, de forma que pessoas ou sistemas não autorizados não possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou sistemas autorizados. Testabilidade Necessário o teste de um programa para validação, quando criado ou modificado, a fim de garantir que realize a função esperada. Portabilidade Capacidade de o produto de software ser transferido de um ambiente operacional para outro. Rastreabilidade Diz respeito à habilidade de rastrear uma representação de projeto ou componente real do programa. Recuperabilidade Capacidade de o produto de software restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha. Reutilização Quanto um programa ou parte dele pode ser reusado em outras aplicações. Satisfação Capacidade de o produto de software satisfazer usuários, em um contexto de uso especificado. NOTA – Satisfação é a resposta do usuário à interação com o produto e inclui atitudes relacionadas ao uso do produto. Usabilidade Capacidade de o produto de software ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas. Utilização Esforço necessário para aprender, operar, preparar entradas e interpretar saídas de um programa. Fonte: Pressman, 2007; NBR 9126; NBR 12207. 3.3 Qualidade do produto da engenharia de software: ISO/IEC 9126 e ISO 25000 (NBR 9126-1 ABNT, 2003) Figura 3: Marca da NBR ISSO/IEC 9126-1 14 Fonte: NBR 9126-1 ABNT (2003). Objetivo Esta parte da NBR ISO/IEC 9126 descreve um modelo de qualidade do produto de software, composto de duas partes: a) qualidade interna e qualidade externa; e b) qualidade em uso. A primeira parte do modelo (figura 4) especifica seis características para qualidade interna e externa, as quais são por sua vez subdivididas em subcaracterísticas. Essas subcaracterísticas são manifestadas externamente, quando o software é utilizado como parte de um sistema computacional, e são resultantes de atributos internos do software. Exemplos de usos da NBR ISO/IEC 9126: Validar a completitude de uma definição de requisitos; Identificar requisitos de software; Identificar objetivos de projeto de software; Identificar objetivos para teste de software; Identificar critérios para garantia de qualidade; Identificar critérios de aceitação para produtos finais de software. Estrutura do modelo de qualidade Abordagens para qualidade: Figura 4 – Processo de controle da qualidade no ciclo de vida do software 15 Fonte: NBR 9126-1 ABNT (2003). Modelo de qualidade para qualidade externa e interna O modelo de qualidade externa e interna mostrado na figura 5 categoriza os atributos de qualidade de software em seis características: Funcionalidade; Confiabilidade; Usabilidade; Eficiência; Manutenibilidade; e Portabilidade. As quais são subdivididas em subcaracterísticas (figura 5) que podem ser medidas por meio de suas respectivas métricas para qualidade externa e interna. 16 Figura 5 – Modelo de qualidade para qualidade externa e interna. Subcaracterísticas e métricas da ISO 9126 Fonte: NBR 9126-1ABNT (2003). Modelo de qualidade para qualidade em uso Os atributos de qualidade em uso são categorizados em quatro características mostradas na figura 6. Eficácia; Produtividade; Segurança; e Satisfação. 17 Figura 6 – Modelo de qualidade para qualidade em uso da ISO 9126 Fonte: NBR 9126-1 ABNT (2003). Norma Square ISO/IEC 25000 – Software Product Quality Requirements and Evaluation Esta norma diz respeito à descaracterização e medição de qualidade de produto de software. A ISO 25000 é uma evolução das séries de normas ISO/IEC 9126 e ISO/IEC14598. Square significa Software Product Quality Requirements and Evaluation (Requisitos de Qualidade e Avaliação de Produtos de Software). A norma ISO/IEC 25000 é composta por dez documentos: NORMA CONTEÚDO 9126-1 Modelo de qualidade de software. 9126-2 Métricas externas. 9126-3 Métricas internas. 9126-4 Métricas para qualidade em uso. 14598-1 Guia de avaliação – visão geral. 14598-2 Planejamento e gerenciamento de avaliações. 14598-3 Processo de avaliação para desenvolvedores. 14598-4 Processo de avaliação para adquirentes. 14598-5 Processo de avaliação para avaliadores. 14589-6 Documentação de módulos de avaliação. 18 A reorganização da Norma ISO/IEC 25000 gera uma nova divisão de assuntos em cinco tópicos, sendo que cada divisão é composta por um conjunto de documentos e trata de um assunto em particular: Requisitos de Qualidade Modelo de Qualidade Avaliação Gerenciamento de qualidade Medições 3.4 Sistemas da qualidade: ISO 9001 e ISO 90003 A série ISO 9000 A série ISO 9000, é uma parte dos diversos padrões emitidos pela ISO, a qual é definida como “Padrões para a Gerência da Qualidade e Garantia de Qualidade. Diretrizes para a Seleção e Uso”. Esta série descreve e explica os requisitos de um sistema de qualidade. No entanto, ISO-9000 não prescreve algum modelo específico para um Sistema de Qualidade. Para obtê-lo as organizações necessitam desenhar seus próprios sistemas de qualidade. Seu maior objetivo é certificar organizações no que concerne a Padrões de Qualidade, em uma determinada área da indústria. A norma ISO 9000 não foi desenvolvida especialmente para organizações que desenvolvem software, apesar de que foi emitido um adendo para adequar o padrão a empresas de software. A série ISO 9000 foi criada sob a premissa de que: “se a produção e a administração do sistema de qualidade são corretas, o produto ou serviço que é produzido também será correto”. Descrição da série ISO 9000 e outros relacionados A série ISO-9000, provê diretrizes e modelos para orientar a implementação de um sistema de Qualidade. Seu primeiro conjunto de normas é o ISO 9000 e está dividida em quatro partes, nas quais se esclarecem as diferenças entre os principais conceitos de qualidade, e provê diretrizes para a seleção e uso: ISO 9000: Gestão e Garantia da Qualidade: diretriz para a seleção e uso das partes: o ISO 9000-1: Seleção e uso. o ISO 9000-2: Diretrizes genéricas para a aplicação da ISO 9001, ISO 9002 e ISO 9003. 19 o ISO 9000-3: Diretrizes para a aplicação da ISO-9001 em desenvolvimento, fornecimento e manutenção de software. o ISO 9000-4: Aplicações da gestão de dependência. A seguir são as normas da ISO 9001 a ISO 9003, nas quais se especificam os requisitos do Sistema de Qualidade. A mesma deve ser usada quando existe um contrato entre duas partes, o qual requeira a demonstração da capacidade de um fornecedor em desenvolver e fornecer um produto, software em nosso caso, com uma qualidade garantida. ISO 9001: Modelo de Garantia de Qualidade em projeto, instalação, desenvolvimento, produção, arquitetura e serviço. ISO 9002: Modelo de Qualidade em produção, ensaios e instalação. ISO 9003: Modelo de Garantia de Qualidade em inspeção e ensaios finais (testes). ISO 9004: Gestão da Qualidade e elementos do sistema da qualidade. ISO 9001 A ISO 9001 é usada para demonstrar capacidade de atender aos requisitos do cliente, os regulamentares e os da própria organização. Define um conjunto de requisitos para o Sistema de Gestão da Qualidade (SGQ) com base nas seguintes cláusulas: Responsabilidade gerencial. Sistema de qualidade. Análise crítica de contratos. Controle de projetos. Controle de dados e documentos. Controle de produtos fornecidos pelo cliente. Identificação de produtos e rastreabilidade. Controle do processo. Teste e Inspeção. Controle de equipamentos de testes, medições e inspeções. Situação de testes e inspeções. Controle de produto sem conformidade. Ação corretiva e preventiva. Manuseio, armazenamento, empacotamento, proteção e entrega. Controle de registros de qualidade. 20 Auditorias internas de qualidade. Treinamento. Assistência técnica. Técnicas estatísticas. ISO 90003 A ISO 90003 é uma evolução da norma ISO 9000-3:2000, que descreve as Diretrizes para à aplicação da ISO 9001. Na ISO 90003:2004 os principais pontos são: Planejamento da realização do Produto: Ciclo de Vida – Deve conter as etapas de teste, verificação, acompanhamento (análise crítica) e validação. Plano de Qualidade – Para um projeto específico, requisitos específicos e definição das alterações em vigor do SGQ. Requisitos da qualidade (produto e processo). Processos relacionados ao cliente: Determinação dos Requisitos do Produto – Elicitação dos requisitos, aprovação pelo cliente, requisitos implícitos, requisitos legais, normativos ou do próprio fornecedor. Análise crítica dos requisitos – Edital, proposta, contrato, capacidade para atender, orientações específicas do software, padrões, plataformas, ambientes, ferramentas, ciclo de vida e risco. Comunicação com o cliente – Suporte, manutenção e helpdesk. Projeto de Desenvolvimento: Planejamento – Work Breakdown Structure – WBS (Estrutura Analítica do Projeto), cronograma, etapas, responsabilidades, atividades de controle, interfaces, recursos e ambiente. Entradas – Elementos necessários para compor a WBS. Saídas – Saídas das fases, produto final, código fonte e objeto, manuais, documentação e relatórios de testes. Análise crítica de projeto – Design review e tomada de decisão. Verificação – Simulações, walkthrough, inspeções, demonstrações com protótipo. Validação – Atendimento aos requisitos no ambiente de uso pretendido; teste unitário, integração, sistema, regressão e aceitação. Alteração de projeto – Havendo alterações, deve retornar ao planejamento. 21 Aquisição: Aquisição de insumos (ferramentas e hardware). Subcontratações ou aquisição de partes das funções do software. Inspeção e recebimento – Verificação, validação, aceitação e testes. Produção e Fornecimento de serviço: Controle de produção – Release, entrega, instalação, operação e manutenção. Identificação e Rastreabilidade – Gestão de configuração. Propriedade do cliente – Componentes, ferramentas, ambiente operacional e de testes, e propriedade intelectual. Preservação do produto – Armazenamento, acesso, proteção contra vírus ou deterioração. Medição, Análise e Melhoria. 3.5 ISO 12207 – Processos do ciclo de vida do software Quando o processo envolve a elaboração de um produto, algumas vezes nos referimos a ele como ciclo de vida. Assim o processo de desenvolvimento de software pode ser chamado de ciclo de vida do software, pois ele descreve a ‘vida’ do produto de software desde a concepção até a implementação, entrega, utilização e manutenção (PFLEEGER, 2004). A Norma NBR ISO/IEC 12207 – Processos do ciclo de vida do software foi criada em 1995 com o objetivo de fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidoscom o desenvolvimento de software utilizem uma linguagem comum. Essa linguagem comum é estabelecida na forma de processos bem definidos. Esses processos são classificados em três tipos: fundamentais, de apoio e organizacionais, representados na figura 7 (NBR 12207 ABNT, 1998). 22 Figura 7 – NBR ISO/IEC 12207 – Processos do ciclo de vida do software Fonte: NBR 12207 ABNT (1998). De acordo com Pfleeger (2004), no ciclo de vida do software os estágios do desenvolvimento do software são: Análise e definição de requisitos; Projeto do sistema; Projeto do programa; Programação; Teste de unidades; Teste de integração; Teste do sistema; Entrega do sistema; e Manutenção. 23 Cada estágio pode ser interpretado como um processo (ou coleção de processos) e cada processo pode ser descrito de várias maneiras. A modelagem do processo inclui diversos e diferentes modelos de conduzir o ciclo de vida do software. O arcabouço de processo genérico e o modelo de ciclo de vida clássico do software são usados como base para a descrição dos modelos de processo nos tópicos a seguir, aplicável à grande maioria dos projetos de software (PRESSMAN, 2007. Adaptado): Comunicação: envolve alta comunicação e colaboração com o cliente, abrange o levantamento de requisitos e outras atividades. Planejamento: esta atividade estabelece um plano de trabalho de engenharia de software. São descritos: técnicas, riscos, recursos, produtos de trabalho e cronograma de trabalho. Modelagem: inclui a criação de modelos que permitam ao desenvolvedor e cliente, entender melhor os requisitos e o projeto do software. Construção: combina a geração de código e testes necessários. Implantação: o software é entregue ao cliente, que avalia o produto e fornece feedback. 3.6 Modelo de qualidade de software: Capability Maturity Model Integration (CMMI) Originalmente definido na v 1.1 em 1993 por Paulk, o Modelo de Maturidade e Capacidade para Software (CMM – Capability Maturity Model for Software) foi baseado em seis anos de experiência com melhoria de processo de software e a contribuição de centenas de revisores. O CMM descreve a criação de software, baseadas em práticas administrativas, caracterizadas pelas organizações das formas de como elas amadureceram os processos para desenvolver e manter software. O CMM acentua a necessidade da armação de maturidade do processo, priorizando ações de melhoria, descreve a estrutura de maturidade do processo em cinco níveis e os componentes estruturais associados. O CMM determina práticas recomendadas em certo número de Áreas-Chave de Processo (KPA – Key Process Area), que provê a organização do desenvolvimento de software, baseada nas melhores estratégias para controlar, manter e evoluir os processos administrativos do desenvolvimento de software. O CMMI é o modelo de maturidade sugerido recentemente com o fim de unificar e agrupar as diferentes usabilidades do CMM e de outros modelos de processos de melhoria corporativo, tais como o ISO 9001. São raras as empresas no mundo que conseguem atingir o nível 5, a grande maioria fica nos estágios iniciais. No Brasil, até o ano (2007), existiam somente 4 empresas que tinham alcançado o nível 5 do CMMI. Fases do processo de maturidade: Capacidade do processo de software – É uma descrição de resultados previstos e resultados que podem ser arquivados para alcançar os objetivos do projeto, que devem ser arquivados para serem utilizados em futuros projetos. 24 Desempenho do processo de software – Representa o resultado atual comparado com o resultado previsto. Quanto mais o resultado atual se aproximar do resultado previsto, melhor é o desempenho do processo de software. Maturidade do processo de software – Indica o quanto o processo de software está explicitamente definido. A maturidade mede a consistência entre os resultados previstos antes de se começar o processo com aqueles obtidos após o fechamento do processo. Deve prover ferramentas administrativas que garantem a medição, o controle e a efetivação do processo. Os cinco níveis de maturidade Os níveis de maturidade estão baseados em pequenas etapas no lugar de inovações revolucionárias. Esses níveis estão organizados de forma que garantem a melhoria contínua do processo. Cada nível de maturidade constitui em um conjunto de metas que quando satisfeita estabilizam um componente importante do processo. Figura 8 – Os cinco níveis de maturidade do processo do CMMI Fonte: CMMI Product Development Team – SEI (2000) 25 Áreas Chave de Processo (ACP) (Key Process Area – KPA) Gerencial Planejamento de projeto de software e gerência Organizacional Revisão e controle pela gerencia sênior Engenharia de software, Especificação, design, codificação e controle de qualidade Nível 1 – Inicial (Processo Caótico – indica a fase de iniciação da implementação dos processos) Nível 2 – Repetitivo (Processo Disciplinado) Acompanhamento e Controle de Projeto Gerência de Configuração Gerência de Requisitos Gerência de Subcontratação Medição e Análise Planejamento do Projeto Garantia de Qualidade de Processo e Produto Nível 3 – Definido (Processo Padronizado e Consistente) Análise de Decisão e Resolução Gerência de software Integrada Definição do Processo da Organização Foco no Processo da Organização Programa de Treinamento Validação Desenvolvimento de requisitos Gerenciamento de Risco Integração do produto Solução técnica dos requisitos Verificação Nível 4 – Gerenciado (Processo Previsível) Gerenciamento Quantitativo de Processos Desempenho do processo organizacional Nível 5 – Otimização (Melhoria Contínua) Gestão do processo organizacional Análise e Resolução de Causas 3.7 Modelo de qualidade de software: SPICE – ISO 15504 A ISO/IEC 15504, também conhecida como SPICE que significa Software Process Improvement & Capability dEtermination (Melhoria do Processo de Software e Determinação da Capacidade) é a norma que define uma série de atividades para manter a qualidade de software, foi publicada em outubro de 2003, mas seu projeto começou em 1993 pela ISO com base nos modelos já existentes como ISO 9000 e CMMI. Ela é uma “evolução” da ISO/IEC 12207, que possui níveis de capacidade para cada processo. 26 O framework inclui um modelo de referência, que serve de base para o processo de avaliação. Um conjunto processos fundamentais que orientam para uma boa engenharia de software, e estabelece duas dimensões: 1. Dimensão de processo; e 2. Dimensão de capacidade. Na dimensão de processo o modelo é dividido em cinco grandes categorias de processo: Cliente-Fornecedor; Engenharia; Suporte; Gerência; e Organização. Na dimensão de capacidade o objetivo é avaliar a capacitação da organização em cada processo e permitir a sua melhoria. O modelo de referência do SPICE inclui seis níveis de capacitação dos processos: Incompleto; Realizado; Gerenciado; Estabelecido; Previsível; ou Otimizado. Elementos normativos da ISO 15504 Os elementos normativos da ISO 15504 – SPICE, apresentado na figura 9, estabelecem um plano de análise e desenvolvimento para efetivar o processo de avaliação. 27 Figura 9 – Elementos normativos da ISO 15504 – SPICE Fonte: CÔRTES (2017) Dimensão dos processos da ISO 15504 Observe a figura 10, similar a ISO 12207 em que estabelece as áreas de processos: Primários, Organizacionais e de Apoio. Na dimensão dos processos da ISO 15504 apresenta os subprocessos e respectivas atividades. 28 Figura 10 – Dimensão dos processos da ISO 15504 – SPICE Fonte: CÔRTES (2017) 3.8 Exercício discursivo comentado O Capability Maturity Model Integration (CMMI)é um programa e serviço de treinamento e certificação para aprimoramento de processos administrados e comercializados, exigidos por muitos programas do Departament of Defense USA (DOD) e do governo para contratos governamentais, especialmente desenvolvimento de software. A Universidade Carnegie Mellon afirma que o CMMI pode ser usado para orientar a melhoria de processos em um projeto, divisão ou a organização inteira do desenvolvimento do software. Para avaliar nas organizações o estado de maturidade de um software a SEI utiliza o CMMI, que define em média dezenove Áreas-Chave de Processo (KPA) das atividades requeridas em cinco níveis de maturidade dos processos. Explique os cinco níveis de maturidade e cite algumas de suas KPA. 29 Resposta: Nível 1: Inicial – O processo encontra-se em um estado caótico. Poucos processos estão definidos e o sucesso depende do esforço individual. Nível 2: Repetitivo – O processo básico de gerenciamento do projeto está feito e está estabelecido às tarefas, custos, tempo e funcionamento. É necessário disciplinar o processo e estabelecer as tarefas: Acompanhamento e Controle de Projeto; Configuração do software gerenciável; Garantia da qualidade do software; Subcontratos de software gerenciável; Tarefas e omissões do projeto de software; Planejamento do projeto de software; e Gestão dos requisitos. Nível 3: Definido – As atividades do processo de software para a gerência e engenharia estão documentadas, iniciadas e integradas dentro da organização. Deve-se estabelecer as tarefas: Revisões minuciosas; Coordenação intergrupos; Prática da engenharia no produto de software; Gestão da integração do software; Programa de treinamento; Definição do processo organizacional; e Foco organizacional no processo. Nível 4: Gerenciável – São colhidos detalhes mensuráveis sobre o processo e o produto de software. Deve-se estabelecer: Gestão da qualidade no software; e Gestão do processo de quantificação. Nível 5: Otimizado – A melhoria contínua do processo está habilitada pelo retorno da quantificação do processo, testes inovativos de ideias e tecnologia. Deve-se estabelecer: Gestão de mudanças do processo; Gestão de mudanças de tecnologia; e Prevenção de defeitos. 30 4. TESTES DE SOFTWARE 4.1 Fundamentos dos testes de software O teste do software é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados fictícios. Os resultados do teste são verificados à procura de erros, anomalias ou informações sobre os atributos não funcionais do programa (SOMMERVILLE, 2011). O teste muitas vezes requer mais trabalho de projeto do que qualquer outra ação da engenharia de software (PRESSMAN, 2011). De acordo com Pressman (2011), “o software é testado para revelar erros cometidos inadvertidamente quando projetado e construído”. A principal métrica do teste de software é a testabilidade, que é necessária para validar o software, quando criado ou modificado, de forma a garantir que realiza a função esperada. A testabilidade examina as diferentes probabilidades e características comportamentais que levam o código a falhar se alguma coisa estiver incorreta. Um índice alto de testabilidade indica a facilidade do software de expor as falhas que geram defeitos. Um índice baixo de testabilidade indica a dificuldade de identificar falhas que geram defeitos. Definido por Barry Boehm em 1979 (apud PRESSMAN, 2011 e SOMMERVILLE, 2011) O teste é uma parte ampla da engenharia de software e faz parte dos processos de validação e verificação (V&V). 4.2 Verificação e Validação (V&V) A verificação é a ação de verificar ou inspecionar o produto, por meio da análise, testes, diagnósticos e simulações, para assegurar que o que foi construído, foi construído da forma correta de acordo com as exigências. A validação demonstra conveniência satisfatória das partes interessadas no uso do produto, no ambiente operacional planejado. O objetivo da validação é demonstrar que um produto criado, ou seus componentes satisfaçam o objetivo quando é colocado ou testado no ambiente de trabalho, ou seja, no cliente final. A validação pode ser solicitada durante o processo de desenvolvimento do produto e não somente no produto final. A validação vai demonstrar quão o produto pronto na verdade vai operar corretamente no usuário, para isso as atividades de validação usam aproximações semelhantes ao da verificação. Frequentemente as atividades de validação e de verificação trabalham simultaneamente e podem usar porções do mesmo ambiente. A verificação assegura você construiu direito; e A validação assegura que você construiu a coisa certa. 31 Atividade de verificação No processo de software a engenharia de sistemas define o papel do software, que inicialmente passa para a análise dos requisitos de software. A atividade de verificação consiste em confrontar o que foi especificado como requisito do software, com o resultado obtido pelo software, para garantir que o que foi projetado, foi construído de acordo. Nesta fase alguns outros problemas podem ser identificados, não somente como um erro ou uma falha, mas também inconsistências com os requisitos ou alinhamento da configuração do sistema com o software em produção. A atividade de verificação inicia pelo código fonte, no qual vários testes são realizados de forma a garantir que lógica de construção do algoritmo está correta, posteriormente são realizados testes da estrutura e formato da informação e finalmente testes de integração do sistema. Tudo inicia pelo teste da lógica do processamento e o ponto chave desta atividade está na verificação do código fonte. Atividade de verificação e depuração de falhas (debug) do código fonte Na verificação do código fonte faz-se o que é chamado de depuração. Do dicionário da língua portuguesa, depuração é a atividade de limpeza ou exclusão de partes indesejáveis. No desenvolvimento do software erros ocorrem, seja por uma “trava” do programa ou algum comportamento inesperado. No processo de desenvolvimento do software, depuração é a atividade de rastreamento do código fonte, com objetivo de corrigir e reduzir falhas no programa de computador. Para depurar falhas no software (debug) é necessário fazer o rastreamento do código no tempo de execução do programa, de onde vem à palavra Trace (rastrear). O rastreamento de um bug inicia com testes para reproduzir o problema e buscar o ponto de erro. Ao encontrar o erro faz-se um diagnóstico, que pode ser informal ou quando houver necessidade um relatório formal de registro do erro. No diagnóstico deve constar o erro identificado e possíveis soluções para o problema. A atividade da depuração de falhas (debugging) mostrada na figura 11 consiste de 4 tarefas: 1. Reprodução (Reproduce): consiste em rastrear o erro com objetivo de identificar a causa de um determinado problema. Neste caso usar breakpoints (pontos de parada no software). 2. Diagnóstico (Diagnose): avaliar o ponto do erro, sua causa, gravidade, grau de prioridade, riscos e impactos no comportamento do software (no programa em análise e em outros programas). 3. Corrigir (Fix): Implementação e testes para as correções necessárias. 4. Refletir (Reflect): aplicação das medidas corretivas de forma a garantir solução para o problema, analisar se a mudança não impacta em outras características do sistema, validações das entradas/saídas, otimização do código e garantia de encapsulamento. 32 Figura 11 – Atividades da Depuração, Testes e Diagnósticos Fonte: elaborado pelo autor, 2019. Engenharia de requisitos e a atividade de validação Veja a figura 12. A atividade de validação é a última fase do processo da engenharia derequisitos, responsável por autorizar o desenvolvimento do sistema / software. É a tarefa de apresentar o documento de requisitos em reunião com a participação do grupo formado pelos interessados no sistema. O objetivo é aprimorar, incluir mudanças propostas e aprovar o início do projeto e desenvolvimento do software/sistema. Figura 12 – Modelo do Processo da Engenharia de Requisitos do software / sistema: Estudo da Viabilidade do sistema Especificação, Modelagem e Documentação Elicitação e Análise de requisitos Validação Nova Iteração Início Desenvolvimento do Sistema Fonte: elaborado pelo autor, 2019. O documento a ser validado pode ser elaborado para um único sistema, parte do sistema ou para cada funcionalidade do sistema. Vale o bom senso, a análise decisiva deve ter base no tamanho, complexidade ou qualidade exigida, do sistema 33 ou da funcionalidade, associada ao seu prazo e custo. Este documento pode ser interpretado como o “Aceite do cliente”. Critérios de validação Critérios de validação são especificações para demonstrar o entendimento e viabilizar uma implementação de software bem-sucedida, logo que informações básicas, funções, desempenho, comportamento e interfaces forem descritos. Esses critérios servem de base para as atividades de teste que ocorrerão posteriormente no processo de engenharia de software. Um Manual do Usuário preliminar pode ser rascunhado para casos em que um protótipo não tenha sido desenvolvido. O manual estimula o usuário / cliente a revisar o software a partir de uma perspectiva de engenharia humana: Exemplo: Comentário do usuário: “A ideia é boa, mas não é desse jeito que eu pretendia fazer isso…”. Esses tipos de comentários devem ser feitos o quanto antes no processo revisional. Auxilia a melhoria ou entendimento do produto. O processo revisional antes de finalizado, normalmente resulta em modificações na função, desempenho, representações da informação, restrições ou critérios da validação. 4.3 Técnicas de testes de software Um princípio básico na realização de Testes de Software (principalmente em Sistemas de média complexidade para cima) é diferenciar a equipe puramente de desenvolvimento, da equipe especificamente de testes. O processo V&V inclui inspeção e revisão. São verificados os requisitos do sistema, modelos de projeto, o código fonte e outros testes propostos, em diferentes situações do processo de software. O nível alto de testes do software baseia-se nas opiniões do usuário em obter resultados que atendam as suas expectativas, bem como falhas ou omissões de requisitos. O nível baixo de testes do software está fundamentado na codificação da lógica de processamento, que fornece o resultado desejado pelo algoritmo construído. Nesse contexto e de uma forma genérica a visão do desenvolvedor baseia-se nas abordagens top-down e bottom-up, veja a figura 13. Abordagens top-down e bottom-up As técnicas top-down são dedutivas, partem do problema destacado pelo usuário e procede por parte do usuário e desenvolvedores à análise das questões que possam ter gerado o problema. As técnicas bottom-up são indutivas, os Quem desenvolve não testa e quem testa não desenvolve. 34 desenvolvedores partem de uma determinada situação, possível de gerar algum problema ou risco. A abordagem top-down (figura 13), verifica a integração dos componentes de um sistema começando pelos níveis superiores (operações e interface com o usuário) e pode caminhar para os níveis inferiores incluindo testes do código. Em sistemas, o foco principal desse teste é caminhar da informação ou resultado, até os dados que a geraram. A abordagem bottom-up (figura 13), começa pelos níveis inferiores (algoritmos, interface com usuário, interface com o hardware, drivers e instalação) e caminha para os níveis superiores. A abordagem bottom-up, normalmente é usada em instantes do desenvolvimento do software. Figura 13 – Níveis de abordagens top-down e bottom-up Fonte: elaborado pelo autor, 2019. F Testes Alfa e Beta No processo V&V quando um software é construído especificamente para um cliente, é normal que ele passe por um Teste de Aceitação por parte do usuário. Esse teste por ser conduzido pelo próprio usuário pode passar por uma bateria de testes levando às vezes semanas, ou mesmo meses, para ser finalizado. No entanto, se o software for feito para vários clientes ou usuários, pela sua amplitude o Teste de Aceitação não é viável para ser realizado por cada usuário em potencial. Por isso, a melhor estratégia a ser aplicada são as dos Testes Alfa e Beta, destinados a validar o software em ambientes amplos de aplicação. Para a realização do Teste Alfa existe a necessidade de um ambiente controlado. Os usuários são levados a testar o software desde seus estágios iniciais de instalação, até a sua operação completa. Tudo realizado num ambiente especial, onde ficam registradas todas as impressões dos usuários, suas reações às interfaces homem-máquina, erros, operações, e demais problemas de uso. top-down bottom-up Software / Sistema Funcionalidade 1 Funcionalidade 2 n Funcionalidades Função 1 Função 2 n Funções Código (software) Interface (usuário) Interface (hardware) Desempenho e Segurança 35 O Teste Beta é normalmente acompanhado da disponibilização de um release, é realizado exclusivamente no habitat do usuário em ambiente descontrolado. Tipicamente sem a presença do desenvolvedor, porém monitorados por estes, ao contrário do Teste Alfa. Os usuários envolvidos no teste normalmente possuem um perfil crítico e colaborador. Em alguns casos, o software é fornecido a usuários de forma que os desenvolvedores consigam do próprio usuário suas observações, questionamentos e sugestões, registros minuciosos com riqueza de detalhes ou registros curtos para quantificar observações. Testes Caixa-Branca e Caixa-Preta Para um sistema encomendado ou configurado especificamente para um determinado negócio, o processo de V&V tem como objetivo demonstrar que um software atende aos requisitos especificados (verificação) e que realmente atendam as expectativas dos stakeholders (validação). Os testes Caixa-Branca e Caixa-Preta são guiados pelo código-fonte, respectivas métricas de software aplicáveis e se realmente estão atendendo aos requisitos com um bom desempenho e segurança. O Teste Caixa-Branca também chamado de Teste Estrutural, é focado nos possíveis erros internos de estrutura dos componentes do software ou sistema. O Teste Caixa-Preta também chamado de Teste Comportamental visa identificar as falhas em seu comportamento externo, com foco nos requisitos funcionais e conduzidos na interface de software com o usuário e com o hardware. Uma das técnicas de maior aplicação no Teste Caixa-Branca é chamada de Teste do Caminho Básico. Esse teste tem como objetivo derivar casos de testes, orientados por meio do caminho de execução do programa. Para isso é usado o Grafo de Fluxo. O grafo de fluxo pode ser construído com base em um fluxograma ou diagrama de atividades. Uma das notações de grafo de fluxo, sugeridas por Pressman (2007) é para acompanhamento da codificação como é mostrado de forma adaptada na figura 14. Figura 14 – Simbologia de comandos estruturados para o grafo de fluxo Fonte: adaptado de PRESSMAN, 2007. Sequência Enquanto (while) Repete … até (repeat … until) (do … while) 1 3 2 4 Se … então … se não (if … then … else) 1 2 2 2 3 3 1 1 36 O Teste Caixa-Preta não é uma alternativa em relação ao Teste Caixa-Branca. É um complemento. O principal objetivo do Teste Caixa-Preta é testar as operações ligadas aos requisitos funcionais. De acordo com Pressman (2011), o Teste Caixa-Preta tenta encontrar erros nas seguintes categorias: Funções incorretas ouomitidas; Erros de interface; Erros de estrutura de dados ou de acesso à base de dados pelo usuário; Erros de comportamento ou desempenho; e Erros de iniciação e finalização do software. Principais técnicas utilizadas nos Testes de Caixa-Preta: Métodos de teste baseados em grafo de fluxo: o Modelagem de fluxo de transação – sequência de passos de uma determinada transação. o Modelagem de estado finito – situação final das operações e das estruturas de dados, com objetivo de reduzir redundâncias de códigos e dados. o Modelagem do fluxo de dados – modela a sequência de tratamento dos dados entre um objeto e outro. o Modelagem no tempo – especificação de tempos na execução de programas. Particionamento de equivalência – método que divide o domínio de entrada de um programa em classes de dados. Análise de valor-limite – avaliação dos limites dos campos de entradas de dados. Teste de Matriz Ortogonal – refere-se ao número de parâmetros de entrada em relação ao número de ligações às funções operacionais. 4.4 Exercício discursivo comentado A Assessoria e Serviços em Tecnologia da Informação (ASSERTI) é uma empresa que fornece serviços de consultoria na depuração do software, usando a engenharia reversa, ou seja, inicia pelas operações do usuário que geraram uma determinada informação. O código é rastreado desde a informação gerada até os algoritmos que coletaram os dados e que foram responsáveis por gerar a informação. Deste serviço é feito um projeto que serve para validação do código. Um de seus principais clientes é a auditoria da receita federal, que usa este processo de depuração em empresas que possuem sistemas de informação do tipo ERP. A atividade de depuração de falhas (debugging) consiste de 4 tarefas. Explique cada uma delas: 37 Resposta: Reprodução (Reproduce): consiste em rastrear o erro com objetivo de identificar a causa de um determinado problema. Neste caso usar breakpoints (pontos de parada no software). Diagnóstico (Diagnose): avaliar o ponto do erro, sua causa, gravidade, grau de prioridade, riscos e impactos no comportamento do software (no programa em análise e em outros programas). Corrigir (Fix): Implementação e testes para as correções necessárias. Refletir (Reflect): aplicação das medidas corretivas de forma a garantir solução para o problema, analisar se a mudança não impacta em outras características do sistema, validações das entradas/saídas, otimização do código e garantia de encapsulamento. 38 5 MANUTENÇÃO DO SOFTWARE 5.1 Fundamentos da manutenção O processo de mudança do software ocorre em todo o seu ciclo de vida. Várias mudanças são feitas: adaptações a novos ambientes operacionais, customização do software com base nas mudanças de requisitos, erros de codificação, adaptação de novas interfaces, enfim tudo o que é necessário para manter o software operacional e adaptado a novas tecnologias. 5.2 Tipos de manutenção Extraído e adaptado do modelo de Sommerville (2003), a manutenção será necessária durante todo o ciclo de vida útil do software, e pode ocorrer motivada por três tipos fundamentais: TIPOS DE MANUTENÇÃO DESCRIÇÃO Manutenção para reparar defeitos no software A correção de erros de codificação é um processo relativamente barato comparado com os erros de projeto. Os maiores custos estão nos erros de requisitos, pois irá implicar num reprojeto. Manutenção para adaptar o software a um ambiente operacional diferente É a típica manutenção de adaptação devido a alguma alteração na infraestrutura da tecnologia, tal como: mudança ou atualização do Sistema Operacional, estrutura do Banco de Dados modificada, ou até mesmo mudanças de hardware. Manutenção para fazer acréscimos à funcionalidade do sistema ou modificá-la. Se refere a mudanças organizacionais ou mudança das regras do negócio. Consequentemente levando às alterações dos requisitos. É a manutenção mais comum entre todas as outras. Estudo de caso: Leis de Lehman de 1985 (apud PRESSMAN, 2011) As leis de Lehman foram produzidas com base no estudo da mudança em sistemas. Foram examinados o crescimento e a evolução de uma série de grandes sistemas e software para chegar nessas leis. Duas destas leis se destacam: Mudança Contínua: a qual afirma que um programa utilizado em um ambiente do mundo real necessariamente tem de ser modificado ou se tornará de maneira progressiva menos útil nesse ambiente; Aumento da Complexidade: à medida que um programa em evolução se modifica, sua estrutura tende a se tornar mais complexa. Recursos extras precisam ser dedicados para preservar e simplificar a estrutura. 39 5.3 Procedimentos de manutenção O Processo de Manutenção é normalmente iniciado pelos pedidos de mudança por parte dos vários usuários que utilizam o sistema. Isso pode ser de maneira informal, ou preferencialmente formalizado, com uma documentação estruturada. Em seguida é verificado o custo e o impacto das mudanças sugeridas com as mudanças aprovadas, um novo release do sistema é planejado. Observe a figura 15. Uma vez bem estruturado, o Sistema 1 que embora tenha custos maiores de planejamento, exigiu no período de manutenção um menor custo e tempo. O Sistema 2 foi planejado mais rapidamente com custo e tempo inferiores ao do Sistema 1, porém exigiu no período de manutenção um maior custo e tempo. O resultado final é que no ciclo de vida o Sistema 1 obteve sobre o Sistema 2 um menor custo global em menor tempo. Figura 15 – Gráfico de custo e tempo do desenvolvimento e manutenção do software Fonte: elaborado pelo autor, 2019. Existem equipes de manutenção especializadas que atuam somente em Manutenção Corretiva, ou seja, somente quando existir um pedido dos usuários é que se atua no problema. No entanto, a melhor estratégia é a Manutenção Preventiva que é na qual se detectam possíveis falhas e previnem-se erros. E com um bom acompanhamento da equipe técnica, tais erros são registrados para que possa realizar uma força tarefa para correção de tais erros. 5.4 Gerenciamento de mudanças Durante os testes de sistemas, ou ainda depois da entrega do software ao cliente, os procedimentos de Gerenciamento de Mudanças devem ser aplicados. O principal passo desse processo é a utilização de um formulário intitulado de “Requisição de Mudança”. Veja o modelo da figura 16. Posteriormente ocorre o procedimento de manutenção do software. Modelo de formulário de requisição de mudança Formulário de Requisição de Mudança Projeto: SuperBlue Código da mudança: 190729 2106 Requisitor da Mudança: Edson Moreno Data: 29/07/2019 Custo ($) e Tempo (t) PLANEJAMENTO PLANEJAMENTO MANUTENÇÃO MANUTENÇÃO Sistema 1 Sistema 2 40 Requisito de mudança: Quando é removido um valor na tabela de custos fixos o valor do custo total não é alterado. Análise da mudança: Analista: Milton del Rio Blas Data: 29/07/2019 Componente afetado: Algoritmo de cáculo do custo total. Avaliação: Haverá necessidade de mudança no código de cálculo do custo total na lista de custo fixo. Prioridade: Alta Prazo estimado de entrega: 3 dias Autorizada mudança: SIM ( X ); NÃO ( ); Aguardar para o dia ____ / ____ / ________. Gerente Responsável: ____________________________ Fonte: elaborado pelo autor, 2019. Um formulário de Requisição de Mudança pode conter as seguintes informações: registro da solicitação da mudança, recomendações, custos, datas de solicitação, aprovação, implementação e validação da mudança. É sugerido também existir um espaço para um esboço, mostrando como a mudança deverá ser implementada. 5.5 Gerenciamento de versões e releases Como dito anteriormente, as mudançasocorrem em todo o ciclo de vida do software, quando aumentam o nível de complexidade e confusão compromete o controle na entrega do produto ou subproduto do software. O Gerenciamento de Versões e Releases acompanha e identifica o desenvolvimento das diferentes versões e releases de um sistema. Este processo é chamado de versionamento. O release é a versão do software ou do sistema produzido que é autorizada para distribuir ao cliente. Sempre existem muitas versões de um sistema, mais do que releases, porque as versões são criadas para testes ou desenvolvimento interno e não são liberadas para os clientes. Para a devida identificação de componentes existem três técnicas básicas: 41 TÉCNICAS BÁSICAS DESCRIÇÃO Numeração de versões É o esquema de identificação mais comum. Atribui-se um número, explícito e único, de versão ao componente. Um acompanhamento para este controle é apresentado na figura 17. Identificação baseada em atributos Cada componente recebe um nome e um conjunto de atributos, que não é único em todas as versões. Identificação orientada a mudanças Além do anterior é associado uma ou mais solicitações de mudança. Figura 17 – Modelo de grafo de controle aplicado na numeração de versões Fonte: elaborado pelo autor, 2019. Observe a figura 17. As versões (V 1.0, V 1.1 e assim por diante) acompanham as mudanças realizadas pelos desenvolvedores e os releases (Rel 1.0 e Rel 1.1) correspondem às versões aprovadas para distribuição ao usuário. A numeração do release independe da numeração da versão, porém neste caso pode se considerar o primeiro dígito como uma mudança de estrutura. Observe o exemplo abaixo. 5.6 Exercício discursivo comentado (ENADE 2011 – Tecnologia em Análise e Desenvolvimento de Sistemas. Adaptado) – A norma ISO/IEC FDIS 14764 (2006) estabelece definições de vários tipos de manutenção e fornece um guia para gerenciar o processo de manutenção, que pode ser aplicado no planejamento, execução e controle, revisão e avaliação, e fechamento do processo de manutenção. Segundo essa norma, solicitações de Exemplo: Nomenclatura dos atributos de versionamento. Padrão de numeração de versão: X.YZ, onde: X – corresponde a uma mudança de estrutura do software. Y – inserção ou adaptação de novas funções ou funcionalidade. Z – correções ou implementações no código fonte. V 1.0 V 1.1 V 1.1a V 1.1b V 1.2 V 1.3 V 1.31 Rel 1.0 Rel 1.1 42 modificação são classificadas como corretiva, preventiva, adaptativa ou perfectiva. Os detalhes de como implementar ou realizar as atividades e tarefas de manutenção não são especificadas pela norma, sendo de responsabilidade do mantenedor. (ISO/IEC FDIS 14764. Software Engineering – Software Life Cycle Processes – Maintenance. 2006.) Considerando os tipos de manutenção e as atividades de implementação do processo, avalie as afirmações a seguir: I. O mantenedor deve desenvolver, documentar e executar planos e procedimentos para realizar as atividades e tarefas do processo de manutenção. II. O mantenedor deve alterar a configuração do sistema para corrigir erros identificados pelos usuários usando a manutenção perfectiva. III. O mantenedor deve estabelecer procedimentos para receber, registrar e rastrear solicitações de modificação/registro de problemas dos usuários, e também prover realimentação para os usuários. IV. O mantenedor deve documentar a estratégia a ser usada para melhorar a manutenibilidade futura do sistema, usando a manutenção corretiva. Com base nas solicitações de modificações, avalie as afirmativas acima como V (Verdadeira) e F (Falsa) e justifique sua decisão. Resposta I. Verdadeira. As atividades de manutenção devem estar documentadas com procedimentos, tipo de testes, diagnósticos e mudanças a serem feitas, para não implicar em retrabalho. II. Falsa. A configuração não deve ser alterada até que haja a identificação do erro por parte do desenvolvedor. III. Verdadeira. O feedback para o usuário de todas as tarefas de manutenção é essencial, porque permite que o usuário reflita e diagnostique a solução do erro, promovendo também um feedback para o desenvolvedor. IV. Falsa. A manutenção corretiva corrige falhas e erros ocorridos após a liberação do software para o usuário. Para melhorar a manutenibilidade deve-se praticar a manutenção perfectiva. 43 REFERÊNCIAS CMMI Product Development Team. CMMI for Systems Engineering / Software engineering, Version 1.02. Staged Representation. Pittsburgh, USA: Carnegie Mellon, SEI, 2000. FIORINI, Soeli; STAA, Arndtvon; e BAPTISTA, Renam Martins. Engenharia de software com CMM. Rio de Janeiro Brasport, 1998. NBR 9126-1 ABNT. NBR ISO/IEC 9126-1 – Engenharia de software – Qualidade de produto. Rio de Janeiro: ABNT – Associação Brasileira de Normas Técnicas, 2003. NBR 9126/14598 ABNT – Associação Brasileira de Normas Técnicas. Guia para utilização das normas sobre avaliação de qualidade de produto de software – NBR ISO/IEC 9126 e NBR ISO/IEC 14598. Curitiba: ABNT, Maio de 1999. NBR 12207 ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 12207 – Tecnologia de informação – Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998. PAULA FILHO, W. de P . Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de Janeiro: LTC, 2012. PFLEEGER, Shari Lawrence. Engenharia de software. 2. ed. São Paulo: Prentice Hall, 2004. PRESSMAN, Ph.D. Roger S. Engenharia de software: Uma Abordagem Profissional. 7. ed. Rio de Janeiro: McGraw-Hill, 2011. PRESSMAN, Ph.D. Roger S. Engenharia de software. 6. ed. Rio de Janeiro: McGraw-Hill, 2007. SALVIANO, Clenio F. Introdução aos modelos de Processo de Software: ISO/IEC 15504 (SPICE), CMM e CMMI. São Paulo: Simpósio, ITI – Instituto nacional de Tecnologia da Informação, 2001. SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011. BIBLIOGRAFIA CÔRTES, Mario L. Modelos de Qualidade de Software: ISO 15504. São Paulo, IC- UNICAMP, 2017 (Artigo). FALBO, Ricardo de Almeida. Qualidade de Processo. A Série ISO 9000. LabES – Departamento de Informática – Universidade Federal do Espírito Santo, 2007 (Artigo). FOURNIER, Roger. Desenvolvimento e manutenção de sistemas estruturados. São Paulo: MAKRON Books, 1994. PINTO, Marisa. Introdução ao debugging de software. PPLWARE no comments. Disponível em: https://pplware.sapo.pt/software/introducao-ao-debugging-de-software/. Acesso em: set. 2016. 44 PAULK, Mark C.; CURTIS, Bill; CHRISSIS, Mary Beth; WEBER, Charles V. The Capability Maturity Model for Software v1.1. Pittsburgh – USA: SEI – Software Engineering Institute Customer Relations, 1993. PRESSMAN, Ph.D. Roger S. Engenharia de Software. 6a ed. Rio de Janeiro: McGraw-Hill, 2007. PRESSMAN, Ph.D. Roger S. Engenharia de Software. 5a ed. Rio de Janeiro: McGraw-Hill, 2002. MCT. Qualidade e Produtividade no Setor de Software Brasileiro N.4 (2002). Brasília: Ministério da Ciência e Tecnologia / Secretaria de Política de Informática, 2002. PMBOK, Project Management Institute. Project Management Body of Knowledge. Pennsylvania, USA: PMBOK Guide. 2000. PMBOK, Project Management Body of Knowledge. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4a ed. Atlanta, USA: Project Management Institute, Inc. 2010. SHEPHERD, George. Microsoft ASP.NET 3.5: passo a passo. – Porto Alegre: Bookman, 2009. SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 2003.
Compartilhar