Qualidade e Usabilidade de Software

QUALIDADE E USABILIDADE DE SOFTWARE Christina Paula de Camargo Curcio Tecnologia QUALIDADE E USABILIDADE DE SOFTWARE Christina Paula de Camargo Curcio Neste livro vamos apresentar os conceitos fundamentais relacionados à quali dade de software métricas normas e orientações sobre a gestão da qualida de Após este estudo esperamos que você tenha facilidade para reconhecer a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus próprios projetos identificando os requisitos necessários para o desenvolvi mento de um software com qualidade Fundação Biblioteca Nacional ISBN 9788538762966 9 788538 762966 CAPAQualidade e Usabilidade de Softwareindd 1 17082017 100901 Christina Paula de Camargo Curcio IESDE BRASIL SA Curitiba 2017 Qualidade e Usabilidade de Software CIPBRASIL CATALOGAÇÃO NA PUBLICAÇÃO SINDICATO NACIONAL DOS EDITORES DE LIVROS RJ C984q Curcio Christina Paula de Camargo Qualidade e usabilidade de software Christina Paula de Camargo Curcio 1 ed Curitiba PR IESDE Brasil 2017 184 p il Inclui bibliografia ISBN 9788538762966 1 Engenharia de software 2 Software Desenvolvimento I Título 1743661 CDD 0051 CDU 00441 Direitos desta edição reservados à Fael É proibida a reprodução total ou parcial desta obra sem autorização expressa da Fael 2017 IESDE Brasil SA É proibida a reprodução mesmo parcial por qualquer processo sem autorização por escrito da autora e do detentor dos direitos autorais Todos os direitos reservados IESDE BRASIL SA Al Dr Carlos de Carvalho 1482 CEP 80730200 Batel Curitiba PR 0800 708 88 88 wwwiesdecombr Produção FAEL Direção Acadêmica Francisco Carlos Sardo Coordenação Editorial Raquel Andrade Lorenz Revisão IESDE Projeto Gráfico Sandro Niemicz Capa Vitor Bernardo Backes Lopes Imagem Capa David M GShutterstockcom ArteFinal Evelyn Caroline dos Santos Betim Sumário Carta ao Aluno 5 1 Qualidade de software 7 2 Normas e padrões 27 3 Influência dos requisitos na qualidade do software 47 4 Processo de desenvolvimento de software 65 5 Gerência da qualidade de software 89 6 Fundamentos da interação homemcomputador IHC 107 7 Usabilidade de software 127 8 Acessibilidade e inclusão digital 145 Gabarito 165 Referências 175 Carta ao Aluno No mercado atual existe uma diversidade de softwares para uso empresarial ou informal Os sistemas podem auxiliar bastante os processos de uma empresa e otimizar o tempo de trabalho para isso necessitam ser de fácil uso com uma interface amigável ao usuário e principalmente ter qualidade O que é necessário um software ter de qualidade A usabilidade de um software deve ser cuidadosamente estudada pois compreender a interação do homem com o compu tador pode definir o sucesso ou o fracasso de uma aplicação Além dos aspectos de usabilidade se faz necessário reconhecer outros aspectos importantes que garantem a qualidade do software assim como as etapas de planejamento e produção que devem ser rigo rosamente seguidas 6 Qualidade e Usabilidade de Software Neste livro vamos apresentar os conceitos fundamentais relacionados à qualidade de software métricas normas e a gestão da qualidade de software Após este estudo esperamos que você tenha facilidade para gerir e reconhecer a qualidade e usabilidade dos softwares disponíveis no mercado e identificar os requisitos necessários para o desenvolvimento de um software com qualidade Esperamos que seu estudo não termine por aqui Com base neste mate rial realize as atividades propostas leia os textos indicados e faça você mesmo a sua pesquisa para aprofundar os conhecimentos aqui apresentados Bom estudo Qualidade de software Introdução O dia a dia das organizações demonstra como é frustrante a realidade do desenvolvimento de software produtos mais caros do que deveriam ser gastos desnecessários cronogramas estourados estresse no trabalho desenvolvedores desmotivados erros recorren tes nos projetos etc Todos na organização saem perdendo com isso sem exceção Para que os problemas enfrentados pelas organizações pro dutoras de software possam ser resolvidos fazse necessária uma conscientização de que para desenvolver softwares é preciso muita disciplina pois somente com um processo ou um modelo de quali dade é possível construir sistemas de computação adequados Desse modo o objetivo deste capítulo é apresentar uma reflexão sobre a qualidade de software conceito fundamentos e processo emba sada em pesquisa bibliográfica da área 1 Qualidade e Usabilidade de Software 8 11 A qualidade de software Qualidade é a capacidade de um produto ou serviço para atender às neces sidades do usuário BEYON 2011 No desenvolvimento de software a qua lidade do projeto acompanha os requisitos de qualidade as especificações e o design do sistema Ela está focada principalmente no aspecto de implementa ção em que é observado se a execução segue o design planejado e se o sistema resultante está cumprindo com os objetivos e requisitos de desempenho Para garantir a qualidade do software são necessários envolvimento de pessoas definição de requisitos do software integração e melhoria contínua dos processos ferramentas atualizadas e métodos de trabalho conforme observado na Figura 1 Figura 1 Qualidade do software Métodos Pessoas e definição de requisitos Ferramentas Integração e melhoria contínua Garantia da qualidade de software Fonte Elaborada pela autora De acordo com a Figura 1 para se garantir a qualidade de um soft ware é preciso pessoas analistas programadores webdesigners gestores etc que tenham não apenas conhecimento da área mas que saibam trabalhar em equipe e tenham disciplina e comprometimento com a organização Elas têm de ter em mente os objetivos e as restrições do sistema a ser desenvolvido de modo a definir suas propriedades e seus requisitos Os requisitos de um software também chamados de requerimentos de software ou de requisitos funcionais de um sistema podem ser compreendi dos como as funções ou atividades que o software ou sistema faz quando pronto ou fará quando em desenvolvimento e condições ou capacita ções que devem ser contempladas pelo software solicitadas pelo cliente ou 9 Qualidade de software usuário para resolver um problema ou alcançar um objetivo REZENDE 2005 p 123 Para se atingir a qualidade de software ela deve ser incorporada à inte gração de todas as funções e recursos de uma empresa desde a alta admi nistração Essa integração deve estar aliada à melhoria contínua e à revisão dos processos Por último o uso de ferramentas adequadas para o monitoramento da qualidade de software auxilia a corporação na mensuração da qualidade Esse monitoramento pode ser feito por meio de métodos estatísticos que são cada vez mais indispensáveis no controle da qualidade Tais métodos são recursos de verificação e validação da qualidade do software e controlam se o software foi desenvolvido de acordo com as especificações desejadas de maneira cor reta e garantem que o software atenda aos propósitos desejados 111 Fundamentos da qualidade de software Originalmente a qualidade de um programa ou sistema era avaliada de acordo com o número de defeitos a cada mil linhas de código Atualmente com a evolução do conceito outros fatores determinam a qualidade do software BENYON 2011 2 Operações de produtos as características operacionais 2 Correção grau em que um programa atende sua especificação e atinge os objetivos definidos pelo usuário 2 Confiabilidade nível de execução esperada de um software para realizar as funções com precisão 2 Eficiência número de computadores e recursos exigidos pelo pro grama para executar suas funções com o tempo de resposta adequado 2 Integridade medida em que pode ser controlado o acesso ao software ou dados por usuários não autorizados 2 Facilidade de uso esforço necessário para aprender usar e interpre tar a funcionalidade do sistema 2 Revisão do produto capacidade de resistir a mudanças de tecnologia Qualidade e Usabilidade de Software 10 2 Facilidade de manutenção necessária para localizar e corrigir um bug no sistema 2 Flexibilidade esforço necessário para modificar um programa 2 Facilidade de teste condição necessária para testar um programa de modo a assegurar que a função desejada não exija esforço 2 Transição do produto capacidade de adaptação a novos ambientes 2 Portabilidade necessária para transferir um programa de um ambiente de hardware ou software a outra tecnologia 2 Reutilização grau em que um componente de programa ou software pode ser reutilizado em outras aplicações 2 Interoperabilidade integração entre sistemas e outros aplicativos O CMM Capability Maturity Model é um modelo de qualidade de software que classifica as empresas em níveis de maturidade ou seja determina a maturidade dos processos realizados para produzir cada software De acordo o CMM as organizações podem ser classificadas em cinco níveis de maturidade No nível 1 inicial o das organizações mais imaturas não há nenhuma metodologia implementada e tudo ocorre de forma desor ganizada por sua vez no nível 5 otimizado o das organizações mais maduras cada detalhe do processo de desenvolvimento está definido quantificado e acompanhado Assim a organização consegue até absorver mudanças no processo sem prejudicar o desenvolvimento do software RESENDE 2005 p 137 Para atingir um nível maduro de produção métodos específicos devem ser implementados WEBER 2012 2 Gerenciamento de requisitos é o processo contínuo de análise e documentação dos requisitos do software Ocorre durante o pro jeto de desenvolvimento de software e envolve os usuárioschave ou stakeholders 2 Planejamento de projeto busca refinar e detalhar os objetivos do projeto e planejar o trabalho necessário para alcançálos 11 Qualidade de software 2 Monitoramento e controle de projetos consiste em medir e coletar informações sobre o desempenho do projeto assim como informar os envolvidos 2 Gestão de fornecedores é o processo de adoção de boas práticas e de controle e gestão dos fornecedores 2 Garantia de qualidade consiste no acompanhamento do projeto e na avaliação de seus diferentes aspectos para garantir que os padrões de qualidade sejam seguidos 112 Aspectos no desenvolvimento do software com qualidade A engenharia de software procura auxiliar a produção de programas e sistemas de boa qualidade com baixo custo e dentro do prazo programado Ela visa à melhoria de desenvolvimento de software ao longo do tempo considerando que as tarefas relativas ao processo podem ser aprimoradas controladas e medidas Um dos principais benefícios de um processo de desenvolvimento de software definido e disciplinado é a melhoria de sua visibilidade ou seja as atividades desse processo são gerenciáveis e por isso seus prazos e custos expressam melhor a realidade Aqui a engenharia de software será discutida de duas formas a conven cional que detalha os aspectos principais desse ramo e outra mais específica que detalha o uso da orientação por objeto A engenharia de software procura atender uma necessidade humana da mesma forma que outras ramificações da engenharia tratam de assuntos relacionados à mineração agricultura moradia e tantos outros que justifi cam a utilização de algum conhecimento científico específico Ela traz bene fícios por meio dos recursos tecnológicos disponíveis para o tratamento de informações Uma parte dos métodos da engenharia de software vem da ciência da computação e a outra da experiência adquirida pelo usuário A engenharia de software é composta por um conjunto de disciplinas específicas relacionadas à ciência da computação e utiliza as abstrações dessa área como algoritmos e estruturas de dados para criar sistemas de computador que atendam às Qualidade e Usabilidade de Software 12 necessidades do usuário usando para isso um processo definido e discipli nado por meio da tecnologia existente Existem três conceitos muito importantes na engenharia de software que se relacionam intrinsecamente 2 Processo tratase de um conjunto de passos ordenados usado para atingir um fim específico sendo composto por atividades méto dos práticas e transformações 2 Projeto é o que concretiza um processo 2 Produto é o objetivo do processo Esses conceitos podem ser relacionados da seguinte maneira um pro jeto tem um escopo delimitado por datas de início e de fim com pontos de controle chamados de marcos de projeto para que possa ser acompanhado e gerido O escopo do projeto é um processo constituído de documentação que detalha o que é feito quando e por quem tendo por meta a concretização do produto especificado De modo geral um produto tem um ciclo de vida em que é concebido desenvolvido entra em operação e sai de operação Um produto de software é criado a partir do momento em que se percebe a necessidade de sua existên cia e assim um conjunto de requisitos é determinado e desenvolvido para que seja posto em operação Quando o produto não é mais necessário ou se torna obsoleto seu ciclo de vida termina e ele é retirado de operação A literatura disponível varia muito ao definir as disciplinas da engenha ria de software a qual se configura como uma área interdisciplinar que se baseia nos fundamentos de várias disciplinas RESENDE 2005 Elas podem ser distribuídas entre os aspectos de requisitos planejamento de projetos e qualidade conforme se discutirá a seguir 1121 Engenharia dos requisitos Os requisitos descrevem ou expressam as características de um dado produto de software podendo ser funcionais ou não funcionais Requisitos funcionais são aqueles que determinam o comportamento do produto de 13 Qualidade de software software de acordo com uma situação específica enquanto os requisitos não funcionais quantificam aspectos desse produto como por exemplo desem penho disponibilidade ou portabilidade Os requisitos precisam ser especificados em um documento devendose detalhar e distinguir os explícitos e os normativos Os requisitos explícitos são aqueles levantados por desenvolvedores com base nas informações dos usuários e os requisitos normativos são os provenientes de leis e normas aplicados ao produto de software PRESSMAN MAXIM 2016 Existem ainda os requisitos de expectativa do usuário os quais não estão documentados Eles são chamados de requisitos implícitos e são totalmente indesejados porém podem ser minimizados por meio de uma boa especifi cação de requisitos ou seja detalhandose bem os explícitos e normativos Para obter uma boa especificação de requisitos fazse necessário o uso de técnicas de levantamento documentação e análise constituise assim a engenharia dos requisitos uma disciplina da engenharia de software Uma boa engenharia de requisitos aumenta a compreensão do produto para o seu públicoalvo e também diminui a instabilidade dos requisitos ou seja a alteração dos requisitos constantes no documento de especificação A instabilidade onera o projeto de várias formas como por exemplo no aumento de prazos e custos Porém essa alteração de requisitos também pode acontecer devido a mudanças em requisitos normativos sendo inevitável a variação do contexto do produto O controle dos requisitos precisa ser então submetido a algum tipo de gestão pois eles podem ser alterados mesmo à revelia do usuário Isso constitui a gestão de requisitos outra disciplina da engenharia de software 1122 Engenharia de gestão de requisitos Além de especificar corretamente os requisitos gerentes de projetos devem estar atentos a outros dois fatores os prazos e os custos pois estes juntamente com os requisitos determinam o sucesso ou o fracasso do projeto de software Um produto de software deve atender aos requisitos e às necessidades dos usuá rios e também deve ser construído dentro do prazo e do custo estimados Qualidade e Usabilidade de Software 14 O aumento ou a alteração de requisitos acarreta aumentos de prazos e ou de custos No caso da redução de requisitos os prazos e os custos tam bém podem sofrer alteração mas isso não é regra O bom planejamento de projetos tenta equilibrar os componentes dos vértices desse triângulo crítico requisitos prazos e custos com base em uma boa especificação de requisitos e com técnicas de estimativa e análise de tamanho esforços prazos e riscos O planejamento de projetos é a disciplina da engenharia de software que trata desses aspectos O planejamento de projetos tem uma disciplina complementar cha mada de controle de projetos cujo objetivo é acompanhar o progresso dos pro jetos comparando o previsto com o realizado Busca solucionar os problemas detectados replanejar os projetos quando houver necessidade e renegociar os compromissos assumidos Também diz respeito à gestão de requisitos a gestão de contratos As organizações que terceirizam a produção de software devem estar capacitadas nessa gestão porque precisam especificar corretamente todos os requisitos do produto selecionar os candidatos mais qualificados ter proficiência no acompanhamento do projeto para intervir quando necessário e verificar os critérios para a aceitação do produto BENYON 2011 1123 Engenharia de gestão de configurações Para gerir com qualidade todos os artefatos produzidos no processo de desenvolvimento a engenharia de software tem a disciplina de gestão de con figurações gerência de configuração ou ainda gestão de configuração de software uma área responsável por fornecer o apoio para o desenvolvimento de software Suas principais atribuições são o controle de versão o controle de mudança e a auditoria das configurações Um grupo de pessoas deve ser designado para controlar esses artefatos de software porque todos são passíveis de alterações Em caso de organizações pequenas que não disponham de pessoal suficiente um membro da equipe de desenvolvedores pode ser designado para essa função Essa é uma disci plina em que é fortemente recomendado o uso de ferramentas automatizadas devido ao grande volume de artefatos e de versões destes que são geradas durante todo o processo de desenvolvimento WEBER 2012 15 Qualidade de software 12 Processos em qualidade de software Para falar sobre qualidade em software é preciso introduzir uma dis cussão sobre os erros aos quais um processo de desenvolvimento de software está sujeito As disciplinas da engenharia de software que regem a garantia da qualidade dizem respeito ao impacto causado por esses erros 121 Erros que devem ser evitados A qualidade de um produto é definida pelo grau de conformidade com os seus requisitos e está diretamente relacionada à qualidade do processo uti lizado em sua construção Podese afirmar então que a qualidade é uma relação construída com base em processos pessoas e tecnologia envolvidos na construção de um produto Esses três elementos formam o segundo triân gulo crítico da engenharia de software e indicam os fatores da produção BENYON 2011 Os defeitos ocorrem em um produto de software em todas as suas fases de desenvolvimento Eles são encontrados de diversas formas como no desempenho aquém do desejado nas funções que não são executadas correta mente ou na dificuldade para utilização do sofware Assim os defeitos estão relacionados à não conformidade com os requisitos explícitos os normativos e os implícitos Os erros relativos ao produto estão vinculados a algum desses fatores e são defeitos de definição de requisitos ou defeitos introduzidos ao longo do projeto Os mais comuns são a introdução de características desnecessárias aos requisitos alteração dos requisitos sem uma análise de impacto e erro no foco do desenvolvimento quando ele é voltado para a pesquisa e não para a produção em si Os erros relativos ao processo estão relacionados com processos informais ou processos oficiais rígidos e burocráticos Os mais comuns são WEBER 2012 2 desperdício de tempo antes do início do projeto 2 pressões por prazos otimistas e o não cumprimento destes por serem impossíveis Qualidade e Usabilidade de Software 16 2 falha no planejamento de projetos em que se omitem as estimativas de atividades como as de garantia da qualidade e a omissão da análise de riscos 2 falha no método de gerir o projeto 2 pressa para começar a etapa de codificação 2 falha na subcontratação de serviços e 2 entrega do produto sem estar totalmente pronto ou testado Entre os requisitos e a codificação existe o projeto presente em todas as fases do processo Os defeitos de projeto são tão graves como os defeitos pro venientes de requisitos Eles se caracterizam por dificuldade para utilização do software desempenho ruim defeitos aleatórios de difícil reprodução e dados inconsistentes que comprometem a manutenibilidade e a extensão Um bom projeto deve ser também documentado Como todas as fases do desenvolvimento do projeto são passíveis de injetar erros no produto é preciso haver atividades como testes revisões for mais e informais e auditorias que visem garantir a qualidade do software detectando precocemente cada erro Estudos já demonstraram que o aumento da qualidade reduz o tempo de desenvolvimento devido ao refinamento na detecção e eliminação precoce de defeitos o que é bem mais barato que corri gir o defeito em um estágio avançado do processo BENYON 2011 Os métodos de garantia de qualidade devem levar em consideração o fator humano é mais fácil detectar erros dos outros do que os próprios Assim revisões testes e auditorias devem ser realizados por pessoas diferentes daquelas que desenvolveram o produto Por fim a garantia da qualidade deve ser gerida por um grupo de pessoas independente dos desenvolvedores e que não mantenha nível hierárquico com estes ou com o gerente do projeto e tenha acesso à alta gerência da organização Já os erros relativos a pessoas podem ocorrer por falta de patrocínio para o projeto ausência de participação dos interessados no produto como os usuários e desenvolvedores atritos entre as partes envolvidas defeitos na formação da equipe do projeto como a falha na contratação de pessoas falta de entrosamento entre funcionários e dependência em relação a determinadas 17 Qualidade de software pessoas ambiente inadequado ao trabalho com muito barulho pouco espaço e fatores ergonômicos inapropriados e falta de motivação do pessoal BENYON 2011 Os erros relativos à tecnologia podem ocorrer por uma estimativa oti mista de que muitos problemas podem ser resolvidos por meio de alta tecno logia esquecendose de que para utilizála em profundidade é necessário trei namento e experiência Assim pode haver falha na análise para mudança de tecnologia e a substituição desta no meio de um projeto falta de automação de atividades como as de gestão de configurações ausência de ferramenta de modelagem e automação de atividades de testes 122 Modelos de ciclo de vida Para a existência de um processo de desenvolvimento de software é pre ciso ter definido o seu modelo de ciclo de vida Existem vários tipos de mode los que se diferenciam principalmente pelo grau de controle aplicado sobre o processo em questão e sua visibilidade para o cliente no seu decorrer como especificado a seguir 2 CodificaRemenda é o pior de todos os modelos de ciclo de vida aqui apresentados e provavelmente o mais utilizado Com base em um problema existente e não um problema modelado ou especifi cado mas sim definido de uma forma qualquer passase imediata mente à codificação Os erros encontrados são corrigidos conforme a demanda daí o termo remenda Muitas vezes não existe um pro cesso definido ou se existe ele não é seguido é impossível de ser gerido e portanto não se pode assumir compromissos confiáveis 2 Cascata esse modelo de ciclo de vida tem a vantagem de apresen tar pontos de controle que permitem demarcar as fases do processo facilitando a sua gestão Porém ele é rígido e burocrático porque não permite a correção de erros nas fases anteriores e tem baixa visibilidade para o cliente pois este não recebe feedback nos pontos de controle existentes assim o único resultado que o cliente vê é o final Ele apresenta uma variante que permite a realimentação entre fases porém esta dificulta a gestão de projetos Qualidade e Usabilidade de Software 18 2 Espiral modelo de ciclo de vida em que um produto é desen volvido em diversas iterações repetições Uma iteração nova representa uma volta na espiral Sua vantagem é que permite a construção de produtos com prazos curtos e a desvantagem é que é difícil de ser gerido 2 Prototipagem evolutiva utiliza o modelo de ciclo de vida em espi ral para construir o produto em protótipos cobrindo progressiva mente os requisitos até a finalização Sua vantagem é que apresenta visibilidade e alta flexibilidade para o cliente Como desvantagem ele precisa de equipes disciplinadas e experientes o projeto deve ser robusto para que a estrutura do produto permaneça confiável ao longo dos protótipos além disso ele é também difícil de ser gerido 2 Entrega evolutiva esse modelo de ciclo de vida é uma combinação dos modelos cascata e prototipagem evolutiva Apresenta a vantagem de ter alta visibilidade para os clientes e facilidade de gestão por apresentar pontos de controle bem definidos Sua desvantagem é a necessidade de um projeto que seja robusto para que a estrutura do produto permaneça confiável ao longo das liberações programadas 2 Dirigido por prazo um conjunto de requisitos essenciais é defi nido e entregue no prazo programado nesse modelo de ciclo de vida O produto final é na verdade um produto parcial e o res tante é desenvolvido em processos posteriores geralmente cha mados de manutenção 2 Dirigido por ferramenta utilizase um processo proposto por uma ferramenta CASE1 e podem ser adequados a um determinado tipo de produto porém fica restrito ao domínio da aplicação Mesmo que uma organização decida por não desenvolver mas adquirir um produto de software ela tem de ter competência para gerir os processos de aquisição implantação adaptação e integração com outros sistemas e a orga nização Isso pode sair mais caro do que o processo de desenvolvimento em si 1 Ferramentas CASE do inglês ComputerAided Software Engineering é uma classificação que abrange todos os programas as ferramentas que auxiliam os analistas nas atividades de en genharia de software desde análise de requisitos e modelagem até a programação e os testes 19 Qualidade de software 123 Processos de desenvolvimento de software Para que a organização possa ser considerada madura ela precisa ter pro cessos de desenvolvimento formalmente definidos e que possam ser melhora dos continuamente como os processos apresentados a seguir Processo pessoal de software PSP utiliza o modelo de ciclo de vida em entrega evolutiva e não há tratamento específico para requisitos Na fase de planejamento do PSP executamse as atividades de estimativas de tamanho com base em modelo de orientação a objetos esforços crono gramas e defeitos O projeto é rigoroso tanto para concepção quanto para verificação e é realizado utilizandose orientação a objetos síntese lógica e máquinas sequenciais Processo de software para times TSP utilizando um modelo de ciclo de vida em espiral esse processo é uma sequência do PSP O TSP cobre a área de gestão de requisitos planejamento e controle de projetos garantia da qualidade e gestão de configurações não cobertas pelo PSP Processo unificado esse processo é dirigido a casos de uso centrado na arquitetura sendo iterativo e incremental e usa a UML Unified Modeling Language como notação para os modelos que o compõe Ele utiliza um modelo de ciclo de vida em espiral e é dividido em fases e fluxos de trabalho Cada fase representa um marco gerencial do projeto e cada fluxo de trabalho trata de um tema técnico específico O RUP Rational Unified Process e o EUP Enterprise Unified Process são baseados no processo unificado Práxis é um processo com fins didáticos e baseado em tecnologia de orientação a objetos e sua notação de análise e projeto também é UML Apresenta elementos do processo unificado mas com influência do PSP e do TSP Da mesma forma que o processo unificado o práxis abrange fases e fluxos uma fase é dividida em uma ou mais iterações e um fluxo é dividido em uma ou mais atividades Um dos objetivos de um processo de desenvolvimento de software é capacitar uma organização a identificar rapidamente e solucionar facilmente os problemas Ora para isso ela necessita de maturidade Uma organização imatura é ruim aos profissionais desenvolvedores e gerentes clientes e usuá rios Para os profissionais é ruim porque o ambiente de trabalho é pouco Qualidade e Usabilidade de Software 20 adequado estressante o grau de motivação é baixo e os processos são difíceis de gerir Já para os clientes e usuários é ruim porque a qualidade do produto final não é boa ou porque foram entregues fora do prazo e do custo estimado Todos esses problemas podem ser minimizados e até mesmo resolvidos pela definição formal de um processo de desenvolvimento de software O processo precisa ser definido de forma a auxiliar a organização a pro duzir produtos melhores com baixo custo e dentro do prazo estimado e uma consequência inerente ao refinamento do processo é que os produtos são produzidos mais rapidamente Por outro lado se a organização erra defi nindo um processo rígido e burocrático ele servirá apenas para formalizar uma situação e não será efetivamente usado na prática Um software é baseado em abstrações lógicas e não em princípios físicos estáveis Como consequência a disciplina para gerir um processo desse tipo deve ser mais rígida que de costume Assim um processo de desenvolvimento de software ruim não vai conduzir a um produto de qualidade satisfatória É um erro imaginar que a qualidade de um software não pode ser medida ela pode e deve ser medida por meio da produtividade ou do número de defeitos encontrados por exemplo As métricas devem ser coletadas anali sadas e normatizadas para que o processo possa ser gerido e melhorado Outro erro muito comum em organizações é acreditar que os problemas da produção são mais técnicos que gerenciais Com um processo de negócio ruim pouco adianta a tecnologia e esta não tem retorno sem processos de negócio mapeados e robustos um projeto de desenvolvimento de software inicia de forma incorreta já que aqueles são a base deste O mesmo se aplica quando a gestão é deficiente Mais uma vez os indicadores dos problemas da produção recaem nos problemas gerados por um processo mal definido As pessoas erram porque a informação chega até elas de forma incorreta incompleta ou confusa os recursos disponíveis não são adequados ou não são suficientes o processo é mal definido ou difícil de seguir e falta treinamento da área de negócio nos processos e tecnologias utilizados BENYON 2011 Infelizmente a tendência é acreditar que os erros são do corpo técnico por falta de comprometimento e treinamento e não devido a processos 21 Qualidade de software inadequados ou uma gerência de projetos despreparada Os gerentes podem não conhecer totalmente o domínio da aplicação e precisam ser treinados em gestão de pessoal Também precisam estar comprometidos com o projeto para se abstrair de paixões pessoais e evitar competições internas que sem pre existem dentro das organizações procurando levar ao conhecimento dos desenvolvedores as informações corretas completas e precisas A conclusão extraída é óbvia fatores de produção pessoas tecnologia e processos são muito dependentes uns dos outros Não basta ter tecnolo gia se não há um corpo técnico com capacidade de operála e isso requer treinamento e experiência Não basta ter tecnologia e um corpo técnico altamente capacitado se os gerentes acreditam que isso resolverá todos os problemas e eles terão o produto desejado dentro do prazo e custo estima dos Para tudo isso é preciso um processo definido Para a realização da melhoria de processos fazse necessária uma análise em que os problemas relativos a eles são de responsabilidade dos gerentes de projetos Ora isso porque os gerentes possuem um universo de variá veis envolvidas estando capacitados a procurar e encontrar as deficiências do processo para interferir quando for preciso A atuação de um gerente de projeto deve ser de forma a estimular melhorias sem procurar efetivamente os culpados porque isso leva ao ocultamento dos problemas reais De outra forma o processo fatalmente não funcionará É tarefa do gerente promover aperfeiçoamentos reduzindo o desgaste no ambiente de trabalho a fim de aumentar a produção Mas para isso é preciso que ele conheça o processo para poder agir eficazmente ter o apoio da alta administração que deve estar ciente do investimento a ser feito envolver o corpo técnico e por último mas não menos importante ele tem de ter em mente que a capacitação no processo não é conseguida da noite para o dia ela é realizada em etapas com marcos para pontos de controle bem definidos Assim os processos de qualidade de software englobam fases que bus cam aumentar a eficiência e a eficácia dos softwares produzidos conforme pode ser observado na Figura 2 O processo de melhoria contínua envolve os procedimentos de planejamento controle e garantia da qualidade em que as Qualidade e Usabilidade de Software 22 revisões devem ser contínuas ao longo de todo o projeto de desenvolvimento do software Figura 2 Processos de qualidade do software Qualidade do software Gestão da qualidade do software conjunto de caracterísiticas de um sistema para atender os requisitos das partes interessadas direção e coordenação das atividade de qualidade de software Melhoria da qualidade do software processo de melhoria contínua 2 Estabelecer os objetivos pro cessos e recursos Revisão dos processos de qualidade 2 Cumprir os obje tivos e requisitos de qualidade 2 Garantir que os re quisitos de qualidade sejam cumpridos Planejamento da qualidade Controle da qualidade Garantia da qualidade Fonte Elaborada pela autora A Figura 2 resume o que foi visto até aqui o processo de melhoria da qualidade do software deve ser contínuo e revisado em todos as etapas Num primeiro momento é feito o planejamento em que se estabelecem os obje tivos processos e recursos Durante o desenvolvimento o controle de quali dade deve estar sempre presente buscandose cumprir os objetivos e atender aos requisitos de qualidade A garantia de qualidade é uma etapa final em que é feita uma última avaliação do produto no entanto para que ela seja eficaz também precisa estar presente em todas as etapas anteriores num ciclo de melhoria contínua 23 Qualidade de software 13 Reflexões sobre a qualidade dos softwares Para que o software tenha qualidade ele deve ter usabilidade funciona lidade confiabilidade manutenibilidade e desempenho Para que essas carac terísticas de qualidade de software sejam atendidas é importante que sejam respondidas questões como O software satisfaz a necessidade do usuário ou da empresa Ele é confiável Tem um bom desempenho É fácil de usar Pode ser corrigido com facilidade Pode ser reutilizado em outro projeto O software deve satisfazer a necessidade do cliente em relação à fun cionalidade Para isso deve se propor a fazer o que é apropriado de forma correta ser capaz de interagir com os sistemas especificados estar de acordo com as normas de qualidade de sofware e da organização e deve ser protegido para evitar acessos não autorizados Com relação à confiabilidade o sistema deve ser imune a falhas e ser capaz de recuperar dados em caso de falhas Além disso deve ser fácil de usar com navegação intuitiva para atender o critério de usabilidade ou seja o sistema deve ter um nível fácil de operação para o usuário e ser de fácil com preensão pois se for muito complicado exigirá vários treinamentos o que dificultará seu emprego Por último o software deve ser de fácil modificação adaptação e valida ção A eficiência do software é outro item de qualidade a ser verificada pois deve ser enxuto com bom tempo de resposta e de processamento na execução de suas funções utilizando recursos e tempo aceitáveis pelo usuário No contexto da engenharia de software o processo de gestão de quali dade é aquele que estabelece o comportamento essencial de um sistema o qual pode ser mantido independentemente de como o sistema é implementado Um modelo de análise deve ser confeccionado visando às abstrações que indicam o que o sistema vai fazer Assim pressupõese que uma tecnologia perfeita esteja disponível e o analista considere que não haverá restrições de capacidade de memória a comunicação entre os objetos será realizada na velocidade ideal a adequação do sistema à plataforma de computador não será um empecilho não acontecerão erros e outras questões relacionadas às abstrações de como fazer o sistema BENYON 2011 Qualidade e Usabilidade de Software 24 O modelo AOO análise orientada a objetos serve para formalizar a visão do mundo real no contexto do sistema de computador estabelecendo os principais objetos que representam o domínio de uma aplicação e as estrutu ras organizacionais impostas a tais objetos bem como a colaboração existente entre eles ou seja as conexões de mensagens que mostram a forma de comu nicação dos objetos com os demais WEBER 2012 Os benefícios trazidos pela melhoria dos processos são muitos Os prin cipais deles são BENYON 2011 2 Engenharia de requisitos e gestão de requisitos são práticas que produzem um retorno de investimento mais significativo porque é mais barato captar o requisito certo do que alterálo em fases posteriores do processo 2 Projeto menos significativo que o anterior mas que não deixa de produzir impacto no retorno de investimento 2 Garantia da qualidade as atividades de garantia da qualidade as que mais sofrem devido à pressa para entrega de um produto dão retorno quando as necessidades de se refazer as etapas iniciais de um processo tendem a diminuir 2 Prevenção de defeitos aqui vale o ditado popular é melhor preve nir que remediar Entre as atividades de garantia da qualidade as de prevenção de defeitos dão mais retorno do que as de correção Ampliando seus conhecimentos O texto a seguir trata sobre a importância do trabalho do analista de requisitos no desenvolvimento de um software e as princi pais dificuldades enfrentadas por esse profissional cujo traba lho muitas vezes é desvalorizado ou incompreendido pelos outros colaboradores e até mesmo gestores da organização FAGUNDES 2011 p 45 25 Qualidade de software Quando se trabalha algum tempo com requisitos de software percebese o quão ingrata é a atividade Não por ser mais ou menos complexa que as outras mas pela forma como é tratada pelos pares O Analista de Requisitos é tomado na maioria das vezes como um documentador até mesmo pelos próprios trabalhadores de requisitos corrompendo o bemfazer da atividade e provocando prejuízo aos projetos e degradando ainda mais a forma como se percebe a engenharia de requisitos A percepção geral que se tem é que os analistas de requi sitos entram em ação para atrasar os projetos e que a docu mentação gerada é extensiva e de pouca valia Às vezes parte dessa percepção é correta mas a razão imputada é na maioria das vezes distorcida apontando para uma origem incorreta Muito mais vezes os problemas de requisitos se dão pela falta de preparação dos analistas seu perfil e por uma fraca postura na relação com o cliente em vez da len dária mão invisível do processo Como resultado desses fatores reais para uma construção ade quada de requisitos constróise uma escala de retrabalho que a equipe não entende exatamente por quê Por várias vezes durante um projeto há questionamentos sobre a forma dos requisitos serem especificados ou se a proposta é adequada ou não desviando o foco da atividade em voga no anda mento do projeto Para então corrigir o prumo e trabalhar requisitos é premente que se faça uma revisão de propósitos motivações formação discurso e perfis para que as pessoas corretas estejam aloca das corretamente para realizar a atividade de maneira eficaz e eficiente A adoção de novos processos e técnicas não surtirão efeito sem essa revisão Qualidade e Usabilidade de Software 26 Atividades 1 Para se avaliar a qualidade do software é fundamental medir e moni torar todo o ciclo de seu desenvolvimento Por quê 2 O que são requisitos de software e como devem ser documentados 3 Com relação aos processos de qualidade de software quais são os principais erros encontrados 4 Por que o modelo ciclo de vida codificaremenda é o mais utilizado e o menos recomendado Normas e padrões Introdução No Brasil existe um corpo de normas nacionais baseadas em normas internacionais que buscam garantir a proteção do con sumidor por meio de produtos e serviços adequados A adoção de padrões internacionais leva a melhores oportunidades de comércio global e reduz a produção de itens de baixa qualidade Para os sistemas de gestão a normalização também ajuda as organizações e as partes interessadas em suas atividades em dife rentes níveis com seus próprios fins Esse é um prérequisito para a evolução de uma cultura de qualidade A seguir são apresentadas e discutidas diferentes padroniza ções suas aplicações e sua importância para ordenações em diversos contextos incluindo o da qualidade de software 2 28 Qualidade e Usabilidade de Software 21 Normas e seus organismos normativos A normalização é o processo de desenvolvimento implementação e melhoria dos padrões que se aplicam a ordens científica industrial e eco nômica diferentes para organizar suas atividades A Associação Americana de Teste de Materiais define padronização como o processo de formulação e implementação de regras numa abordagem ordenada para atividades especí ficas visando a benefícios e com a cooperação de todos os envolvidos CYBIS et al 2015 As grandes somas de dinheiro que os países desenvolvidos inves tem em organizações nacionais e internacionais de normalização são uma prova da importância dada à padronização VALERIANO 2005 A ISO International Organization for Standardization desenvolve nor mas internacionais para diversos campos da tecnologia exceto o eletrotécnico coberto pela IEC International Electrotechnical Comission e as telecomu nicações abrangidas pela UIT União Internacional de Telecomunicações De acordo com a ISO padronização é a atividade que visa estabelecer os problemas reais ou potenciais provisões para uso comum e repetido a fim de obter um nível ótimo de ordenação em um dado contexto que pode ser tecnológico político ou econômico WEBER 2012 A normalização envolve um conjunto de regras convencionais destina das a simplificar unificar e especificar produtos WAZLAWICK 2013 2 Simplificar procura manter apenas o estritamente necessário seja em documentos processos orientações etc As próprias normas também são simplificadas para serem facilmente assimiladas 2 Unificar a ideia é criar um padrão para os produtos utilizado em todas as partes do mundo para permitir trocas internacionais 2 Especificar procura por meio de uma linguagem clara e pre cisa identificar os produtos definindoos categorizandoos catalogandoos e detalhando suas características de modo a orientar o consumidor 29 Normas e padrões Em relação às normas técnicas é importante conhecer os Organismos Nacionais de Normalização NSB do inglês National Standards Body dos paí ses de interesse que em geral possuem um centro de informação sobre nor mas Os NSB têm um arquivo próprio de padronizações de organismos nacio nais regionais e internacionais tais como as do British Standards Institution BSI ou Instituto Britânico de Normalização e da Association Française de Normalisation AFNOR Associação Francesa de Normalização No Brasil o organismo responsável pela elaboração de normas técnicas é a Associação Brasileira de Normas Técnicas ABNT O papel dos NSB tem evoluído nas últimas décadas com melhorias na infraestrutura física e econômica avanços na tecnologia da informação implantação de melhores práticas de fabricação automação transporte e mudanças em muitos aspectos que afetam o comércio e a indústria levando a um aumento acelerado no volume de transações comerciais entre os países SOMMERVILLE 2011 Com a globalização a média das áreas das organizações consideradas sob padronização foi estendida para incluir sistemas de gestão indústrias de serviços e novas tecnologias que não existiam até a segunda metade do século XX PRESSMAN MAXIM 2016 Os padrões são utilizados cada vez mais para apoiar os regulamentos técnicos e mais direcionados para tecnologias convergentes e de rápido desenvolvimento direcionados a uma ampla gama de partes interessadas PFLEEGER 2004 Novos produtos reguladores com períodos mais curtos de desenvolvimento são uma tentativa por parte da comunidade normativa para responder às exigências de governos empresas e consumidores em todo o mundo LAUDON LAUDON 2004 Assim as atividades de padronização tornaramse mais complexas e mais importantes para o desenvolvimento nacional e internacional A criação da Organização Mundial do Comércio OMC em 1995 levou ao desen volvimento de vários acordos na área em especial o Acordo sobre Barreiras 30 Qualidade e Usabilidade de Software Técnicas ao Comércio e o Acordo sobre a Aplicação de Medidas Sanitárias e Fitossanitárias ao qual todos os membros da OMC devem aderir CAIÇARA JR 2007 Esses acordos são uma tentativa de reduzir o impacto das normas e regulamentações usadas como barreiras técnicas ao comércio entre os países CYBIS et al 2015 22 Normas ISO e modelos CCMI 221 ISO As normas ISO são amplamente respeitadas e aceitas internacio nalmente pelos setores público e privado CAIÇARA JR 2007 A International Organization for Standardization ou ISO é uma organização não governamental uma federação de organismos nacionais de normaliza ção de todas as regiões do mundo incluindo países desenvolvidos e países em desenvolvimento MARSHALL JR et al 2012 Cada membro da ISO possui uma agência principal de normalização em seu próprio país Os paísesmembros propõem as novas normas envolvemse em seu desenvolvimento e prestam apoio divididos em grupos técnicos em conjunto com a Secretaria Geral da ISO localizada em Genebra na Suíça PRESSMAN MAXIM 2016 O termo ISO tem raiz grega significando igual igualdade o qual dá nome à organização que também coincide com sua sigla Esse é um signifi cado muito adequado a essa entidade uma federação internacional indepen dente com o propósito de proporcionar sistemas uniformes de segurança qualidade e eficiência do trabalho para trocas simples entre países e regiões de bens e serviços produzidos PRESSMAN MAXIM 2016 O ano de 1945 foi fundamental para a história da entidade pois os delegados do Comitê Coordenador de Padronização das Nações Unidas UNSCC se reuniram em Nova Iorque para tentar criar uma organização de padrões fundando as bases para a ISO PRESSMAN MAXIM 2016 Ela foi estabelecida em 1946 com a participação de 64 delegados de 25 31 Normas e padrões países em Londres Inglaterra na sede do Instituto de Engenheiros Civis Essas pessoas decidiram aventurarse no projeto de uma organização cujo objetivo seria facilitar a industrialização e as regras de unificação e melhoria da coordenação internacional das empresas CAIÇARA JR 2007 Em 27 de fevereiro de 1947 a ISO foi finalmente oficializada e inicia ramse suas operações Naquele ano mais de 19500 normas foram criadas para todos os setores de produção incluindo o setor da saúde a indústria de alimentos a de tecnologia etc PRESSMAN MAXIM 2016 Em 1987 surge a norma ISO 9000 com a finalidade básica de faci litar ainda mais o comércio global Para chegar a um consenso sobre essa legislação foi necessário o apoio de 75 dos países que a compõem Essa política baseiase em dois pilares melhoria e desempenho enraizada em princípios incluindo mercados regulação melhorias responsabilidade desenvolvimento do intelecto etc A partir de 1994 foi implementada a versão ISO 9001 quando ela se tornou mais interessante para as empresas CAIÇARA JR 2007 A norma passou por um enorme crescimento desde então A norma de 1994 era especificamente dirigida a empresas com processos de produção e portanto na revisão de 2000 ABNT 2000 ela foi simplificada e tornouse aplicável a todos os tipos de empresas públicas ou privadas A versão atual do padrão é datada de 2015 a ISO 90012015 ABNT 2015 um aperfeiçoamento de sua edição anterior de 2008 ISO 90012008 ABNT 2008 A fim de validar a implementação dessa norma fazse necessária uma auditoria de certificação e aplicação das regras de quali dade e se a conformidade for constatada é emitido um certificado à empresa MARSHALL JR et al 2012 Em relação à engenharia de software a NBR ISOIEC 91261 é a atual padronização mundial de qualidade de produtos propondo métricas e atributos para os produtos de software ABNT 2003 Sob o título geral Engenharia de Software qualidade do produto essa norma abrange em suas três partes o modelo de qualidade a ser adotado as métricas internas e a as métricas externas características e subcaracterísticas do produto de software 32 Qualidade e Usabilidade de Software 222 CMMI O Capability Maturity Model Integration CMMI foi criado pelo SEI Software Engineering Institute um órgão de pesquisa da universidade norte americana Carnegie Mellon e consiste em um modelo de garantia de quali dade com enfoque voltado para a capacidade de maturidade de processos de software nas empresas Em 1984 o SEI começou a pesquisa para desenvolver um quadro de melhoria e avaliação da qualidade das empresas de desenvolvimento de software que fornecem serviços para o Departamento de Defesa dos Estados Unidos O resultado da investigação foi chamado de Capability Maturity Model Software SWCMM um modelo de maturidade de capacidades desenvolvido para processos relacionados com a produção e manutenção de sistemas de software que teve sua versão 10 publicada em agosto de 1991 MARSHALL JR et al 2012 Posteriormente como resultado do feedback gerado pela comunidade de software novas versões alteraram e acrescentaram uma série de elementos na CMM principalmente em relação a sua institucionalização nas organizações Assim o SWCMM pode ser usado para dois fins CAIÇARA JR 2007 2 Melhorar os processos relacionados com a produção e manutenção de software 2 Definir critérios para a determinação do nível de maturidade de uma organização que produz e mantém software Com o passar do tempo e a evolução do modelo CMM estabelecese o CMMI que teve como um de seus propósitos unir vários modelos usa dos em conjunto dentro de organizações em prol de melhorias de processo CAIÇARA JR 2007 como modelos de desenvolvimento de software SWCMM sistemas de engenharia SECM e desenvolvimento de produ tos integrados IPDCMM O CMMI serve como um guia que auxilia as empresas a gerenciar mensurar e monitorar produtos e serviços e contém as práticas ligadas à gestão de projetos e de processos à engenharia e ao suporte Assim o modelo CMMI busca a melhoria contínua dos processos organizacionais por meio da análise e redesign fornecendo de acordo com Caiçara Júnior 2007 33 Normas e padrões 2 Uma maneira de integrar os elementos funcionais de uma organização 2 Um conjunto de melhores práticas com base em histórias de sucesso comprovadas por organizações com experiência em práti cas de melhoria de processos 2 Uma ajuda para identificação de metas e prioridades para a melho ria dos processos dependendo dos pontos fortes e fracos da organi zação obtidos por um método de avaliação 2 Um suporte às empresas em atividades produtivas complexas para coordenar as suas atividades 2 Uma referência para avaliar os processos atuais da organização O CMMI for Services fornece orientação para a prestação de serviços aos clientes internos e externos da organização Em 2000 foi desenvolvido e publicado o método Requisitos de avaliação para o CMMI que define os elementos considerados essenciais para avaliar o CMMI em uma empresa e o Padrão de avaliação CMMI para melhoria de processos Esses dois docu mentos também foram atualizados como resultado do feedback da comuni dade envolvida em CMMI gerando a versão mais recente 12 do SCAMPI1 e ARC2 ambos publicados em 2006 CAIÇARA JR 2007 2221 Níveis de maturidade e capacidade O CMMI está dividido em cinco níveis de maturidade que atestam o grau de evolução de uma organização em determinado momento e tem como objetivo principal guiar a melhoria de processos das empresas Com ele é possível gerenciar o desenvolvimento e a produção de software com base em prazos e custos estabelecidos e com mais qualidade Esses níveis estão demonstrados na Figura 3 1 Métodos de avaliação SCAMPI Standard CMMI Appraisal Method for Process Improvement são os métodos geralmente aceitos para avaliar organizações perante os modelos CMMI ISD BRASIL 2017 2 O documento de avaliação por áreas de resultadochave ARC Appraisal Requirements for CMMI descreve requisitos para diferentes tipos de avaliação buscando uma uniformidade entre os métodos CARNEGIE MELLON UNIVERSITY 2006 34 Qualidade e Usabilidade de Software Figura 3 Níveis de maturidade do CMMI 1 Inicial Processo im previsível e sem controle 2 Repetível Processo disci plinado 3 Definido Processo consistente e padronizado 4 Gerenciado Processo previ sível e contro lado 5 Otimizado Processo con tinuamente melhorado Fonte Elaborada pela autora com base em CMMI INSTITUTE 2017 Esses níveis de maturidade de processos de uma organização são defini dos a seguir PRESSMAN MAXIM 2016 Nível 1 Inicial No nível 1 de maturidade a maioria dos processos são adhoc e caóticos e a organização geralmente não fornece um ambiente estável para apoiálos Sucessos nesse caso ocorrem devido aos esforços para superar a concorrência e de pessoas competentes dentro da organização e não do uso de proces sos comprovados Apesar desse caos as organizações pertencentes ao nível 1 frequentemente produzem os produtos e serviços que disponibilizam no entanto frequentemente excedem seus orçamentos e não cumprem os seus planos Essas empresas têm como características a tendência a não honrar os seus compromissos a abandonar processos em tempos de crise e a incapaci dade de repetir seus sucessos Ainda nesse nível os trabalhos são executados de modo redundante por pessoas que não compartilham seus métodos de trabalho com toda a organização Nível 2 Repetível Gerenciado No nível 2 o caos passa a ser ordenado e as organizações se concentram em tarefas diárias relacionadas com a administração Cada projeto tem uma série de processos planejados e executados em conformidade com as políticas 35 Normas e padrões estabelecidas São utilizadas pessoas qualificadas que têm os recursos para produzir saídas controladas A disciplina de processo refletida pelo nível 2 de maturidade ajuda a garantir práticas e projetos de acordo com planos documentados e tanto a produção como a prestação de serviços são definidos Os contratos são esta belecidos entre as partes interessadas e também revistos quando necessário Artefatos e serviços são devidamente controlados satisfazendo suas descrições específicas padrões e procedimentos Nível 3 Definido No nível 3 de maturidade os processos são descritos em normas proce dimentos ferramentas e métodos O conjunto de processos padrão da orga nização é estabelecido e continuamente melhorado de modo consistente para toda a empresa Os projetos são estabelecidos por meio da adaptação desse conjunto de procedimentos e normas de acordo com diretrizes específicas Uma diferença importante entre os níveis 2 e 3 de maturidade é o escopo das normas a descrição de processos e procedimentos No nível 2 as nor mas podem ser um pouco diferentes em cada instância específica do processo por exemplo em um projeto particular No nível 3 padrões descrições de processos e procedimentos em um projeto são adaptados com base em um conjunto de processos padrão da organização para determinado projeto ou unidade organizacional e portanto são mais consistentes Outra distinção importante é que no nível de maturidade 3 os proces sos são geralmente descritos de forma mais rigorosa do que no nível 2 Um processo definido apresenta claramente sua finalidade insumos critérios de entrada atividades papéis medidas etapas de verificação saídas e critérios de saída No nível 3 os procedimentos são geridos de forma mais proativa compreendendo as interrelações de atividades e medidas detalhadas do pro cesso seus artefatos e serviços Nível 4 Gerenciado quantitativamente No nível 4 a organização e os projetos estabelecem metas quantitativas para medir a qualidade e o desempenho dos processos as quais são utilizadas 36 Qualidade e Usabilidade de Software como critérios na gestão Os objetivos quantitativos são definidos com base nas necessidades de clientes usuários finais organização processos e atores A qualidade e o desempenho das atividades são compreendidos em termos estatísticos e tratados em todo o processo de ciclo de vida Para subprocessos selecionados são recolhidas e analisadas estatisticamente medidas sobre pro cessos de execução as quais são incorporadas nas métricas de repositório da organização para apoiar a tomada de decisão As variações dos processos quando ocorrem devem ser identificadas e corrigidas na causa raiz para prevenir futuras ocorrências de mudanças de processos Uma diferença importante entre os níveis 3 e 4 é a previsibilidade do desempenho do processo No nível 4 de maturidade esse desempenho é con trolado usandose técnicas estatísticas e quantitativas e o processo é quantita tivamente previsível por outro lado no nível 3 o desempenho do processo é previsível apenas qualitativamente Nível 5 Otimizado No nível 5 de maturidade uma organização melhora continuamente seus processos com base no conhecimento das causas comuns de variação inerente a processos Tratase de melhorias contínuas incrementais e tecnoló gicas Os objetivos de melhoria de processos quantitativos para a organização são estabelecidos e continuamente revisados sendo utilizados como critério de qualidade em processos Uma diferença importante entre os níveis 4 e 5 é o foco da variação do processo No nível 4 de maturidade a organização direcionase para encontrar as causas especiais de variação e fornecer uma previsão estatística dos resultados No entanto os resultados podem ser insuficientes para alcançar as metas esta belecidas No nível 5 a organização está focada nas causas comuns de variação de processo e modifica os procedimentos afetados para melhorar o desempenho deles e atingir os objetivos quantitativos de melhoria de processos 37 Normas e padrões O quadro a seguir explica resumidamente o que acontece em cada um desses níveis Quadro 1 Características dos níveis de maturidade das organizações Nível Características Inicial 2 Basicamente nenhuma prática forma de gerenciamento de enge nharia de software está implantada na organização 2 Tudo é feito à medida em que vão surgindo as necessidades 2 O padrão usual é o não cumprimento de prazos e orçamentos estabelecidos 2 A maioria das atividades são respostas a crises e não a tarefas préplanejadas 2 O processo de software é imprevisível e depende totalmente da equipe atual 2 É impossível prever com precisão o tempo necessário para desenvolver um produto ou o seu custo Repetível 2 Já estão implantadas práticas básicas de gerenciamento de projetos de software 2 As técnicas de planejamento e gerenciamento se baseiam em expe riências com produtos similares daí o termo repetível 2 Há o acompanhamento meticuloso dos cronogramas de prazo e da planilha de custos 2 Os gerentes identificam problemas à medida que eles vão surgindo e tomam ações corretivas imediatas para evitar que eles se transformem em crises 2 Medidas tomadas durante um projeto podem ser usadas para elaborar cronogramas e orçamentos realistas para projetos futuros Definido 2 O processo para a produção de software é completamente documentado 2 Tanto aspectos técnicos quanto gerenciais do processo são claramente definidos 2 São feitos esforços contínuos para melhorar o processo onde for possível 2 São usadas revisões para atingir as metas de qualidade de software 2 Há a introdução de novas tecnologias como as ferramentas CASE para aumentar a produtividade 38 Qualidade e Usabilidade de Software Nível Características Gerenciado 2 A organização estabelece metas de qualidade e produtividade para cada projeto 2 A qualidade e a produtividade são medidas continuamente 2 Ações corretivas são tomadas quando ocorrem desvios inaceitáveis das metas 2 Controles estatísticos de qualidade são implantados para a gerência ser capaz de distinguir o desvio esporádico de um problema significativo nos padrões de qualidade ou produtividade Otimizado 2 Há aperfeiçoamento contínuo do processo 2 São usadas técnicas de controle estatístico de processos e qualidade para orientar a organização 2 O conhecimento adquirido em cada projeto é utilizado em projetos futuros 2 O processo incorpora uma curva de realimentação positiva resultando em uma melhoria contínua na produtividade e na qualidade Fonte Elaborado pela autora com base em SCHACH 2010 p 9394 Dependendo do modelo de representação usada em CMMI existem duas maneiras de realizar a melhoria de processos Uma delas é utilizando a representação contínua e a outra é melhorando toda a organização de acordo com os processos definidos A representação contínua se concentra em melhorar um procedimento de modo que a organização possa ser certificada para uma área de processo em um determinado nível de capacidade Existem seis níveis de capacidade ao longo dos quais os processos são associados em uma área Quadro 2 e cada um deles é construído sobre o nível anterior ou seja um processo para chegar a determinado nível de capacidade deve necessariamente ter atingido um nível anterior CAIÇARA JR 2007 39 Normas e padrões Quadro 2 Níveis de representação contínua e escalonada Representação contínua Representação escalonada Nível de capacidade Nível de maturidade Nível 0 Incompleto Nível 1 Realizado Inicial Nível 2 Manejado Manejado repetível Nível 3 Definido Definido Nível 4 Manejado quantitativamente Manejado quantitativamente gerenciado Nível 5 Otimizado Otimizado Fonte CYBIS et al 2015 Adaptado Nos processos de representação contínua os níveis de capacidade são delimitados da seguinte forma 2 Nível 0 Incompleto um processo é chamado de incompleto quando um ou mais objetivos da área de processo não estão em conformidade 2 Nível 1 Realizado é chamado de feito ou realizado o processo que satisfaz todas as metas específicas da área de processo 2 Nível 2 Manejado produzido é designado processo de gestão quando o projeto apresenta a infraestrutura para suportálo O pro cesso é planejado e executado de acordo com a política da empresa envolvendo as partes interessadas e emprega pessoas qualificadas 40 Qualidade e Usabilidade de Software que tenham recursos adequados para produzir saídas controladas É monitorado controlado revisto e avaliado de acordo com sua descrição específica 2 Nível 3 Definido é uma adaptação do conjunto de normas da organização de acordo com as diretrizes da empresa e fornece dispositivos medidas e outras informações para melhorar os ativos da organização 2 Nível 4 Manejado gerenciado quantitativamente é contro lado usandose técnicas quantitativas estatísticas e outras Metas quantitativas para a qualidade e o desempenho do processo são estabelecidas e utilizadas como critérios para sua gestão 2 Nível 5 Otimizado otimização é a melhoria contínua do pro cesso com base no entendimento de causas comuns de variação de processo Esse processo é realizado por meio de aperfeiçoamentos incrementais e usandose a inovação tecnológica Na representação escalonada um método de melhoria de processo estruturado e sistemático também envolve uma graduação em estágios ou níveis Para atingir determinado nível a organização precisa ter uma infraes trutura robusta em termos de processos para se qualificar para o próximo nível Por isso a empresa pode ser classificada pelo seu nível de maturidade de 1 a 5 os quais são compostos por áreas de processo em que os objeti vos devem ser cumpridos a fim de que a organização possa ser certificada Quadro 3 PRESSMAN MAXIM 2016 Quadro 3 Modelo de classificação de áreas de processos organizacionais em níveis de maturidade Área de processo Categoria Nível de maturidade Análise e resolução das causas Suporte 5 Análise e resolução das decisões Suporte 3 41 Normas e padrões Área de processo Categoria Nível de maturidade Assegurando a qualidade dos processos e produtos Suporte 2 Definição de produtos organizacionais IPPD OPD IPPD Gestão de processos 3 Desenvolvimento de requerimentos Engenharia 3 Treinamento organizacional Gestão de processos 3 Administração quantitativa de projetos Gestão de projetos 3 Administração de acordo com provedores Engenharia 2 Administração de requerimentos Gestão de projetos 3 Administração de riscos Suporte 2 Administração de configuração Gestão de projetos 3 Administração integral do projeto Gestão de projetos 3 Inovação e desenvolvimento organizacional Gestão de processos 5 Integração de produto Engenharia 3 Medição e análise Suporte 2 Monitoração e controle do projeto Gestão de projetos 2 Planejamento do projeto Gestão de projetos 2 Processos orientados às organizações Gestão de processos 3 Rendimento de processos organizacionais Gestão de processos 4 Solução técnica Engenharia 3 Validação Engenharia 3 Verificação Engenharia 3 Fonte CYBIS et al 2015 Adaptado 42 Qualidade e Usabilidade de Software 23 Métricas de qualidade de software As métricas de qualidade fornecem uma indicação de que o software está em conformidade com as exigências implícitas e explícitas dos clientes O principal objetivo da engenharia de software é produzir com uma alta qua lidade A fim de atingir esse objetivo os engenheiros de software devem usar medições técnicas de modo objetivo para avaliar a qualidade dos modelos de análise o códigofonte e casos de teste que foram criados por meio da aplica ção de engenharia de software MARSHALL JR et al 2012 O primeiro objetivo da equipe de projeto é o de medir os erros e defeitos As métricas que vêm do resultado dessas medidas fornecem uma indicação da eficácia das atividades de controle e garantia de qualidade PRESSMAN MAXIM 2016 De acordo com Marshall Junior et al 2012 as métricas de qualidade de software englobam o resumo dos fatores que afetam a qualidade a medida de qualidade e a eliminação dos defeitos 231 Resumo dos fatores que afetam a qualidade Marshall Jr et al 2012 define um conjunto de fatores de qualidade que avaliam o software sob três pontos de vista diferentes 2 operação do produto usálo 2 revisão do produto alterandoo 2 transição do produto modificandoo para trabalhar em um ambiente diferente Assim se fornece um mecanismo para o operador do produto ou seja a pessoa responsável pelo desenvolvimento do software identificar se ele atende os requisitos de qualidade préestabelecidos 43 Normas e padrões 232 Medida de qualidade Exatidão facilidade de manutenção integridade e facilidade de utiliza ção são medidas de qualidade que fornecem indicadores úteis para a equipe do projeto MARSHALL JR et al 2012 e devem ser avaliadas pela equipe de produção e pelos gestores 2 Exatidão é o grau em que o software executa a sua função 2 Manutenção é a facilidade com que um programa pode ser corrigido se um erro de sistema seja de código ou de requisitos for encontrado 2 Integridade mede a capacidade de um sistema para resistir a ata ques acidentais e intencionais à sua segurança Os ataques podem ser executados em qualquer um dos três componentes de software programa dados e documentos3 Para medir a integridade é preciso definir dois atributos adicionais ameaça e segurança Ameaça é a probabilidade de que um ataque dê certo em determinado momento Já a segurança é a probabili dade que o sistema tem de repelir um ataque de certo tipo 2 Facilidade de uso é uma tentativa de quantificar o quão amigável pode ser o programa para o usuário 233 Eliminação dos defeitos É o entendimento dos principais defeitos presentes nos projetos de software como erros na gestão prazos curtos erros de código com o obje tivo de avaliálos e eliminálos de modo a garantir o controle de qualidade em todas as atividades do processo MARSHALL JR et al 2012 3 A documentação de software consiste em manuais gerais e técnicos ou mesmo relatórios que explicam o funcionamento do programa ou sistema e acompanham o produto explicando ao cliente como utilizálo e suas características 44 Qualidade e Usabilidade de Software As métricas de qualidade portanto são fundamentais nos processos de desenvolvimento de softwares pois auxiliam no monitoramento e no con trole da qualidade por meio de testes que ajudam a prever erros e a corrigir defeitos que por ventura possam surgir Ampliando seus conhecimentos O texto a seguir trata sobre a importância de as empresas de desenvolvimento de software terem certificações na área de tecnologia pois estas não apenas garantem qualidade de processos e produtos como também atraem clientes Gestão da qualidade SILVA AZEVÊDO 2015 p 100101 A gestão da qualidade de software tem como objetivo nor matizar e rever periodicamente os conceitos e métodos uti lizados por uma empresa garantindo melhoria e correções nos processos de desenvolvimento com base em estudos e estatísticas minuciosas A área acompanha todos os processos de construção dos softwares modelagem de negócio e lici tação de requisitos análise e designer do projeto implemen tação testes implantação gerenciamento de configuração e mudança gerenciamento de projeto e ambiente A área da qualidade trabalha de acordo com as normas da ISO 9001 ISO 9002 e ISO 9003 Apesar de muitos acha rem que o procedimento de certificação de uma empresa de tecnologia é muito diferente das empresas industriais os pro fissionais vêm mostrando que não As fábricas de softwares são os grandes exemplos disso pois as mesmas têm se preo cupado com a focalização nos clientes abordagem dos pro cessos envolvimento dos stakeholders comprometimento da 45 Normas e padrões liderança relação com os fornecedores e a melhoria contínua dos processos Muitos clientes que prezam por mais confiabilidade nos con tratados buscam empresas que sejam certificadas na área Hoje são diversas as certificações onde cada uma atende necessi dades específicas do negócio As mais conhecidas da área de tecnologia são CMMI e MPSBR Para se certificar a empresa precisa atender algumas exigências e demonstrar maturidade nos processos de produ ção Essas certificações além de darem um peso maior ao cur rículo da empresa atraem clientes que buscam por parceiros com maior qualidade nos processos A área da qualidade se responsabiliza pela garantia do cumpri mento dos processos e pela melhoria dos mesmos melho ria contínua O produto é visto como consequência da exe cução desses processos Apesar dos esforços serem voltados para o processo o principal objetivo é garantir um produto final que satisfaça o cliente Atividades 1 Explique em que as normas para os sistemas de informações auxiliam os processos e como é seu uso 2 O que é SWCMM e como ele pode ser usado 3 Como é possível avaliar os fatores que afetam a qualidade de software 4 Quais são os cinco níveis de maturidade de uma organização Influência dos requisitos na qualidade do software Introdução O processo de análise e verificação das necessidades de um clienteusuário1 para o desenvolvimento de um sistema é chamado de engenharia de requisitos O objetivo da engenharia de requisitos é entregar um software correto e completo de acordo com especifica ções predeterminadas Os requisitos são a peça fundamental para um projeto de desenvolvimento de software com qualidade que exige planeja mento e recursos Os líderes do projeto utilizam os requisitos de base para estimar os recursos necessários à criação de um software 1 Em alguns casos cliente e usuário são a mesma pessoa mas também podem ser pessoas diferentes Cliente é a pessoa ou grupo que requisita o software a ser desen volvido e fornece os requisitos básicos do produto além de coordenar os recursos financeiros para o projeto Já usuário é uma pessoa ou grupo que vai realmente usar o software construído PRESSMAN MAXIM 2016 p 111 3 Qualidade e Usabilidade de Software 48 Assim os requisitos são a base para a decisão sobre como um produto será executado ou seja a base do ciclo de vida de um projeto Disso decorre a sua importância na definição e gestão de processos 31 Processos de negócio As empresas se diferenciam entre si pela sua capacidade de organização e de processos de negócio Cada empresa utiliza um procedimento especí fico para chegar ao resultado desejado relacionandoo ao produtofim da empresa Para um desenvolvimento de software por exemplo é fundamental o levantamento dos processos do negócio da empresa para que no futuro sejam desenvolvidas tecnologias que auxiliem em sua gestão Um processo de negócio consiste em um conjunto de tarefas ou ativida des que são executadas de acordo com certas regras relacionadas a determina dos objetivos Tratase de uma série de tarefas individuais e cada uma delas é executada em uma ordem específica Para entender a importância do processo de negócio para a construção de um software é importante primeiro avaliar com o cliente a sua necessi dade saber exatamente o que ele deseja no produto solicitado para se ter uma ideia aproximada das funções que o software deverá apresentar WEBER 2006 Com essa informação os analistas preparam um estudo detalhado sobre a viabilidade do sistema desejado e avaliam a possibilidade de desenvol vêlo VALERIANO 2005 Esse estudo de viabilidade centrase no objetivo do projeto pois analisa os requisitos do software para a sua implementação a contribuição do projeto para a organização e os limites de custo sempre de acordo com os valores da empresa VALERIANO 2005 Se esse estudo de viabilidade for positivo a próxima fase começa com a coleta detalhada dos requisitos por meio de uma entrevista com o cliente usuário Analistas e engenheiros comunicamse com os clientesusuários para conhecer as ideias destes sobre os resultados que o software deve fornecer e quais as características que devem ser incluídas VALERIANO 2005 49 Influência dos requisitos na qualidade do software 311 Requisitos de software Como visto no Capítulo 1 os requisitos incluem necessidades quantificadas e documentadas desejos e expectativas do patrocinador dos stakeholders2 e dos clientes VASQUEZ SIMÕES 2016 em relação ao software encomendado De acordo com a definição do glossário do IEEE3 os requisitos do software são VASQUEZ SIMÕES 2016 p 18 1 Uma condição ou capacidade do sistema solicitada por um usuário para resolver um problema ou atingir um objetivo 2 Uma condição ou capacidade que deve ser atendida por uma solução para satisfazer um contrato especificação padrão ou quaisquer outros documentos formais impostos 3 Documentação da representação das condições ou capacidades apresentadas nos dois itens anteriores 4 Uma condição ou capacidade que deve ser alcançada ou pos suída por um sistema produto serviço resultado ou compo nente para satisfazer um contrato padrão especificação ou outro documento formalmente imposto Os requisitos devem apresentar uma série de características tanto indivi dualmente como em grupos Estas são as características mais importantes dos requisitos de software VALERIANO 2005 2 Necessário Um requisito deve ser necessário A sua omissão causa uma deficiência no sistema afetando a sua capacidade suas caracte rísticas físicas Quando o clienteusuário aponta a necessidade de um requisito é preciso verificar quão necessário ele realmente é ao software Se for um elemento apenas estético por exemplo não se trata de um requisito 2 Conciso Um requisito é conciso se é fácil de ler e compreender A sua redação deve ser simples e clara para aqueles que vão consul tálo sejam os clientes ou outros desenvolvedores no futuro Um 2 Stakeholders são as partes interessadas no negócio todas as pessoas ou grupos que atuam direta ou indiretamente na gestão eou nos resultados da organização 3 Instituto de Engenheiros Eletricistas e Eletrônicos organização fundada nos EUA sem fins lucrativos dedicada ao avanço da tecnologia no mundo Qualidade e Usabilidade de Software 50 documento muito extenso acaba dificultando o processo pois sua leitura e interpretação demandam mais tempo 2 Completo Um requisito é completo quando não necessita de mais detalhes na sua formulação ou seja a informação disponibi lizada é suficiente para sua compreensão e para o desenvolvimento do software 2 Consistente Os dados apresentados devem ser confiáveis e segu ros possíveis de serem realizados e integrados de forma consistente ou seja um requisito não pode contradizer outro nem se propor a fazer a mesma coisa 2 Inequívoco Os requisitos devem ser claros e não permitir mais de uma interpretação não podem ser ambíguos pois isso poderia acarretar diversos erros no sistema 2 Verificável Um requisito é verificável quando ele é palpável pode ser construído testado rastreado e homologado não é apenas uma ideia que só pode existir no papel Os requisitos de software são a descrição das características e funciona lidade do objetivo target do sistema de modo a comunicar expectativas dos consumidores de produtos de software Podem ser óbvios ou ocultos conhe cidos ou desconhecidos esperados ou inesperados VALERIANO 2005 Isso significa que nem sempre o clienteusuário tem claros os requisitos daí a necessidade de o gestor do projeto juntamente com os analistas orientar o clienteusuário de modo a conseguir informações mais completas sobre o produto que vão desenvolver Para expressar os requisitos do software as sentenças devem ser claras exprimindo objetivamente a ação a ser realizada O exemplo a seguir apresentado por Vazquez e Simões 2016 demons tra o caso de especificação de requisitos para um software voltado ao controle de entradas e saídas de visitantes em um edifíciocondomínio 51 Influência dos requisitos na qualidade do software No primeiro caso o requisito não foi especificado adequadamente visto que não há uma caracterização da ação principal a ser realizada incluindo cláusulas adicionais em um único texto Identificador RF001 Requisito Controle de Portaria Para realizar o controle de entrada e saída na portaria deve ser realizado o cadas tro do visitante através dos seguintes atributos Nome Registro Geral e Imagem Caso a visita tenha sido liberada pelo condomínio então podem ser registradas a data e a hora em que o visitante acessou a portaria Ao sair do condomínio devem ser registradas a data e a hora em que o visitante saiu mas só deve ser permitido para visitante com registro de entrada e sem registro de saída Fonte VAZQUEZ SIMÕES 2016 p 203 Já no segundo caso o mesmo texto foi reformulado e dividido em dife rentes sentenças que especificam o passo a passo das ações a serem cumpridas Identificador RF001 Requisito Manter Cadastro de Visitante O condômino cadastra o visitante registrando Nome e Registro Geral Identificador RF002 Requisito Liberar Acesso de Visitante O condômino cadastra a liberação de acesso selecionando um visitante já cadastrado e indica o período data e hora e início e data e hora de fim para realizar a visita Identificador RF003 Requisito Registrar Entrada de Visitante O porteiro ou guarda verifica se a documentação apresentada pelo visitante confere com dados apresentados na liberação de aceso Nome do Visitante e Registro Geral e registra a data e a hora em que o visitante entrou no condomínio Fonte VAZQUEZ SIMÕES 2016 p 204 Verificase assim que esse detalhamento dos requisitos realizado no segundo caso garante que os procedimentos sejam seguidos corretamente Qualidade e Usabilidade de Software 52 Desse modo a engenharia de requisitos é responsável por documentar os requisitos de acordo com as exigências do clienteusuário como apresen tado a seguir 312 Engenharia de requisitos O processo de análise e levantamento das necessidades dos clientes é conhecido como parte integrante da engenharia de requisitos O objetivo dessa área da engenharia de software é desenvolver e manter um sistema documentado de especificação de requisitos que contemple todas as informa ções necessárias de forma concisa clara e descritiva VALERIANO 2005 A engenharia de requisitos facilita a interação com o clienteusuário em termos de identificar e entender o que ele necessita e na obtenção de um acordo acerca da solução que será entregue Assim ela descreve e integra tarefas técni cas orientações papéis e responsabilidades em fluxos de trabalho que têm iní cio com o entendimento da necessidade do cliente e passa pelo acordo sobre a solução que será construída conforme apresentado na Figura 1 Figura 1 O contexto da engenharia de requisitos Requisitos Gerência de Projetos Análise e projeto Implementação Implantação Medição e análise Testes cliente necessidades do cliente plano de projeto e acompanhamento escopo orçamento e prazo projeto da solução projeto do banco de dados material de treinamento e de suporte ao usuário estimativas e medições casos de teste equipe Facilita a interação com o cliente acordos sobre a entrega Fonte VASQUEZ SIMÕES 2016 p 12 53 Influência dos requisitos na qualidade do software Desse modo a engenharia de requisitos contempla uma das partes do estudo da engenharia de software sendo necessária às etapas de gerência de projetos análise de projeto implementação implantação medição e análise e testes Como se pode observar na Figura 1 a engenharia de requisitos medeia todo o processo entre o clienteusuário e a equipe de desenvolvimento fazendo a interação entre eles O desenvolvimento dos requisitos geralmente passa pelas seguintes fases MARSHALL JR et al 2012 2 Análise de problemas identificar stakeholders obter concordância em relação ao problema que eles possuem identificar fronteiras e restrições ao sistema e elaborar o documento de visão 2 Avaliação e negociação processo de avaliação e negociação de melhorias com o cliente ou stakeholder 2 Especificação processo que tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados 2 Validação processo que tem como objetivo a validação da con sistência e do contexto dos requisitos levantados no processo de identificação 2 Evolução processo em que se compreende a situação inicial do problema os requisitos iniciais o entendimento do problema modificado e os requisitos que são alterados ao longo do tempo do projeto 2 Princípios de especificação processo de representação dos requi sitos do cliente especificando a funcionalidade da implemen tação identificando o comportamento desejado do sistema e o modo pelo qual outros componentes do sistema interagem com o software Essas fases não seguem com rigor essa ordem e uma mesma fase pode se repetir algumas vezes durante o projeto mas todas estão presentes quando se trata de desenvolvimento de requisitos de software Qualidade e Usabilidade de Software 54 32 Os requisitos e a comunicação Os requisitos são o ponto de concordância entre o cliente e o projeto de desenvolvimento de software Esse entendimento é necessário para construir um software que atenda às necessidades do clienteusuário Se os requisitos são descritos de forma a focar nas necessidades do clienteusuário então é preciso que o gestor do projeto primeiro obtenha essa informação por meio de entrevistas ou recolhendo documentação que descreva o software desejado pelo clienteusuário PRESSMAN MAXIM 2016 As necessidades dos clientes evoluem com o tempo e toda mudança envolve um custo Por isso é necessário ter uma cópia da documentação do sistema original e de cada revisão ou alterações feitas nesse documento Como todas as necessidades são tratadas de forma diferente é necessário classificá las para saber qual delas vai ser satisfeita pelo software ou algum outro pro duto do sistema PFLEEGER 2004 A especificação de requisitos de software é a atividade em que o docu mento é gerado com um nome específico contendo uma descrição com pleta das necessidades e capacidades do sistema que será desenvolvido Esse documento descreve o escopo4 do sistema e como será suas funções como por exemplo definir os requisitos funcionais e não funcionais PRESSMAN MAXIM 2016 321 Especificação de requisitos Segundo Vasquez e Simões 2016 p 18 a especificação de requisitos é um contrato entre clientes e equipe de desenvolvimento Ela deve esclare cer aos clientes o que será entregue como produto do trabalho da equipe de desenvolvimento Com base na especificação os clientesusuários devem ser capazes de entender o projeto e apontar falhas nele para que sejam corrigidas imediatamente antes que o produto comece a ser produzido com defeitos Desse modo os riscos de erros na execução são menores e a garantia de satis fação do clienteusuário é maior Portanto são objetivos da especificação de requisitos VASQUEZ SIMÕES 2016 4 Escopo é a descrição de tudo o que é preciso ser feito para se alcançar os objetivos do projeto incluindo recursos e funções desejados 55 Influência dos requisitos na qualidade do software 2 documentar de forma correta e fidedigna todas as necessidades do clienteusuário 2 obter aprovação aceite sobre tudo o que está sendo proposto para se entregar em termos de produto 2 ajudar a equipe de desenvolvimento a compreender exatamente o que os clientesusuários desejam 2 servir de base para o trabalho de manutenção futura no sistema A especificação de requisitos portanto é um importante instrumento de comunicação entre os clientesusuários e a equipe de desenvolvimento Contudo ela deve ser orientada ao cliente e não à equipe embora seja útil também para esta A especificação nem sempre é um único documento mas a composição de vários documentos Segundo Vasquez e Simões 2016 uma especificação de requisitos geralmente apresenta 2 Visão geral em que se apresenta os objetivos do projeto as partes interessadas e o escopo preliminar com as funções descritas brevemente 2 Glossário definição dos termos técnicos e de siglas usados no documento 2 Modelos de sistema em que se mostra o relacionamento entre os componentes do sistema 2 Lista de requisitos funcionais em que se descreve as tarefas exe cutadas pelo sistema e as interfaces externas do software Os requisitos funcionais definem as funcionalidades e o compor tamento do sistema mediante cada entrada ou seja é aquilo que descreve o que o sistema tem que fazer a cada ação de um usuário ou outro sistema por exemplo o sistema deve cadastrar médicos profissionais entrada ou emitir um relatório de clientes saída 2 Lista de requisitos não funcionais em que se descreve as restrições impostas sobre o software relacionandoas aos requisitos funcionais Qualidade e Usabilidade de Software 56 Os requisitos não funcionais dizem respeito às características e padrões de qualidade que o sistema deve oferecer como por exemplo desempenho confiabilidade segurança robustez portabilidade usabilidade entre outros MARINHO 2015 Desse modo seriam exemplos de requisitos não funcionais casos em que o sistema avisa o usuário quando ele tenta fazer uma operação ilegal confiabilidade ou quando se propõe a imprimir um relatório em até cinco segundos desempenho 2 Especificação detalhada de requisitos detalhamento dos requi sitos funcionais Todos os requisitos de hardware e software diagramas modelos e quais quer outros sistemas de informação contemplados na especificação servem como um suporte e guia para as fases subsequentes desse processo como o desenvolvimento propriamente dito do produto e os testes finais É impor tante reforçar que a especificação de requisitos é o resultado final das ativida des de análise e avaliação de requisitos desse modo o documento resultante será usado como fonte básica de comunicação entre clientes usuários finais analistas de sistemas testadores e todos os envolvidos na implementação do sistema PFLEEGER 2004 Assim os clientes e usuários usam as especificações de requisitos para comparar se o que está sendo proposto está de acordo com as necessidades da empresa Analistas e programadores usam os requisitos para determinar o produto a ser desenvolvido e a equipe de desenvolvimento prepara testes fun cionais com base nesse documento Para o gerente de projeto os requisitos ser vem como referência e controle da evolução do sistema PFLEEGER 2004 322 Dificuldades na definição de requisitos Segundo Pressman e Maxim 2016 entre as dificuldades na definição de requisitos estão suas exigências não são óbvias e podem vir de várias fon tes os requisitos são difíceis de expressar em palavras a linguagem é ambí gua não são muitos os tipos de requisitos e há diferentes níveis de detalhe o número de requisitos em um projeto pode ser difícil de manusear e eles nunca são iguais alguns são mais difíceis mais arriscados mais importantes ou mais estáveis do que outros 57 Influência dos requisitos na qualidade do software Existem ainda dificuldades para quantificálos uma vez que cada conjunto de requisitos é específico para cada projeto e cada requisito tem propriedades únicas que incluem áreas funcionais específicas Muitas vezes eles estão relacionados uns aos outros e assim referemse a outras partes do processo Além disso tudo um requisito pode mudar ao longo do ciclo de desenvolvimento sendo necessário rever o projeto como um todo devido à integração de requisitos Também há os requisitos que estão na expectativa do usuário porém não estão documentados Esses requisitos são chamados de requisitos implí citos e como visto no Capítulo 1 são totalmente indesejados porém podem ser minimizados por meio de uma boa especificação ou seja detalhandose bem os requisitos explícitos e normativos VALERIANO 2005 O segredo para que todas as falhas do processo sejam minimizadas está na elaboração da especificação de requisitos Se essa fase for bem realizada e documentada se o clienteusuário tiver claros os requisitos funcionais e os não funcionais e fizer uma boa análise das falhas existentes na especificação as chances de o software ser desenvolvido sem surpresas desagradáveis são bem maiores Para tanto é preciso que a comunicação entre as partes interessadas flua sem ruídos que a entrevista seja direta e planejada que os gestores estudem com os analistas as solicitações feitas pelo clienteusuário e prevejam todos os empecilhos e dificuldades que possam vir a surgir durante o desenvol vimento do software O texto da especificação precisa ter o nível de deta lhamento adequado sem exageros mas também não tão conciso a ponto de gerar ambiguidades e ser escrito tendo em vista o clienteusuário e não um expert de tecnologia Portanto o documento precisa ser escrito em uma linguagem adequada sem jargões técnicos que dificultam a compreensão de um leitor leigo No caso de termos técnicos necessários precisam vir sempre acompanhados de um glossário Esse documento precisa ser compreendido sem interferência externa de modo que o cliente possa lêlo e interpretálo sem auxílio e se sinta à vontade para interferir nele a ajustálo de acordo com as suas necessidades O uso de uma linguagem inadequada muito técnica pode frustrar e assustar o cliente impedindoo de interagir com o projeto de forma adequada Qualidade e Usabilidade de Software 58 A relação com o clienteusuário precisa ser construída com respeito e confiança entre as partes É preciso ter muito tato com o cliente para não criar barreiras na comunicação Para tanto é preciso que o gestor de projetos seja um bom ouvinte e esteja em sintonia com o cliente para compreender suas necessidades em relação ao projeto 33 Qualidade de requisitos de software Os requisitos de software são a base a partir da qual a qualidade é medida A falta de conformidade5 com os requisitos significa falta de qualidade A ISO 90012008 especifica requisitos para um sistema de gestão da qualidade quando uma organização CYBIS et al 2015 a precisa demonstrar sua capacidade de fornecer de forma consis tente produtos6 que atendam aos requisitos do cliente e requisitos regulamentares aplicáveis e b pretende aumentar a satisfação do cliente por meio da aplicação eficaz do sistema incluindo processos para sua melhoria contínua e a garantia de conformidade com os requisitos do cliente Nesse contexto os requisitos são o primeiro passo para se atingir a qualidade e serão avaliados durante os testes nos quais é possível verificar se estão sendo atendidos ou não A Figura 2 aponta um grande equívoco em relação ao esforço para se obter qualidade no processo de desenvolvimento de um software Figura 2 Ciclo de desenvolvimento no qual a qualidade se resume a testes de software Modelo de negócios Requisitos Análise e modelagem Implemen tação Testes de software Disponibili zação Esforço para obter qualidade Tempo Fonte BARTIÉ 2002 p 25 5 Segundo as ABNT NBR ISOIEC 170002005 conformidade é a demonstração de que os requisitos especificados relativos a um produto processo sistema pessoa ou organismo são atendidos INMETRO 2017 6 Nessa norma o termo produto aplicase apenas para o produto destinado a um cliente ou por ele solicitado ou nesse caso em específico o software PFLEEGER 2004 59 Influência dos requisitos na qualidade do software Embora a qualidade possa ser avaliada durante a fase de testes é um equívoco concentrar os esforços para obtenção da qualidade apenas nessa fase do projeto tendo em vista que a qualidade deve percorrer todas as etapas de desenvolvimento Se isso não for feito desde o início os erros tendem a migrar de uma etapa para a outra onerando todo o processo Portanto a qualidade não é uma fase do ciclo de desenvolvimento de software é parte de todas as fases BARTIÉ 2002 p 25 como representado na Figura 3 Figura 3 Garantia da qualidade de software em todo o ciclo de desenvolvimento Modelo de negócios Requisitos Análise e modelagem Implemen tação Testes de software Disponibili zação Tempo Processo de garantia da qualidade de software Fonte BARTIÉ 2002 p 27 Qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente declarados a padrões de desenvolvimento clara mente planejados e comunicados à especificação e documentação dos requi sitos e às características implícitas que são esperadas de todo software desen volvido por profissionais PRESSMAN 2016 Assim os padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia Se tais critérios não forem definidos o resultado muito provavelmente será a falta de qualidade do software Desse modo como observado a tarefa de análise de requisitos é um pro cesso de descoberta e refinamento assim durante o sistema de engenharia os softwares são melhorados em cada detalhe A análise e especificação de requisitos podem parecer uma tarefa relativa mente simples mas requerem muito detalhamento e trabalho Uma vez que o conteúdo da comunicação é muito diversificado há muitas alterações devido a equívocos ou falta de informação Qualidade e Usabilidade de Software 60 Os requisitos de um sistema de software quando vistos como um todo são extensos e contêm múltiplas relações Para se obter a capacidade de especificar esses sistemas complexos com os detalhamentos simples e concisos de documen tos o novo sistema deve ser capaz de realizar a sua classificação e organização Na busca da qualidade o engenheiro deve refinar o mapeamento do software e a partir desse ponto desenvolver a estrutura dos dados a arquite tura e o design processual Finalmente a especificação de requisitos fornece apoio à equipe de desenvolvimento e ao clienteusuário assim como dispõe os meios para avaliar a qualidade dos sistemas uma vez já construídos 331 Requisitos de qualidade A especificação independentemente da forma como é feita pode ser vista como um processo de fusão dos requisitos dos clientes com os requisitos do software e os requisitos de qualidade Os requisitos são representados de modo a levar a uma implementação bemsucedida do software Definir com precisão os requisitos de um software permite que todos os recursos da empresa e a energia da equipe de desenvolvi mento sejam direcionados a um fim claro Sem uma definição precisa daquilo que se pretende construir perdese tempo mais erros são cometidos e a qualidade do produto final é incerta KOSCIANSKI SOARES 2007 p 172 Os requisitos de qualidade de software segundo Wazlawick 2013 devem fazer parte da própria especificação do produto Geralmente são requisitos definidos para o software todo são suplementares e não para cada função específica Eles precisam ser avaliados de acordo com o grau de necessidade do produto e depois de uma análise financeira do projeto para se verificar se o investimento compensa Afinal a qualidade também tem um custo e o investimento compensa quando ela baixa os custos com falhas por exemplo Isso não significa que a qualidade deixará de ser uma meta em todas as etapas do processo mas é preciso considerar que existem níveis de quali dade e que qualidade não é sinônimo de perfeição mas de algo que atende às necessidades do clienteusuário de forma satisfatória Por exemplo ao se identificar um risco à qualidade do software em relação à confiabilidade como a indisponibilidade do sistema ao usuário é possível dividir a análise em subcategorias como mostra o Quadro 1 61 Influência dos requisitos na qualidade do software Quadro 1 Subcategorias do requisito confiabilidade Risco R001 indisponibilidade do sistema para o usuário Características Subcaracterísticas Objetivo Questão Métrica Confiabilidade Maturidade Avaliar a capaci dade de preven ção de falhas do sistema do ponto de vista do usuário Quantas falhas foram detectadas durante um período definido de experimentação Número de falhas detectadasnúmero de casos de testes Tolerância a falhas de recuperabilidade Avaliar a disponibilidade do sistema do ponto de vista do usuário Quantos padrões de defeitos são man tidos sob controle para evitar falhas críticas e sérias Número de ocorrências de falhas sérias e críticas evitadas conforme os casos de testes de indu ção de falhasnúmero de casos de testes de indu ção de falhas executados Quão disponível é o sistema para uso durante um período de tempo específico Tempo de operação tempo de operação tempo de reparo Total de casos em que o sistema estava disponível e foi utilizado com sucesso pelo usuário número total de casos em que o usuário tentou usar o software durante um período de tempo Qual é o tempo médio em que o sistema fica indisponível quando uma falha ocorre antes da inicialização Tempo ocioso total indisponívelnúmero de quedas do sistema Qual o tempo médio que o sistema leva para completar a recuperação desde o início Soma de todos os tempos de recuperação do sistema inativo em cada oportunidade número total de casos em que o sistema entrou em recuperação Fonte WAZLAWICK 2013 p 248 Qualidade e Usabilidade de Software 62 Ampliando seus conhecimentos Problemas de comunicação afetam o desenvolvimento de qualquer projeto O texto a seguir é uma metáfora de como esses problemas podem acarretar interpretações equivo cadas e soluções inadequadas e até mesmo estranhas para projetos muito simples Nesse sentido uma especificação bemfeita e documentada de requisitos pode evitar muitos malentendidos KOSCIANSKI SOARES 2007 p 172 173 Há uma ilustração que conta a história de desenvolvimento de um produto de software comparandoa com a instalação de um balanço em uma árvore Tratase de uma anedota conhe cida entre programadores e analistas de sistemas Tudo começa quando um cliente procura uma empresa dizendo precisar de um software O analista de sistemas o escuta com toda a atenção e faz uma série de perguntas Posteriormente ele escreve durante alguns minutos e faz um primeiro esboço do que o cliente descreveu Supondo que este não consiga expressar corretamente suas necessidades em relação ao programa o analista acrescenta um toque pes soal de maneira a cobrir certas lacunas Afinal por falta de conhecimentos de informática o cliente tem dificuldades para explicar o que precisa Posteriormente em uma reunião com a equipe da empresa o analista expõe suas anotações O gerente do projeto decide fazer algumas modificações para reduzir o cronograma inicial e cortar os custos de implementação A documentação toda passa em seguida para o analista Ele percebe que algumas das simplificações efetuadas pelo gerente retiraram funções que seriam provavelmente essenciais para o cliente Assim faz algumas adaptações com base em sua própria experiência sobre o assunto e projeta a solução a ser implementada 63 Influência dos requisitos na qualidade do software Finalmente o projeto completo é entregue ao programador Ao analisar as especificações ele descobre estar diante de um software que lhe custará muito trabalho Um dos princípios de bom projeto é a reutilização de código partes de programas que foram anteriormente desenvolvidos e estão funcionando corretamente podem ser empregadas para construir novos pro gramas O programador efetua então alguns pequenos ajustes nas especificações permitindo que partes de outros projetos possam ser aproveitadas Com isso o trabalho será concluído antes e o programador terá mais tempo para efetuar testes Uma vez que cada pessoa envolvida na construção do software contribuiu efetuando uma pequena modificação a cada estágio a especificação do produto acabou diferente da existente no estágio anterior Tal situação é ilustrada na figura O projeto seria um balanço em uma árvore Cada parte da figura mostra como uma das pessoas envolvidas pensava no produto não existia um acordo entre elas Por erros de comu nicação e falta de rigor ao seguir aquilo que foi estabelecido na etapa anterior o produto acabou diferente a cada nova fase A sequência da figura representa o que foi pedido ao analista pelo cliente o que o gerente do projeto planejou o que o analista projetou e o que foi realmente implementado pelo programador Figura Uma caricatura dos problemas de comunicação na produção de software Fonte Autoria desconhecida Qualidade e Usabilidade de Software 64 Considerando a situação em que as características de um produto não estão escritas em nenhum documento e são transmitidas apenas oralmente há muita possibilidade de que sejam compreendidas de diversas maneiras por diferentes indi víduos O pior é que é muito provável que as informações sejam simplesmente esquecidas Atividades 1 As empresas possuem processos de negócios iguais Justifique sua resposta 2 Defina requisitos funcionais e não funcionais 3 O levantamento de requisitos é um processo isolado de TI que con ta com a participação apenas dos profissionais dessa área Justifique sua resposta 4 Qual é o equívoco representado na figura a seguir em relação ao esforço para se obter qualidade no processo de desenvolvimento de um software Figura Ciclo de desenvolvimento no qual a qualidade se resume a testes de sottware Modelo de negócios Requisitos Análise e modelagem Implemen tação Testes de software Disponibili zação Esforço para obter qualidade Tempo Fonte BARTIÉ 2002 p 25 Processo de desenvolvimento de software Introdução Desenvolvimento de software contempla todo o processo de programação de computadores documentação testes correção de bugs1 e de erros envolvidos na criação e na manutenção de aplica tivos e estruturas resultando em um produto de software que deve seguir as especificações documentadas 1 Bug erro defeito falha de funcionamento 1 Erro de software ou hardware O termo vem dos primórdios da informática quando um defeito em computador era causado por um inseto 2 Equívoco ou funcionamento defeituoso 3 Equívoco ou erro cometido durante a fase de elaboração de um programa Pode ser do tipo sintá tico ou lógico No primeiro caso tem origem na codificação defeituosa na linguagem simbólica de programação utilizada e costuma ser detectado durante o processamen to de compilação que permite determinar a natureza do erro e corrigilo por diversos métodos Os erros de tipo lógico obedecem a um planejamento errôneo da solução do problema e não são detectáveis pela máquina que realiza corretamente os cálculos embora os resultados obtidos não sejam válidos SAWAYA 1999 p 60 4 Qualidade e usabilidade de software 66 O desenvolvimento de software envolve escrever e manter o código fonte mas em um sentido mais amplo inclui todas as etapas envolvidas entre a concepção do software desejado até o produto final dentro de um processo planejado e estruturado Portanto esse processo pode incluir pesquisa desenvolvimento prototi pagem2 modificação reutilização reengenharia manutenção e demais ativi dades que resultem na produção do software O software pode ser desenvolvido para uma variedade de propósitos sendo o mais comum atender às necessidades de um cliente ou negócio espe cífico Assim supre uma necessidade percebida de algum conjunto de usuá rios potenciais de software de código aberto ou então para uso pessoal por exemplo no caso de um pesquisador ou então de um empresário que precisa de um software específico para automatizar uma tarefa O software do sistema está implícito nas aplicações e no próprio processo de programação sendo muitas vezes desenvolvido em paralelo 41 Ciclo de desenvolvimento de software O desenvolvimento de software também chamado de ciclo de vida de desenvolvimento de software é aplicado especificamente para produtos de estrutura de software WEBER 2006 Umas das partes cruciais de um projeto de software é a boa escolha de seu ciclo de vida pois não sabendo escolhêlo bem o projeto pode acabar em decadência Portanto esta etapa do levantamento biblio gráfico é dedicada a esse assunto lembrando que para a escolha do ciclo de vida ele deve atender no mínimo as características principais do projeto GODOI NETO et al 2017 p 4 Existem vários modelos para a criação e desenvolvimento de um software e cada um deles descreve uma abordagem diversa para diferentes atividades que ocorrem durante o processo WAZLAWICK 2013 2 A prototipagem é o processo de construir um sistema experimental rapidamente e a baixo custo para demonstração e avaliação de modo que os futuros clientes ou usuários do sistema possam melhor determinar os requerimentos dele REZENDE 2005 p 134 67 Processo de desenvolvimento de software O ciclo de desenvolvimento apresentado por Yourdon 1989 apud REZENDE 2005 p 42 é dividido em etapas a fim de projetar e desenvol ver um produto de software de forma eficiente estudo de viabilidade análise de sistemas projeto implementação geração do teste de aceite garantia da qualidade descrição de procedimentos conversão de banco de dados insta lação Essas etapas são apresentadas a seguir 2 Estudo de viabilidade identifica as deficiências atuais estabelece objetivos do novo sistema gera cenários aceitáveis prepara encar gos de projeto 2 Análise de sistemas desenvolve o modelo ambiental desenvolve o modelo comportamental estabelece os limites homemmáquina executa a análise custobenefício seleciona opção restringe o sis tema faz a especificação do pacote 2 Projeto aloca especificações para os processadores aloca especi ficações às tarefas deriva o diagrama estrutural avalia o diagrama estrutural projeta módulos projeta banco de dados faz o empaco tamento do projeto 2 Implementação soluciona o próximo módulo codifica o módulo testa o esqueleto do sistema 2 Geração do teste do aceite gera plano de teste prepara testes de performance prepara testes de vias normais prepara testes de vias de erro empacota os testes 2 Garantia da qualidade faz o teste final ou teste de aceite compa rando o produto ao projeto de implementação 2 Descrição dos procedimentos faz descrições das atividades opera cionais do cliente ou usuário 2 Conversão de banco de dados pode envolver mais trabalho e planejamento do que desenvolvimento de programas para o novo sistema e em outros casos pode não haver uma base de dados para ser convertida Qualidade e usabilidade de software 68 2 Instalação atividade final suas entradas são o manual do usuário o banco de dados convertido e o sistema de aceite Modelos de ciclo de vida de desenvolvimento de software são muito discutidos na literatura e se diferenciam pelo grau de controle aplicado sobre o processo e por sua visibilidade ao cliente CYBIS et al 2015 A seguir vejamos os ciclos de vida mais usados e de que modo eles influenciam na qualidade do software a ser desenvolvido 411 Codificaremenda ou codificarecorrigir Segundo Schach 2010 infelizmente ainda muitos produtos são desen volvidos seguindo esse ciclo de vida É o modelo menos profissional de todos em que o software vai sendo desenvolvido sem que haja um projeto nem o levantamento das necessidades do clienteusuário e das especificações Nesse modelo a equipe de desenvolvimento faz o software da forma como acredita que deve ser feito e depois o retrabalha quantas vezes forem necessárias até que o cliente fique satisfeito SHACH 2010 Na Figura 1 é possível verificar a ausência do levantamento de necessidades e especificações Figura 1 Modelo de ciclo de vida codificaremenda Descontinuação do produto Manutenção pósentrega Modificar até que o cliente fique satisfeito Desenvolvimento Manutenção Implementar a primeira versão Fonte SCHACH 2010 p 50 69 Processo de desenvolvimento de software Ainda segundo Shach 2010 esse ciclo de vida até pode vir a funcionar bem em programas menores e mais simples mas é inviável para programas maiores pois seu custo e seu tempo de desenvolvimento aumentam conside ravelmente além de exaurir a equipe e o cliente em testes sem fim Outro problema apontado pelo autor é que a falta de especificações atra palha na manutenção do software depois de pronto e entregue ao cliente Embora esse modelo seja considerado o mais fácil para desenvolver software é de longe o pior deles 412 Cascata Esse modelo de ciclo de vida também chamado de clássico ou linear foi proposto por Winston Royce no ano de 1970 É um ciclo de vida que eventualmente suporta iterações3 contudo basicamente é um modelo pouco flexível com muitas restrições Isso porque se caracteriza por progre dir de forma sequencial entre uma fase e a seguinte e essa sequencialidade acaba causando diversos problemas ao desenvolvimento do software e afe tando sua qualidade Um ponto crítico referente ao modelo cascata é que nenhuma fase é terminada até que a documentação para essa fase tenha sido comple tada e os produtos dessa fase tenham sido aprovados pelo grupo de SQA garantia da qualidade de software Isso acarreta modificações se os produtos de uma fase anterior tiverem de ser modificado como consequência de se seguir uma volta de realimentação essa fase ante rior é considerada completa apenas quando a documentação para ela tiver sido modificada e as modificações tiverem sido verificadas pelo grupo de SQA SCHACH 2010 O modelo de ciclo de vida cascata tem a vantagem de possuir pontos de controle que permitem demarcar as fases do processo facilitando a gestão 3 Iterações são ciclos curtos que têm duração de poucas semanas garantindo dessa forma feedbacks frequentes e respostas rápidas às mudanças Segundo Martins 2010 em cada iteração uma parte do software é produzida Ao final de cada iteração é possível avaliar o progresso do projeto e dessa forma o software é produzido incrementalmente à medida em que as iterações ocorrem Qualidade e usabilidade de software 70 do projeto e a manutenção do software depois de pronto devido ao controle da documentação Porém ele é rígido e burocrático porque não permite a correção de erros nas fases anteriores e possui baixa visibilidade para o cliente pois este não recebe feedback nos pontos de controle existentes assim o único resultado que o cliente vê é o final Figura 2 Exemplo típico de modelo em cascata Requerimentos Desenvolvimento Implementação Verificação Produção Fonte TORRES 2014 Como mostra a Figura 2 no modelo em cascata o andamento do pro cesso flui de cima para baixo como uma cascata e o progresso de uma fase para a próxima se dá de forma sequencial Somente quando uma fase está completa e perfeita podese seguir para a próxima não existindo sobreposi ção de fases ou mesmo a possibilidade de pular a execução de uma fase No 71 Processo de desenvolvimento de software entanto na realidade o desenvolvimento de um software não ocorre dessa forma pois muitas atividades são desenvolvidas paralelamente As etapas do modelo em cascata são apresentadas a seguir 2 Requisitos etapa na qual se estabelecem os requisitos do produto que se deseja desenvolver os serviços a serem fornecidos limitações e objetivos do software Esta etapa pode ser vista como a etapa de concepção de um produto ou software 2 Desenvolvimento é o processo de passos do projeto que representa os requisitos de uma forma que permita a codificação do produto É o projeto documentado para que se transforme em software 2 Implementação é a etapa em que são criados os programas 2 Verificação é a etapa de testes do sistema Após a codificação con cluída começa a fase de testes e verificação do sistema Essa fase examina se foram solucionados os erros de software e assegura que as entradas produzam resultados reais conforme os requisitos que foram descritos 2 Produção etapa de aprovação para que o sistema entre em pro dução para isso todas as fases e testes devem ter sido realizados e a coleta de aprovações dos usuários e envolvidos no projeto deve ser feita para se colocar o sistema em produção Apesar de todos os seus problemas o modelo cascata foi empre gado durante muitos anos Atualmente no entanto tem sido pouco uti lizado devido à complexidade cada vez maior dos produtos desenvolvidos SCHACH 2010 Qualidade e usabilidade de software 72 413 Modelo V Esse modelo de ciclo de vida foi concebido por Alan Davis e contém as mesmas etapas do ciclo de vida em cascata sendo considerado uma variação deste como se pode observar na Figura 3 Figura 3 Modelo V Modelagem de requisitos Teste de aceitação Projeto da arquitetura Teste de sistema Projeto de componente Teste de integração Geração de código Software executável Teste de unidade Fonte PRESSMAN MAXIM 2016 p 43 Segundo a figura o projeto segue de forma sequencial e linear até a geração de códigos lado esquerdo do V e a partir daí a equipe passa para o outro lado do V realizando testes que validam cada fase do lado esquerdo Segundo Pressman e Maxim 2016 p 42 não há nenhuma diferença fun damental entre o ciclo de vida clássico e o modelo V Além das abordagens clássicas há outros modelos de ciclo de vida chamados evolucionários que são basicamente iterativos e possibilitam o desenvolvimento de versões mais completas dos softwares O ciclo de vida em espiral e o modelo de prototipagem evolutiva são os mais comuns 73 Processo de desenvolvimento de software 414 Espiral Modelo de ciclo de vida em que um produto é desenvolvido em diversas iterações Uma iteração nova representa uma volta na espiral Sua vantagem é que permite a construção de produtos com prazos curtos e a sua desvanta gem é que ele é mais difícil de ser gerido WAZLAWICK 2003 A Figura 4 apresenta um exemplo de ciclo de vida em espiral Figura 4 Modelo em espiral 1 Determinar objetivos 2 Identificar e resolver riscos 4 Planejar a próxima iteração Custo acumulativo Progresso 3 Desenvolvimento e testes Revisão Plano de requeri mentos Requeri mentos Conceito de Requeri mentos Conceito de operação Plano de desenvolvimento Verificação e validação Verificação e validação Plano de testes Análise de riscos Análise de riscos Análise de riscos Protótipo 1 Protótipo 2 Protótipo operacional Desenho detalhado Esboço Código Integração Testes Entrega Implementação Fonte TORRES 2014 No modelo em espiral as atividades são realizadas no sentido horário partindo do centro da espiral e passando por quatro quadrantes A fase 1 cor responde à determinação dos objetivos e soluções alternativas além das restri ções do sistema Na fase 2 devem ser analisados os riscos das decisões da fase anterior quando podem ser construídos protótipos e realizadas simulações do software Na fase 3 de desenvolvimento de testes estão as atividades de desenvolvimento incluindo design especificação codificação e verificação A principal característica dessa fase é que cada especificação vai ressurgindo a cada ciclo especificação de requisitos do software da arquitetura da inter face de usuário e algoritmos devendo ser feita a verificação correta Na fase 4 Qualidade e usabilidade de software 74 de planejar a próxima iteração estão as revisões das etapas anteriores e o pla nejamento da próxima fase Nessa etapa dependendo dos resultados obtidos nas fases anteriores podese optar por seguir o desenvolvimento no modelo cascata por exemplo ou optar pela construção de novos protótipos Cada circuito em volta da espiral pode representar uma iteração como explicam Pressman e Maxim 2016 p 48 O primeiro circuito em volta da espiral pode resultar no desenvolvi mento de uma especificação de produto passagens subsequentes em torno da espiral podem ser usada para desenvolver um protótipo e então progressivamente versões cada vez mais sofisticadas do soft ware Cada passagem pela região de planejamento resulta em ajus tes no planejamento do projeto Custo e cronograma são ajustados de acordo com o feedback a realimentação obtido do cliente após a entrega Além disso o gerente de projetos faz um ajuste no número de iterações planejadas para concluir o software Para esses autores o modelo espiral é mais realista para o desenvolvi mento de softwares pois o software evolui aos poucos e os riscos são avalia dos a cada nível evolucionário A prototipação pode ser aplicada em qual quer estágio reduzindo os riscos e solucionando os problemas à medida que eles surgem 415 Prototipagem evolutiva Também chamada de prototipação4 utiliza o modelo de ciclo de vida em espiral para construir o produto em protótipos que cobrem progressivamente os requisitos até a finalização do produto Sua vantagem é que possui visibi lidade permitindo a verificação antecipada do produto final e a correção dos problemas detectados Além disso apresenta alta flexibilidade por permi tir ajustes durante o desenvolvimento do produto Como desvantagens esse 4 Segundo o Dicionário de informática e internet prototipação consiste na criação de um modelo funcional protótipo de um novo sistema de computador ou programa para testes e refinamentos A prototipação costuma ser utilizada no desenvolvimento de novos sistemas de hardware e softwares e também em novas aplicações de gerenciamento de informações As ferramentas utilizadas nos dois primeiros casos incluem equipamentos e programas de apoio SAWAYA 1999 p 375 75 Processo de desenvolvimento de software método precisa de equipes disciplinadas e experientes o projeto deve ser bem realizado para que a estrutura do produto permaneça confiável ao longo dos protótipos e ele é mais difícil de ser gerido WAZLAWICK 2003 Figura 5 Prototipagem evolutiva Construção de protótipo Comunicação Planejamento rápido Modelagem Projeto rápido Entrega e feedback Fonte PRESSMAN MAXIM 2016 p 45 O ciclo da prototipação começa com a fase de comunicação coleta e refinamento dos requisitos As fases seguintes são o planejamento rápido a modelagem rápida na qual é desenvolvido o protótipo e a construção do protótipo Por fim a fase de implantação entrega e feedback finaliza o ciclo Segundo Pressman e Maxim 2016 esse modelo funciona bem quando o cliente não tem claros os requisitos e os detalhes do software de que neces sita O protótipo construído ajuda tanto o cliente como a equipe de desen volvimento a entender melhor o produto que vão criar Esse protótipo pode ser descartado por não representar o desejo do cliente ou pode evoluir até se transformar no produto final Qualidade e usabilidade de software 76 416 Entrega evolutiva Esse modelo de ciclo de vida é uma combinação dos modelos cascata e prototipagem evolutiva Apresenta a vantagem de ter alta visibilidade para os clientes e facilidade de gestão por possuir pontos de controle bem definidos Sua desvantagem é a necessidade de um projeto robusto para que a estru tura do produto permaneça confiável ao longo das liberações programadas CYBIS et al 2015 O objetivo da entrega evolutiva é obter o máximo de feedback do cliente sobre o que foi entregue de modo que a próxima entrega seja planejada de acordo com esse feedback recebido garantindo mais agilidade e qualidade ao produto Seguese o mesmo ciclo da prototipagem evolutiva com a diferença que as entregas referemse a partes do software ou sistema Conhecer os diversos ciclos de vida de software existentes permite à orga nização escolher o melhor modelo para desenvolver um projeto de acordo com as necessidades do clienteusuário e a capacidade de produção da orga nização Mesmo que a empresa decida por não desenvolver mas terceirizar a produção de software ela tem que ter competência para gerir os processos de aquisição implantação adaptação e integração desses sistemas com a orga nização Isso pode sair mais caro do que o processo de desenvolvimento em si daí a importância de entender esses processos para fazer a melhor escolha VALERIANO 2005 42 Garantia da qualidade do software A garantia de qualidade do software é obtida por meio de processos de engenharia de software de monitorização e aplicação de métodos de qua lidade que ocorrem por meio de intervenções da gestão de qualidade no sistema de software que está sendo criado Essas intervenções são apoiadas por uma ou mais normas geralmente a ISO 9000 WAZLAWICK 2003 A qualidade do software é o conjunto de qualidades que caracteri zam e determinam a sua utilidade e existência Qualidade é sinônimo de eficiência flexibilidade precisão confiabilidade facilidade de manutenção 77 Processo de desenvolvimento de software portabilidade usabilidade segurança e integridade A qualidade do software é portanto mensurável e varia de um sistema para outro ou de um programa para outro Como afirma Valeriano 2005 p 88 a qualidade do software é o grau em que um sistema componente ou processo atende aos requisitos especificados e às necessidades e expectativas do cliente ou do usuário A qualidade do software engloba os requisitos e os padrões atendidos como demonstrado na Figura 6 Figura 6 Software com qualidade Usuário Requisitos atendidos Padrões atendidos Software com qualidade Desenvolvedor Organização Processo de desenvolvimento Software produto Requisito Padrões Processo de software Fonte Elaborada pela autora De acordo com a Figura 6 verificase que os elementos usuário desen volvedor e organização devem em conjunto traçar os requisitos para o desenvolvimento do software que deve atender a alguns padrões normas para que possa ser considerado um software de qualidade O Software Quality Assurance ou SQA é um conjunto de atividades sis temáticas e planejadas para garantir que os processos de software e produtos cumpram com os requisitos as normas e os procedimentos de processo de produtos design de software documentação de codificação suporte de teste e manutenção SOMMERVILLE 2011 Com o SQA a qualidade não é apenas responsabilidade da equipe de desenvolvimento do projeto mas é medida por uma série de testes de qua lidade Esses testes foram inicialmente desenvolvidos pela indústria militar Qualidade e usabilidade de software 78 durante a década de 1970 nos Estados Unidos e foram se difundindo e aprimorando até se tornar o SQA PRESSMAN MAXIM 2016 Segundo Pressman e Maxim 2016 o SQA inclui uma abordagem de gestão da qualidade engenharia de software revisões técnicas formais aplica das durante o processo de software um teste de estratégia multiescalada um software de controle de documentos e mudanças e um procedimento para garantir um ajuste ao desenvolvimento de padrões de software A finalidade da garantia de qualidade é dotar a gestão com dados neces sários sobre a qualidade do produto por isso a aquisição da qualidade deve cumprir sua visão e objetivo CAIÇARA JR 2007 Assim o SQA dá visibilidade aos processos utilizados pelo projeto e os produtos que ele gera Para Pressman e Maxim 2016 entre os objetivos da SQA estão realizar atividades de planejamento de garantia de qualidade avaliar e auditar os produtos e atividades para verificar sua conformidade com os procedimentos e as normas e fornecer os resultados dessas revisões ou auditorias de relatórios de gestão Cabe aos gestores trabalhar com a equipe do projeto desde o início eles devem ser objetivos e independentes e ajudar no projeto em vez de apenas controlar as atividades O processo de verificar se as normas estão sendo aplicadas corretamente pode ser feito pela equipe de desenvolvimento no caso de pequenos projetos mas nos grandes projetos um grupo específico deve se dedicar a essa função ISNARD 2012 421 Vantagens do SQA Um plano SQA pode tomar uma série de caminhos testandose diferen tes capacidades e análises de execução dependendo das exigências do projeto dos usuários e do software Deve buscar PRESSMAN MAXIM 2016 a maior satisfação dos clientes com métodos melhorados e um bom relaciona mento com eles além do desenvolvimento do software com custo reduzido e sem comprometer a qualidade 79 Processo de desenvolvimento de software Sobre a metodologia do SQA ressaltase que o teste de software é consi derado uma arte e uma ciência que requer a adoção de aplicações complexas para o desenvolvimento de diferentes sistemas operacionais Várias aplicações de software requerem diferentes abordagens quando estão na fase de teste mas algumas das tarefas mais comuns de controle de qualidade incluem os passos elencados na Figura 7 Figura 7 Teste de software Validação do teste Comparação Testes de usabilidade 2 O teste de validação é realizado para checar se há algum erro 2 Compara a saída de um uso específico com um sistema de dados previamente criado com os mesmos parâmetros 2 Usuários que não estão familiarizados com o software for necem feedback para os desenvolvedores sobre o que eles acharam difícil de fazer Essa é a melhor forma de realizar melhorias em uma interface Fonte SOMMERVILLE 2011 Adaptado As atividades de qualidade do produto englobam a norma ISOIEC 9126 que consiste na atual padronização mundial para a qualidade de software Essa norma está baseada em três níveis características subcaracterísticas e métricas sendo que cada característica é formada por um conjunto de subcaracterísticas e cada subcaracterística é avaliada por um conjunto de métricas As características de qualidade do software devem responder aos seguin tes questionamentos PFLEEGER 2004 2 Funcionalidade O produto satisfaz as necessidades do usuário 2 Confiabilidade É imune a falhas Qualidade e usabilidade de software 80 2 Usabilidade É fácil de usar 2 Eficiência É rápido e simples 2 Manutenibilidade É fácil de modificar 2 Portabilidade É fácil de usar em outro ambiente A ISOIEC 9126 define essas características principais da qualidade do produto da seguinte maneira PFLEEGER 2004 Funcionalidade tratase de um conjunto de atributos que evidenciam a existência de funções e suas propriedades especificadas As funções devem satisfazer as necessidades explícitas e implícitas para que o software seja con siderado funcional Usabilidade referese ao conjunto de atributos que evidenciam o esforço necessário para se poder usar o software assim como o julgamento individual desse uso por um conjunto explícito ou implícito de usuários Nesse sentido o software apresenta usabilidade se faz com que o usuário tenha sucesso na execução das tarefas propostas pelo sistema Confiabilidade é o conjunto de atributos que evidenciam a capa cidade do software de manter seu nível de desempenho sem que ocorram falhas ou interrupções sob condições estabelecidas durante certo período de tempo Eficiência tratase de um conjunto de atributos que evidenciam o relacionamento entre o nível de desempenho do software e a quantidade de recursos usados sob condições estabelecidas Um software é eficiente quando atende seu objetivo sem ser complicado de forma simples e objetiva Manutenibilidade é o conjunto de atributos que evidenciam o esforço necessário para fazer modificações especificadas no software Ele deve possibi litar correções e alterações sempre que for preciso mesmo depois de entregue ao cliente Portabilidade diz respeito ao conjunto de atributos que evidenciam a capacidade do software de ser transferido de um ambiente para outro sem haver a necessidade de criação de um programa semelhante para ser usado em outra plataforma 81 Processo de desenvolvimento de software 43 Métodos ágeis validações e indicadores 431 Métodos ágeis O desenvolvimento ágil de software envolve uma abordagem para a tomada de decisões em projetos da área a qual se refere a métodos de enge nharia de software Essa abordagem diz respeito a um grupo de metodologias utilizadas na criação de programas que baseia o seu desenvolvimento em um ciclo iterativo no qual os requisitos e as soluções evoluem por meio da cola boração entre diferentes equipes envolvidas no projeto Assim o trabalho é feito por colaboração sendo autoorganizado por equipes multidisciplinares envolvidas em um processo de tomada de decisão compartilhada no curto prazo PFLEEGER 2004 Métodos ágeis enfatizam mais a comunicação face a face do que a docu mentação em si Equipes mais ágeis estão localizadas em um único escritó rio aberto às vezes chamado de plataforma de lançamento O escritório ou a equipe deve incluir revisores e responsáveis pela documentação além de designers de iteração e gerentes de projeto PFLEEGER 2004 A metodologia ágil engloba segundo Sommerville 2011 2 Valorização das pessoas e suas interações sobre processos e ferra mentas processos de qualidade com bons relacionamentos trazem bons resultados 2 Avaliação da documentação a documentação é necessária porque permite a transferência de conhecimento mas sua redação deve ser limitada ao que contribui ao valor direto do produtoserviço 2 Taxa de colaboração com o cliente sobre negociação de contrato embora sejam necessários os contratos não acrescentam valor aos produtosserviços Metodologias ágeis ao cliente integram e mantêm o projeto com o objetivo de proporcionar o maior valor possível em cada iteração Dos valores básicos é possível extrair vários princípios que qualificam a filosofia da gestão ágil PFLEEGER 2004 dentre os quais se destaca a Qualidade e usabilidade de software 82 busca pela satisfação do cliente por intermédio da entrega inicial e contínua de valor em períodos de 15 a 60 dias As mudanças de requisitos dentro do período mencionado são bemvin das para que haja melhor integração do projeto Uma boa comunicação entre usuário desenvolvedor e cliente também é essencial para o desenvolvimento do produto Além disso o produto funcional por exemplo software operacional é a principal medida de progresso devendose enfatizar o foco no grau de acabamento e no tempo de conclusão previsto As características básicas de projetos geridos com metodologias ágeis são as seguintes SOMMERVILLE 2011 2 Incerteza indica a necessidade estratégica da previsão de riscos no desenvolvimento 2 Equipes autoorganizadas não existem funções especializadas na equipe 2 Autonomia liberdade para a tomada de decisão 2 Autoaperfeiçoamento periodicamente o produto tem de ser desenvolvido e avaliado 2 Autoenriquecimento conhecimento e transferência de conhecimento 2 Fases de desenvolvimento que se sobrepõem as fases não existem como tal mas as tarefasatividades são realizadas de acordo com a evolução das necessidades ao longo do projeto Na verdade muitas vezes não é possível fazer um projeto técnico detalhado antes de se começar a desenvolvêlo e ver alguns resultados Além disso as fases tradicionais realizadas por pessoas diferentes não promovem o trabalho em equipe e podem gerar mais desvantagens do que vantagens por exemplo um atraso de fase afeta todo o projeto 2 Controle sutil pontos de controle local para monitorar adequa damente sem limitar a liberdade e a criatividade da equipe Além disso recomendase nesse processo avaliar o ambiente de traba lho sendo fundamental escolher pessoas que não entrem em conflito entre si compreender os erros como pontos de melhoria e aprendizado e melhorar a 83 Processo de desenvolvimento de software interação entre a equipe e a organização para que possam atender às neces sidades do projeto Também é essencial a difusão e transferência de conhe cimentos controlando a alta rotatividade dos membros da equipe entre os diferentes projetos PFLEEGER 2004 Atualmente a metodologia ágil mais popular para gerenciamento de projetos é o Scrum5 MELO et al 2013 4311 Scrum O Scrum é uma metodologia cujas práticas são aplicadas em um processo iterativo e incremental Assumese que os projetos em que o Scrum se insere são complexos e imprevisíveis no quais não é possível prever tudo que irá acon tecer Por essa razão ele oferece um conjunto de práticas que torna tudo isso visível SCHWABER 2004 como um ciclo de vida específico Figura 8 Figura 8 Ciclo de vida do Scrum Tarefas de Backlog detalhadas pela equipe Backlog da Sprint Daily meeting 24 horas 30 dias Backlog priorizado pelo Product Owner Produto incremental a ser entregue Fonte MOUNTAIN GOAT SOFTWARE 2017 A estrutura de processo do Scrum iniciase com uma visão do produto que será desenvolvido com a apresentação das características definidas pelo cliente das premissas e restrições Em seguida é criado o product backlog a 5 O livro Scrum a arte de fazer o dobro do trabalho na metade do tempo de Jeff Sutherland 2014 cocriador do Scrum é a melhor referência para ficar por dentro dessa metodologia de projetos Qualidade e usabilidade de software 84 lista contendo todos os requisitos conhecidos do produto O product backlog é então priorizado e dividido em releases e cada um deles contém um conjunto de requisitos denominado sprint backlog que será desenvolvido em uma ite ração chamada de Sprint MARÇAL et al 2007 Na execução do Sprint diariamente a equipe faz reuniões de 15 minu tos Daily Scrum Meeting para acompanhar o andamento do projeto Ao final do Sprint é realizado o Sprint Review Meeting de modo que o time apresente o resultado alcançado ao Product Owner representante do cliente Esse resultado recebe o nome de Increment of Potentially Shippable Product Functionality Em seguida o Scrum Master o gestor do projeto conduz o Sprint Retrospective Meeting com o objetivo de melhorar a equipe o processo ou o produto para o próximo Sprint 432 Validações e indicadores Para a determinação da qualidade do software a partir da perspectiva de produto acabado é necessária a avaliação de um conjunto de indicadores que respondam a diferentes critérios e fatores consistentes com a estrutura da ISO 9126 norma padrão que permite a melhor adaptação e padronização dos vários processos de qualidade de software SOMMERVILLE 2011 Assim a fim de serem validados os indicadores devem apresentar apli cabilidade eficiência e relevância Para atender a esses itens os indicadores devem ser testados e devem prezar pela segurança e pela qualidade Uma vez que o processo de avaliação foi concluído de acordo com diferentes fatores e critérios os principais indi cadores da qualidade do software podem ser elencados como descrito a seguir PFLEEGER 2004 A funcionalidade pode ser definida como o conjunto de critérios e indi cadores correspondentes relacionados com as propriedades específicas que atendem às necessidades do cliente A funcionalidade do software deve ter as seguintes características adequação acurácia interoperabilidade segurança de acesso e conformidade Por exemplo o usuário deve ter facilidade para utilizar o software com segurança 85 Processo de desenvolvimento de software Esse indicador deve corresponder aos critérios de PFLEEGER 2004 2 adequação o conjunto de indicadores para assegurar que o con teúdo é adequado 2 precisão interoperabilidade6 e segurança sua definição está em consonância com a função adequada que executa 2 compliance o conjunto de indicadores para assegurar que o soft ware está descrito de acordo com padrões estabelecidos A confiabilidade é definida como um grupo de critérios e indicado res correspondentes relacionados com a capacidade de manter o seu nível de desempenho sob condições estabelecidas por um período determinado SOMMERVILLE 2011 Por exemplo um sistema deve ser seguro e fun cionar no tempo requerido Precisa estar em concordância com os seguintes critérios PFLEEGER 2004 2 maturidade deve ser compreendido como a capacidade de se repetir uma série de resultados de maneira previsível 2 capacidade de recuperação o conjunto de indicadores para asse gurar que as propriedades específicas do software caso sejam perdi das possam ser recuperadas 2 tolerância a falhas o software precisa ser projetado para suportar erros e falhas e mecanismos de restauração devem estar disponíveis A usabilidade é o conjunto de critérios e indicadores relacionados com o esforço necessário para o uso do software e a avaliação individual de tal utilização por um grupo declarado ou implícito de usuários como por exemplo a facilidade de usuários utilizarem dados do sistema por intermédio de atalhos A usabilidade corresponde aos critérios de PFLEEGER 2004 2 aprendizagem o conjunto de indicadores para assegurar a apren dizagem para o sistema a que se destina 6 Uma vez conseguida a conectividade a interoperabilidade referese aos recursos lógicos que permitem a comunicação entre programas diferentes ou com configurações diferentes e tam bém a manipulação dos dados formatos e características diversas SAWAYA 1999 p 242 Qualidade e usabilidade de software 86 2 compreensibilidade o conjunto de indicadores para assegurar a compreensão dos elementos que o compõem 2 operacionalidade definida de acordo com a função correta que ele executa 2 atratividade o conjunto de indicadores para assegurar que seja atraente do ponto de vista dos usuários a quem se destina Por fim a eficiência é definida como um conjunto de critérios e indica dores correspondentes que dizem respeito ao desempenho da quantidade de recursos necessários sob condições estabelecidas SOMMERVILLE 2011 Como exemplo mencionase a capacidade de o sistema realizar uma função em menos tempo A eficiência deve estar relacionada a critérios de 2 comportamento ao longo do tempo definido em correspondên cia com a função adequada que o produto executa 2 comportamento do recurso o conjunto de indicadores para asse gurar o fator de acordo com a portabilidade ou seja a capacidade de ser transferido de uma plataforma para outra Como observado métodos validações e indicadores devem ser adota dos no processo do desenvolvimento do software sempre buscandose uma melhoria na qualidade Os métodos e os indicadores são baseados em critérios que buscam vali dações com o intuito de se atingir uma boa funcionalidade confiabilidade usabilidade e eficiência Ampliando seus conhecimentos No texto a seguir Jeff Sutherland cocriador do método Scrum explica em que se baseou para criálo comparao com o método cascata e apresenta suas principais características 87 Processo de desenvolvimento de software Uma nova forma de pensar SUTHERLAND 2014 p 1516 Esta nova abordagem se chama Scrum Eu a criei vinte anos atrás Agora essa é a única maneira comprovada de ajudar projetos desse tipo Existem duas forma de fazer as coisas o método antigo da cascata que gasta centenas de milhões de dólares e não entrega nenhum resultado ou a nova forma que com menos gente e em menos tempo consegue mais resultados com mais qualidade e menos custos Sei que soa bom demais para ser verdade mas a prova está nos resulta dos Funciona mesmo O motivo por que ela funciona é simples Eu olhei a forma como as pessoas realmente trabalham em vez de como elas dizem que trabalham Analisei uma pesquisa realizada por décadas e as melhores práticas de empresas em todo o mundo e analisei mais a fundo as melhores equipes nessas empresas O que as tornava superiores O que as tornava diferentes Por que algumas equipes atingem resultados excepcionais e outras apenas resultados medíocres eu chamei de Scrum essa estrutura de desempenho de equipe O termo vem do jogo de rúgbi e se refere à maneira como um time trabalha junto para avançar com a bola no campo Alinhamento cuidadoso unidade de propósito cla reza de objetivo tudo se unindo Tratase de uma metáfora perfeita para o que uma equipe deseja fazer O Scrum acolhe a incerteza e a criatividade Coloca uma estrutura em volta do processo de aprendizagem permitindo que as equipes avaliem o que já criaram e o mais importante Qualidade e usabilidade de software 88 de que forma o criaram A estrutura do Scrum busca aprovei tar a maneira como as equipes realmente trabalham dando a elas as ferramentas para se autoorganizar e o mais impor tante aprimorar rapidamente a velocidade e a qualidade de seu trabalho Em essência o Scrum tem como base uma ideia simples ao começar um projeto por que não fazer paradas regulares para verificar se o que está sendo feito está seguindo na direção certa e se na verdade os resultados são os que as pessoas desejam E verificar se existem maneiras de aprimorar a forma como se está trabalhando para obter resultados melhores e executados mais rapidamente e quais seriam os obstáculos que impedem as pessoas de obtêlos Os resultados finais do Scrum ou o objetivo do projeto se preferir são equipes que melhoram drasticamente a produtividade Atividades 1 O que diferencia um modelo de ciclo de vida de desenvolvimento de software 2 Em que situação a prototipagem evolutiva deve ser empregada Por quê 3 O que os métodos ágeis de desenvolvimento de software enfatizam 4 Quais são os principais indicadores da qualidade do software Gerência da qualidade de software Introdução A gerência da qualidade do software garante que o nível de qualidade exigido pelo cliente seja alcançado por meio de melhorias no processo de desenvolvimento do produto Esse tipo de gestão visa desenvolver uma cultura de aprimoramento dentro da equipe e é visto como responsabilidade de todos A gerência de qualidade deve ser independente da gestão do projeto para garantir que o software seja elaborado com qualidade e dentro do prazo e do custo estipulados Essa gestão afeta dire tamente a qualidade do desenvolvimento do processo e indireta mente a qualidade do produto 5 Qualidade e usabilidade de software 90 Um gerenciamento de qualidade de software inclui o Software Quality Assurance SQA ou Garantia de Qualidade de Software que visa desen volver procedimentos e padrões em nível organizacional Assim são realiza dos o Planejamento da Qualidade de modo a selecionar os procedimentos e padrões aplicáveis a um projeto específico e modificálos conforme neces sário e o Controle de Qualidade para assegurar que as melhores práticas e padrões vistos no capítulo 2 sejam seguidos pela equipe de desenvolvimento de software resultando em produtos de alta qualidade 51 Dimensões da qualidade do processo e do produto A qualidade do processo e do produto decorrentes do desenvolvi mento de software está ligada à percepção e às expectativas dos consumido res em termos das dimensões de qualidade de serviço PARASURAMAN ZEITHAML BERRY 2005 511 Dimensões da qualidade do processo Parasuraman Zeithaml e Berry 2005 argumentam que a qualidade percebida é uma função da diferença entre expectativa e desempenho ao longo de um sistema estabelecido de dimensões de qualidade De acordo com Johnston 1995 é necessário reconhecer os determinantes ou as dimensões do projeto para se poder especificar medir controlar e melhorar a qualidade do serviço percebida pelos clientes identificandose os problemas que possam influenciar o julgamento geral destes em relação ao produto Segundo Parasuraman Zeithaml e Berry 2005 são cinco as dimensões que avaliam a qualidade no desenvolvimento de serviços 1 Tangibilidade entendida como a aparência das instalações físicas dos equipamentos e do material de comunicação 2 Confiabilidade que é a capacidade de executar o serviço prome tido com precisão e formalidade No que se refere a essa dimensão 91 Gerência da qualidade de software Boulding et al 1993 argumentam que embora a qualidade do serviço seja multidimensional a confiabilidade é fundamental na determinação global da qualidade percebida do serviço Ou seja no modelo dinâmico de qualidade de serviço a confiabilidade é o principal manipulador da percepção geral de serviço ao cliente 3 Sensibilidade definida como a vontade de ajudar os clien tes e fornecer um serviço rapidamente Sobre essa dimensão Parasuraman Zeithaml e Berry 2005 relatam que ter sensibi lidade significa servir os clientes de forma ágil e responder rapi damente às suas solicitações ou reclamações Outro aspecto da sensibilidade diz respeito à pontualidade no serviço de campo e ao tempo de reparação técnica 4 Garantia que compreende o conhecimento e a cortesia dos fun cionários e sua capacidade de inspirar confiança 5 Empatia que envolve os cuidados e o atendimento individuali zado que a empresa oferece aos seus clientes Por meio dessas dimensões é possível compreender os tradeoffs1 viven ciados pelos clientes o que pode ajudar a construir uma vantagem competi tiva em relação à concorrência 512 Dimensões da qualidade segundo Garvin David Garvin 2015 propôs oito diferentes dimensões da qualidade desempenho recursos confiabilidade conformidade durabilidade faci lidade de manuseamento estética e qualidade percebida Figura 1 Para o autor algumas dessas dimensões se reforçam mutuamente enquanto outras não 1 Tradeoff é um termo em inglês que significa o ato de escolha de um produto ou serviço em detrimento de outro Muitas vezes é traduzido como perdeeganha pois implica um conflito de escolha quem escolhe deve conhecer os pontos positivos e os negativos de um produto ou serviço para escolher aquele que atende melhor às suas necessidades Ele precisa avaliar bem cada um para fazer a melhor escolha pois deixará de usufruir dos benefícios do produto ou serviço que não foi escolhido Qualidade e usabilidade de software 92 Figura 1 Dimensões da qualidade segundo Garvin 2015 Desempenho Recurso Confiabilidade Conformidade Durabilidade Qualidade percebida Dimensões de qualidade Facilidade de manuseamento Estética Fonte Elaborada pela autora com base em GARVIN 2015 As oito dimensões são explicadas por Garvin conforme exposto a seguir 5121 Desempenho Referese às principais características operacionais de um produto ou serviço Essa dimensão de qualidade abrange atributos mensuráveis de modo que as empresas geralmente podem ser classificadas objetivamente em aspectos individuais de desempenho 93 Gerência da qualidade de software O desempenho é muitas vezes uma fonte de desentendimento entre clientes e fornecedores particularmente quando o que se entrega não está adequadamente definido dentro das especificações O desempenho de um produto muitas vezes influencia a rentabilidade ou a reputação da empresa Por isso muitos contratos ou especificações também incluem os danos rela cionados ao desempenho inadequado Alguns padrões de desempenho são baseados em preferências subjetivas mas as preferências no geral são tão universais que têm a força de um padrão objetivo GARVIN 2015 O desempenho do software pode estar associado por exemplo à existência de ferramentas que facilitam a navegação ou a um sistema operacional que permita a monitoração constante do hardware como memória rapidez do sistema e inexistência de bugs 5122 Recursos São as características adicionais que realçam o apelo do produto ou serviço ao usuário Pensamento semelhante pode ser aplicado às caracte rísticas que muitas vezes são um aspecto secundário do desempenho GARVIN 2015 Os recursos do software englobam todos os conjuntos de instruções que possibilitam o processamento de informações e portanto englobam progra mas e procedimentos Os programas podem ser compreendidos como um conjunto de ins truções que possibilitam ao computador realizar determinada tarefa Já os procedimentos são um conjunto de instruções usadas por usuários para a finalização de uma tarefa Como exemplos de recursos do software temse 2 softwares aplicativos são programas de computador criados para ajudar os usuários a desempenhar tarefas específicas 2 softwares de sistema programas de sistema operacional que con trolam e apoiam todas as operações de um sistema de computador 2 procedimentos todas as orientações que o usuário final utiliza para navegar no sistema operacional Qualidade e usabilidade de software 94 5123 Confiabilidade É a probabilidade de um produto não falhar em um período de tempo específico sendo um elementochave para os usuários que precisam dele Entre as medidas mais comuns de confiabilidade estão o tempo médio até a primeira falha o tempo médio entre falhas e a taxa de falha por unidade de tempo Como essas medidas exigem que o produto esteja em uso por um período especificado elas são mais relevantes para bens duráveis do que para produtos e serviços consumidos instantaneamente A confiabilidade normalmente se torna mais importante para os consumidores conforme o tempo de inatividade e a manutenção do produto se tornam mais caros GARVIN 2015 Dessa forma verificase que a confiabilidade do software não depende diretamente da disponibilidade do produto porém ela tem relação com o tempo decorrido até que o sistema operacional se torne indisponível sendo necessária a reparação dos defeitos Exemplo O sistema 1 apresenta falha uma vez por ano porém a cada falha leva dois dias para reiniciar enquanto o sistema 2 falha uma vez por mês mas a cada falha demora dois minutos para reiniciar Qual deles apresenta maior confiabilidade O sistema 1 é mais confiável ao usuário já o sistema 2 apresenta maior disponibilidade pois as falhas são corrigidas rapidamente 5124 Conformidade É a precisão com que o produto ou serviço atende aos padrões especifi cados A dimensão da conformidade descreve até que ponto o projeto de um produto e suas características operacionais atendem aos padrões estabelecidos e se tais características se devem mais a abordagens tradicionais do que a qua lidades pioneiras Quando os produtos são desenvolvidos suas especificações são definidas e um alvo por exemplo os materiais utilizados ou a dimensão do produto assim como uma tolerância o intervalo de desvio permitido do alvo são estabelecidos Um problema com essa abordagem é que há pouco interesse em saber se as especificações foram cumpridas exatamente como determi nado enquanto os limites de tolerância forem satisfeitos 95 Gerência da qualidade de software As medidas de conformidade normalmente se concentram na precisão e na oportunidade e incluem contagens de erros de processamento atrasos inesperados e outros erros frequentes GARVIN 2015 No caso dos softwares a conformidade verifica se ele foi desenvolvido de acordo com padrões normas procedimentos e guias de TI e se atendem aos requisitos do clienteusuário 5125 Durabilidade Mede a duração da vida de um produto Quando o produto pode ser reparado estimar sua durabilidade é mais complicado pois o item será usado até que não seja mais economicamente viável operálo Isso acontece quando a taxa de reparo e os custos associados aumentam significativamente Tecnicamente a durabilidade pode ser definida como a quantidade de uso que se obtém de um produto antes de ele se deteriorar GARVIN 2015 Em alguns casos os consumidores devem pesar o custo esperado de futuras reparações em reais e em transtornos pessoais contra o investimento e as des pesas operacionais com um modelo mais novo e mais confiável ou seja se uma substituição é preferível à continuação da reparação Essa abordagem da durabilidade tem duas implicações importantes Em primeiro lugar sugere que a durabilidade e a confiabilidade estão estreitamente ligadas Um produto que muitas vezes falha é susceptível de ser substituído ou retirado do mer cado mais cedo do que um que é mais confiável pois seus custos de reparo serão mais altos e a compra de uma marca concorrente parecerá muito mais desejável ao cliente Em segundo lugar implica que os dados de durabilidade devem ser interpretados com cuidado Um aumento na vida do produto pode não ser resultado de melhorias técnicas ou do uso de materiais mais duráveis mas em vez disso fruto de mudanças no ambiente econômico do qual ele faz parte GARVIN 2015 Em relação à durabilidade do software verificase que ela diz respeito ao tempo de duração de um software até ele se tornar desatualizado em relação ao conteúdo ou obsoleto Vale ressaltar que a durabilidade apesar de ser um conceito similar não é a mesma coisa que a confiabilidade A durabilidade por exemplo relacionase com a vida útil do software enquanto a confiabilidade Qualidade e usabilidade de software 96 relacionase com o período de tempo em que o produto não poderá apresentar defeitos por exemplo no período da garantia dada pelo fabricante 5126 Atendimento Essa dimensão diz respeito aos fatores do produto ou serviço que podem afetar a percepção do cliente O atendimento envolve questões como pontualidade e rapidez do ser viço eficiência presteza reatividade resolução de problemas pouco tempo de espera comunicação adequada entre outros aspectos implicados no con tato entre cliente e fornecedorempresa Como no caso dos softwares necessitase de atendimento para repa ros ou manutenção dos produtos essa dimensão de atendimento adequado influencia a visão do usuário final inclusive no que diz respeito à decisão sobre o uso futuro do software em questão 5127 Estética É a dimensão subjetiva que indica a impressão que o usuário tem em relação a um produto As propriedades estéticas de um produto contribuem para a identidade de uma empresa ou marca e falhas ou defeitos que o diminuem mesmo quando não reduzem ou alteram outras dimensões de qualidade são muitas vezes causa de rejeição Assim a estética referese a como o cliente vê e sente produto seus sons gostos ou cheiros ou seja é claramente uma questão de julgamento pessoal e um reflexo da preferência individual No entanto parece haver alguns padrões no ranking dos con sumidores de produtos com base em gostos Um estudo sobre a qualidade em 33 categorias de alimentos por exemplo descobriu que a alta qualidade era frequentemente associada a sabor rico e cheio sabores naturais e frescos bom aroma e aparência GARVIN 2015 No desenvolvimento do software a estética é um requisito que pode ser satisfeito com a adoção de prototipação da interface do aplicativo por meio da qual é possível verificar como será o software quando finalizado A reali zação de protótipos ajuda no desenvolvimento visual do produto que pode 97 Gerência da qualidade de software receber a opinião não somente de desenvolvedores mas também do cliente e de potenciais usuários 5128 Qualidade percebida É a qualidade atribuída a um bem ou serviço baseada em medidas indiretas A percepção nem sempre reflete a realidade pois os consumidores muitas vezes possuem informações incompletas sobre os atributos de um produtoserviço As medidas indiretas podem constituir a única base dos clientes para a comparação de marcas A durabilidade por exemplo rara mente pode ser observada diretamente pois é inferida por meio de vários aspectos tangíveis e intangíveis do produto Nessas circunstâncias imagens propagandas e nomes de marcas referências sobre a qualidade em vez da própria realidade podem ser críticos GARVIN 2015 Abordando a questão da qualidade do software ressaltase que ela é um conjunto de atributos que devem ser satisfeitos de modo que esse produto atenda às necessidades de todos os usuários o desenvolvedor o cliente o usuário final e todas as partes interessadas stakeholders 52 Planejamento e controle da qualidade do software O planejamento e o controle da qualidade do software surgem da neces sidade de se produzir um produto de alta qualidade e isso implica a garantia de proteção de software ao longo de todo o seu processo de engenharia O controle de qualidade abrange uma série de avaliações e testes utilizados para todo o ciclo de desenvolvimento de produto a fim de garantir que cada software atenda aos requisitos que lhe foram atribuídos Essa variedade de tare fas está associada a diferentes sujeitos os engenheiros de software que realizam o trabalho técnico e o grupo de SQA Software Quality Assurance responsável pela garantia de qualidade e planejamento WAZLAWICK 2013 Nesse contexto o planejamento e o controle formais representam um filtro para processos de engenharia de software pois eles são aplicados em Qualidade e usabilidade de software 98 vários estágios de desenvolvimento e usados para detectar defeitos que pos sam ser eliminados WAZLAWICK 2013 Esses processos envolvem a verificação da necessidade de melhorias no produto de software inclusive confirmando as partes dele em que não sejam necessárias ou desejáveis modificações adotandose um trabalho baseado em critérios de correção e integridade MARSHALL JR et al 2012 521 Detecção e controle de erros O principal objetivo das revisões técnicas formais é encontrar erros durante o processo de desenvolvimento do software impedindo que eles se propaguem em etapas posteriores e que se tornem defeitos após a entrega do produto Estudos indicam que as atividades de design2 introduzem entre 50 e 65 de todos os erros e finalmente todos os defeitos durante o desenvol vimento do software No entanto as inspeções dessas atividades são eficazes em 75 dos casos SOMMERVILLE 2011 Durante cada etapa de desenvolvimento pode haver problemas que pas sam despercebidos e a inspeção pode não conseguir descobrir os erros Em alguns casos erros não identificados a nas etapas iniciais são posteriormente amplificados SOMMERVILLE 2011 Para realizar inspeções de controle a equipe de desenvolvimento deve gastar tempo e esforço e a organização precisa gastar dinheiro Esses testes produzem um custobenefício demonstrável portanto se a empresa tem os recursos necessários eles devem ser realizados PRESSMAN MAXIM 2016 Para ilustrar o impacto sobre o custo de detecção de erros desde o início ou seja desde o planejamento do projeto considere uma série de custos rela tivos que se baseiam em dados recolhidos em grandes projetos de software com e sem a realização de processos de inspeção Tabelas 1 e 2 2 O design de software compreende a concepção especificação e prototipação da partes ex ternas e internas do software A parte externa compreende o modelo conceitual da aplicação e a interface de usuário A parte interna compreende a arquitetura de componentes de software e os algoritmos e estruturas de dados que implementam estes componentes LEITE 2000 99 Gerência da qualidade de software Tabela 1 Com realização de inspeçõescontrole Erros encontrados Quantidade Custo unitário Total Durante o projeto 22 15 33 Antes do teste 36 65 234 Durante o teste 15 150 315 Após o teste 3 670 201 Total 783 Fonte CYBIS et al 2015 Adaptado Tabela 2 Sem realização de inspeçõescontrole Erros encontrados Quantidade Custo unitário Total Antes do teste 22 65 143 Durante o teste 82 150 1230 Após o teste 12 670 804 Total 2177 Fonte CYBIS et al 2015 Adaptado Do exposto podese resumir que os benefícios obtidos por meio da apli cação de inspeções PRESSMAN MAXIM 2016 envolvem a redução de defeitos no software e da quantidade de recursos de desenvolvimento espe cialmente nas fases de codificação e teste assim como uma redução dos custos de manutenção corretiva Um processo de inspeção adequado consiste de seis passos CYBIS 2015 1 Planejamento Quando o desenvolvedor conclui um produto de trabalho uma equipe de inspeção é formada e um moderador é designado O moderador assegura que o produto de trabalho satis faça os critérios de inspeção Ele atribui papéis diferentes para os membros da equipe de inspeção bem como estabelece o tempo de planejamento e os recursos Qualidade e usabilidade de software 100 2 Resumo Se os inspetores não estão familiarizados com o pro jeto de desenvolvimento é necessário dar a eles uma visão geral do processo Esse é um passo opcional mas não menos importante porque nessa fase será dado aos inspetores o contexto a ser coberto por meio das inspeções 3 Preparação Os inspetores são preparados individualmente para avaliação na reunião estudando os produtos de trabalho e mate riais relacionados Nessa fase é aconselhável a utilização de listas de verificação para ajudar a encontrar defeitos comuns 4 Comentário Nessa fase os inspetores se reúnem para discuti rem juntos cada trabalho individual O moderador deve assegurar que todos estejam suficientemente preparados A pessoa designada como leitor apresenta o produto do trabalho interpretandoo enquanto cada participante se atenta para possíveis defeitos Após a conclusão da reunião o grupo determina se o produto será aceito ou se deve ser reformulado para inspeção posterior 5 Retrabalho O desenvolvedor corrige todos os defeitos encontra dos pelos inspetores 6 Followup acompanhamento O moderador verifica as correções feitas pelo desenvolvedor Se o moderador está satisfeito a inspeção é formalmente completa e o produto de trabalho é colocado sob controle de configuração Para cumprir essas seis etapas surge a necessidade do estabelecimento dos objetivos da inspeção dos participantes e de que papéis eles terão dos produtos de trabalho a serem inspecionados e do que deve ser o resultado das reuniões de inspeção CYBIS et al 2015 2 Objetivos O objetivo principal é encontrar defeitos no produto de trabalho e para isso é preciso definir quais serão as metas a serem alcançadas O estabelecimento dessas metas está diretamente relacionado com o tipo de projeto as metodologias e os instrumen tos utilizados 101 Gerência da qualidade de software 2 Grupos de inspeção É recomendado que se formem grupos de três a seis indivíduos IEEE 1997 incluindo neles o autordesen volvedor dos produtos de trabalho 2 Funções Além do autor devem ser definidos o moderador que liderará a inspeção e que deve ter mais experiência do que o resto do grupo o leitor que apresenta os produtos de trabalho nas reu niões e o escriba que documenta a descrição e a localização dos defeitos encontrados 2 Os produtos funcionam O processo de inspeção pode ser apli cado a diferentes tipos de produtos de trabalho encontrados em um desenvolvimento de software incluindo requisitos projeto código testes guia de usuário e outras documentações O padrão IEEE Práticas Recomendadas para Especificação de Requisitos de Software IEEE 1998 não especifica um tamanho mas os produtos de trabalho têm normalmente 10 a 20 folhas de especi ficação de requisitos com 200 ou 250 linhas de código cada 2 Resultado de reuniões de inspeção Os dois principais resultados devem ser a lista de defeitos a serem corrigidos e um relatório de inspeção que descreve o que foi inspecionado quem inspecionou e o número de defeitos encontrados Assim verificase que um dos maiores benefícios da realização de ins peções de software é a possibilidade de solucionar erros o quanto antes com esforço reduzido e custos menores à empresa 53 Gerência dos testes de software Alterações durante o desenvolvimento de software são inevitáveis por isso é preciso garantir que esse processo não seja desordenado A área da engenharia de software que trata desse assunto é a gerência de testes do software PRESSMAN MAXIM 2016 que pode ser entendida como um conjunto de atividades de apoio que permite a absorção ordenada Qualidade e usabilidade de software 102 das mudanças inerentes ao desenvolvimento de software mantendo a integri dade e a estabilidade durante a evolução do projeto ARANTES FIDELIS AZEVEDO 2017 p 1 As atividades da gestão de testes de software envolvem CYBIS et al 2015 2 controlar e acompanhar mudanças controle de mudança 2 registrar a evolução do projeto controle de versão 2 estabelecer a integridade do sistema integração contínua O controle de mudanças acontece ao longo de todo o processo de desen volvimento do software As alterações devem ser registradas avaliadas e elen cadas conforme sua prioridade Isso permite o acompanhamento do escopo dos prazos e dos custos de cada etapa No controle de versão sempre que ocorrer uma solicitação de mudança há um acréscimo na evolução do projeto que deve ser registrado no histórico de desenvolvimento O registro de controle de versões assegura cada etapa do desenvolvimento de software pois possibilita a edição paralela dos arquivos e a criação de diferentes versões é muito importante para a gestão e o controle do produto A integração contínua de um sistema tem como principal objetivo a verificação da composição do sistema ou seja se seus itens de registro estão consistentes A integração acompanha o controle de versão e dispara scripts que automatizam a construção os testes e a coleta de métricas de qualidade Pressman e Maxim 2016 citam que a gerência dos testes faz parte da gestão de configuração e que elas estão relacionadas com as demais áreas da engenharia de software assim esses processos são requisitos de implemen tação em diversos modelos de níveis de maturidade de desenvolvimento de software Verificase desse modo que a realização de testes está relacionada à gestão de projeto à garantia da qualidade de software e à gerência de configuração Ainda de acordo com os mesmos autores PRESSMAN MAXIM 2016 as solicitações de mudanças de desenvolvimento de software são regis tradas e controladas sob responsabilidade do desenvolvedor que registra a 103 Gerência da qualidade de software solicitação seus resultados dispara a execução dos testes e realiza a coleta das métricas de qualidade do sistema como um todo e de cada código criado Os resultados devem ser apresentados para a equipe de desenvolvimento com base nos quais são então realizadas as alterações as correções e os ajustes necessários criando assim uma nova versão e seu respectivo registro 531 Tipos de testes Existem ferramentas de software que auxiliam nos gerenciamentos dos testes a serem realizados permitindo o acompanhamento e o controle de casos e atividades específicas Dependendo da necessidade podem ser aplica dos diferentes tipos de testes como descrito a seguir 2 Teste de funcionalidade nele são avaliados campos navegação entre as telas botões links interface e funcionalidade geral do sis tema Os requisitos iniciais solicitados pelo cliente devem ser testa dos e aprovados nesse teste 2 Teste de desempenho é avaliado o desempenho do sistema se ele está atendendo aos requisitos preestabelecidos e o tempo que cada aplicação demora para dar respostas a determinada ação 2 Teste unitário são avaliadas pequenas unidades de software uma parte do código construído como as rotinas com o objetivo de verificar funções diferentes dentro do sistema 2 Teste de bugs é avaliada a existência de bugs erros de programa ção e funcionamento do sistema erros de construção de código ou da própria aplicação 2 Teste de integração nele são avaliados vários componentes do software combinados e testados em grupo 2 Teste operacional nele é verificado se a aplicação responde ao tempo de execução do sistema 2 Teste de regressão é realizado logo após a alteração de um código e assim toda a aplicação deve ser testada novamente 2 Teste de caixa branca todas as entradas e saídas desejadas do sistema são testadas e é observado o resultado esperado Qualidade e usabilidade de software 104 2 Teste de configuração nele se avalia se a aplicação funciona cor retamente em diferentes configurações de hardware e software 2 Teste de interface é avaliada a navegabilidade e se cada compo nente responde conforme especificado pelo usuário 2 Teste de carga teste em que se avalia o funcionamento da apli cação com simulação de entrada de dados simultâneos em grande quantidade verificandose a resposta do sistema 2 Teste de aprovação do usuário nele o usuário realiza os testes operacionais e se sua aplicação é funcional 2 Teste de estresse caminhos diferentes de uso são avaliados ten tando simular um erro ou uma ação inesperada submetendo o software a situações extremas Nesse contexto de avaliação dos softwares o desenvolvimento de pro jetos de qualidade deve envolver profissionais devidamente preparados Os engenheiros devem entender o raciocínio por trás de cada padrão e as nor mas devem ser revistas regularmente para se evitar problemas de obsolescên cia e credibilidade O gerenciamento da qualidade do software funciona melhor quando se cria uma cultura de qualidade nas organizações ou seja quando a quali dade é vista como responsabilidade de todos Ampliando seus conhecimentos O texto a seguir procura desmistificar a ideia equivocada que muitos programadores têm sobre os testes de software além de defender a existência de uma equipe de qualidade que não participou do desenvolvimento do software para poder avaliálo de forma objetiva 105 Gerência da qualidade de software Definindo qualidade de software BARTIÉ 2002 p 2021 Definição comum de testes De forma geral todas as equipes de desenvolvimento aplicam testes em seus softwares independentemente se os testes são bem planejados bem estruturados e de como são executa dos O fato é que esses testes não são suficientes para detec tar os erros que estão inseridos dentro de uma aplicação Um dos motivos básicos para que isso ocorra é na forma com que esses profissionais encaram os testes de software Todos enxergam os testes como uma forma de provar que tudo está bem e funcionando conforme o estabelecido Todas as definições difundidas sobre testes dão uma dimen são positiva sobre o problema ou seja o entendimento sobre testes é sempre colocado sob o prisma de avaliar se tudo está funcionando adequadamente O fato é que é mais fácil provar que algo funciona do que provar que algo não fun ciona o que significa que teremos um menor esforço em provar o funcionamento de um software do que o contrário E é exatamente isso que sentimos quando colocamos uma equipe independente de qualidade para avaliar determinado projeto de software como essa equipe não está envolvida emocionalmente nem politicamente com o projeto terá um comportamento muito mais objetivo e direto indo exatamente aos pontos que inicialmente o projeto deveria atender e por motivos desconhecidos foram abandonados ou não atendi dos corretamente Qualidade e usabilidade de software 106 A definição correta sobre testes Entender que o objetivo dos testes é provar que algo não funciona é um avanço significativo na compreensão de um processo de qualidade de software Não adianta termos documentações incompletas imprecisas e ambíguas É neces sário buscar um maior nível de qualidade em todos os produ tos sejam documentos ou softwares produzidos em todas as fases do ciclo de desenvolvimento Esses documentos auxiliarão as equipes a tomarem decisões mais corretas sobre o projeto de software que refletirá em um produto com maior conformidade com as necessidades dos clientes e usuários Portanto os testes em documentos deverão não somente analisar se as definições foram registradas mas se estas foram escritas de forma a não dar margens a dúvidas e se estão em conformidade com as demais Se o documento registra deci sões que foram analisadas devemos avaliar se tais decisões estão apoiadas em informações e análises objetivas e não por dados infundados ou meras suposições Atividades 1 Cite as dimensões que avaliam a qualidade no desenvolvimento de produtos e serviços 2 O que é controle de qualidade de software 3 Quais são as atividades da gestão de testes de software 4 Explique a importância de a gerência de qualidade ser independente da gestão do projeto Fundamentos da interação homemcomputador IHC Introdução A adaptação às novas ferramentas tecnológicas é complexa Para alguns indivíduos ela acontece rapidamente outros no entanto devido à heterogeneidade cultural social econômica e cognitiva têm mais dificuldades para se adequar aos novos proces sos tecnológicos Este capítulo busca uma reflexão sobre os proces sos que envolvem a relação entre o homem e o computador 6 Qualidade e Usabilidade de Software 108 De modo geral a IHC estuda as trocas de informações por meio de software entre pessoas e computadores relacionando tudo que estiver envolvido na interação entre usuários e computadores seja aspectos físicos psicológicos práticas de trabalho relações sociais saúde etc ANDRADE 2007 p 36 Essa disciplina é responsável pela concepção avaliação e implementação de dispositivos de tecnologia interativa O objetivo de se estudar essas interações emerge da necessidade de que elas sejam mais eficientes a fim de minimizar erros aumentar a satisfação do usuário reduzindo eventuais frustrações e finalmente tornar mais produti vas as tarefas que envolvem pessoas e computadores Embora a pesquisa nesse campo ainda seja muito recente a recompensa alcançada é gratificante Assim é importante que os sistemas de informa ção sejam eficazes eficientes simples e agradáveis e muito cuidado deve ser tomado na elaboração dos softwares porque quanto mais os sistemas forem agradáveis maior será a possibilidade de o usuário conseguir explorar todos os comandos de um software 61 Abordagens técnicas da IHC A relação entre os seres humanos e os computadores é uma área de inves tigação multidisciplinar e o termo mais genérico para se referir a ela é interação humanocomputador IHC que engloba as interfaces dos usuários num sistema de fabricação ou controle de desenvolvimento de softwares WEBER 2012 Em outras palavras a IHC investiga e aborda todos os aspectos rela cionados à concepção e à implementação de interfaces entre seres humanos e computadores Dada a sua natureza e seus objetivos a IHC envolve várias disciplinas das ciências de computação como processamento de imagem visão computacional linguagens de programação e similares bem como 109 Fundamentos da interação homemcomputador IHC disciplinas relacionadas às ciências humanas ergonomia psicologia cogni tiva filosofia etc como explícito na Figura 1 Figura 1 Disciplinas relacionadas à IHC Ergonomia Psicologia social e organizacional Psicologia cognitiva Ciência da computação Inteligência artificial Linguística Filosofia Sociologia Engenharia Design Antropologia IHC Fonte PREECE 1997 apud ANDRADE 2007 p 36 A palavra interação se refere a uma ação que pode ser realizada formal ou informalmente e portanto nela são executados processos de troca em um sentido amplo WEBER 2012 Nas relações entre homens e máquinas Qualidade e Usabilidade de Software 110 propostas pela IHC entendese que elas estão ligadas a processos internos automáticos do ser humano como o processamento de rotina de informa ções Desse modo as máquinas seriam algoritmos que buscam melhorar o desempenho do indivíduo e aumentar sua inteligência assim como os seus níveis de consciência WEBER 2012 O desenho e a especificação de interfaces para melhorar a relação huma nomáquina pode incluir diferentes aspectos como uma melhor interface para utilização de dispositivos móveis Figura 2 Figura 2 Relação homemcomputador Fonte grinvaldsiStockphoto 611 Evolução da IHC Estudos sobre IHC remontam ao ano de 1963 quando Ivan Sutherland criou um sistema para manipular objetos gráficos utilizando uma caneta que 111 Fundamentos da interação homemcomputador IHC permitia pegar objetos mover e redimensionálos No mesmo ano Elgerbart projetou o primeiro mouse Em 1968 o MIT Lincoln Labs criou um modelo para interfaces incluindo janelas menus ícones botões etc Foi o prelúdio para as interfaces que hoje conhecemos como as utilizadas na manipulação direta de dispositivos No início da ciência da computação designers e desenvolvedores presta vam muito menos atenção para o problema de tornar os produtos de hardware e software usáveis até porque as interfaces continham apenas texto No entanto com o advento das interfaces gráficas começou a haver a necessidade de estudos de IHC e pedidos provenientes de um conjunto crescente de usuários para um melhor uso de dispositivos chamou atenção dos pesquisadores que passaram a estudálo sob o nome de usabilidade WEBER 2012 Muitas organizações passaram a encomendar softwares que auxiliassem os usuários a serem mais produtivos o que exigiu também muitos estudos de ergonomia1 uma área que interfere na usabilidade pois busca o bemestar e a saúde do usuário A ergonomia não se limita apenas aos móveis e ao ambiente de trabalho mas também diz respeito à forma como o usuário interage com o computador Nesse sentido até o número de clics que o usuário precisa dar até chegar a seu objetivo quando usa um aplicativo computacional é avaliado pela ergonomia Outro conceito importante associado à IHC a partir da década de 1990 foi o de user experience ou experiência do usuário EU centrado principal mente nos parâmetros relacionados à satisfação dos usuários Nos últimos anos o EU tem sido ampliado e mais bem definido em algumas áreas de pesquisa Peter Moville conhecido como um dos pais da arquitetura da informa ção de websites criou um diagrama para ilustrar as facetas da experiência do usuário no formato de uma colmeia que ficou conhecida como The User Experience Honeycomb colmeia da experiência do usuário representada na figura a seguir 1 Ciência que estuda a adequação do trabalho às características do ser humano de modo a conferir efetividade nas atividades laborais e de lazer desenvolvidas pelo homem preservando a sua saúde física e mental e dandolhe satisfação ao executálas SHNEIDER 2017 Qualidade e Usabilidade de Software 112 Figura 3 Experiência do usuário honeycomb Utilidade Valor Usabilidade Encontrabilidade Credibilidade Acessibilidade Desejo Fonte MORVILLE apud MATTHEWS 2009 p 85 A figura da colmeia deixa claro que é preciso pensar a experiência do usuário além da usabilidade que é apenas uma das facetas do diagrama Segundo Benyon 2011 as sete células do favo de mel representam os parâmetros que devem ser cuidadosamente equilibrados para fornecer aos usuários uma experiência de qualidade satisfatória garantindo que a interface seja útil usável desejável encontrável acessível confiável e valiosa Muitos designers de interface web conduzem estudos honeycomb para identificar prioridades na fase de projeto procurando refletir sobre todas as facetas do diagrama honeycomb de modo a ter uma visão mais ampla de requisitos para satisfazer o usuário do software Matthews 2009 p 85 explica cada um dos favos da colmeia 2 Utilidade é importante ver o produto do ponto de vista do cliente usuário buscando verificar a real necessidade dele e se o software atende a essa necessidade As perguntas que devem ser feitas são 113 Fundamentos da interação homemcomputador IHC Esse software vai ser útil ao meu cliente Ele atende às suas necessi dades Para que ele serve Quais são as suas funções A partir desse questionamento é mais claro entender o que é realmente impor tante contemplar no software em termos de funcionalidade 2 Usabilidade A facilidade de uso é essencial porém uma interface focada apenas na boa interação homemcomputador não atende a todas as necessidades do usuário Ou seja a usabilidade é necessá ria mas não suficiente A pergunta que deve ser feita é O usuário consegue entender o que deve ser feito sem nenhuma explicação Ou A navegação é intuitiva 2 Desejo A sensação de conforto e bemestar é grandemente influenciada pelas cores e pela estética do software como um todo O usuário precisa sentirse bem ao interagir com ele por isso é importante cuidar da organização visual do software buscando trabalhar em conjunto com webdesigners para que a experiência do usuário seja gratificante As perguntas a se fazer são O usuário vai gostar da aparência do software Ele vai ter vontade de navegar novamente nele Vai ser uma experiência gratificante 2 Encontrabilidade Os conteúdos devem ser facilmente localizá veis para que o usuário encontre rapidamente o que precisa As perguntas que devem ser feitas são O usuário consegue encontrar as informações que precisa rapidamente As informações estão visí veis de modo que ele não precise ficar procurando por elas 2 Acessibilidade Assim como os edifícios e calçadas são pensados para atender pessoas com deficiência mais de 10 da população os sites e softwares também devem ter essa preocupação apresen tando soluções que ampliem a acessibilidade das pessoas com defi ciência além de crianças e idosos As perguntas que devem ser feitas são Que ferramentas são necessárias para auxiliar uma pessoa com deficiência visual auditiva motora etc a utilizar esse software No caso de crianças ou idosos que adaptações são necessárias ao software para que esses públicos possam utilizálo adequadamente 2 Credibilidade Um dos pontos fortes do software é a reputação de ser confiável Isso significa que ele deve funcionar perfeitamente Qualidade e Usabilidade de Software 114 sem travar ou dar mensagens de erro A pergunta que deve ser feita é O usuário pode confiar nesse software 2 Valor O software deve dar um retorno real ao clienteusuário Deve ser uma experiência marcante que traga soluções e faça efeti vamente a diferença A pergunta a ser feita é Esse software satisfaz as necessidades do usuário contribuindo para sua experiência As facetas da experiência do usuário servem a vários propósitos funcio nando como uma ferramenta que ajuda a pensar além da usabilidade e dos limites convencionais Ao perceber como todas essas facetas se integram de forma harmoniosa é fácil concluir que uma simples mudança no layout não é suficiente para solucionar os problemas de um sistema ou um software 612 Os modelos mentais e a IHC O conhecimento sobre modelos mentais humanos área de estudo da engenharia semiótica é outro aspecto importante da IHC As pessoas racioci nam com modelos mentais os quais podem ser compreendidos como blocos de construção cognitivos que são combinados e recombinados conforme a necessidade Como quaisquer outros modelos eles representam o objeto ou a situação em si uma de suas características mais importantes é que sua estru tura capta a essência se parece analogicamente dessa situação ou objeto HAMPSON MORRIS 1996 p 243 Assim um modelo mental pode ser entendido como uma representação interna de informações que corresponde de forma análoga a uma representação do mundo real ou que está o mais próximo possível do mundo real Usuários de tecnologia digital aprendem e mantêm o conhecimento e as habilidades de diferentes formas muitas vezes influenciados por sua idade bem como por fatores de seu contexto cultural e social Assim estudos da engenharia semiótica apontam para uma lacuna entre os usuários e as novas tecnologias que agora surgem muito mais rapidamente do que no passado Isso ocorre porque muitas vezes os desenvolvedores e os usuários têm uma visão distinta da aplicação ou seja os desenvolvedores veem o software por dentro visão obtida a partir de linguagens de programação que descrevem 115 Fundamentos da interação homemcomputador IHC o funcionamento do sistema enquanto os usuários têm uma visão externa da interface de usuário Por isso é importante inserir no desenvolvimento do software a atividade de design de modo que desenvolvedores e usuários possam compartilhar a mesma visão do produto As formas naturais eficientes e eficazes da IHC podem reduzir o nível das habilidades necessárias para utilizar dispositivos complexos Uma interface natural intuitiva eficiente robusta e configurável pode diminuir significati vamente a distância entre os modelos mentais e os computadores e máquinas WEBER 2012 Assim é possível minimizar as potenciais desigualdades entre as pessoas para ajudálas a resolver um problema como o fosso digital o abismo exis tente entre os indivíduos que têm acesso às tecnologias digitais tecnologias da informação e comunicação TICs e possuem as habilidades necessárias para utilizálas e aqueles que não têm acesso a elas ou não possuem tais com petências WEBER 2012 613 Componentes básicos do sistema de IHC Segundo Weber 2012 os componentes básicos do sistema de IHC são usuário computador diálogos objetos de interação e sistemas de significados 6131 Usuário O ser humano tem uma capacidade limitada para processar informações WEBER 2012 e saber disso é muito importante na elaboração do design de um software A comunicação humana se dá por meio de quatro canais de entrada saída visão audição tato e movimento WEBER 2012 A informação que uma pessoa recebe é armazenada na memória sensorial na memória de curto prazo e na memória de longo prazo Assim que recebida ela é proces sada racionalmente pelo indivíduo e decodificada em função das habilidades adquiridas por este como por exemplo ser capaz de resolver problemas ou erros Por isso mesmo um fato a ser destacado é que todos os usuários terão Qualidade e Usabilidade de Software 116 habilidades em comum mas haverá outras que irão variar de indivíduo para indivíduo WEBER 2012 6132 Computador Os dispositivos computacionais utilizados podem afetar de diferentes maneiras o usuário Os dispositivos permitem a inserção de texto como no caso do teclado do computador do tablet e do smartphone seja um discurso oral ou um manuscrito de desenho seleções na tela com o mouse ou as mãos etc Sistemas de realidade virtual e visualização em 3D desempenham um papel muito importante na interatividade homemcomputador E esse recurso tende a ser cada vez mais utilizado como mostra a Figura 4 Figura 4 Realidade virtual e visualização em 3D Fonte aurielakiiStockphoto O processo de IHC se baseia no hardware e no software que juntos fazem o diálogo entre o sistema e o usuário compondo a interface Segundo Souza et al 1999 O termo interface é aplicado normalmente àquilo que interliga dois sistemas Tradicionalmente considerase que uma interface 117 Fundamentos da interação homemcomputador IHC homemmáquina é a parte de um artefato que permite a um usuário controlar e avaliar o funcionamento deste artefato através de dispo sitivos sensíveis às suas ações e capazes de estimular sua percepção No processo de interação usuáriosistema a interface é o combinado de software e hardware necessário para viabilizar e facilitar os pro cessos de comunicação entre o usuário e aplicação A interface entre usuários e sistemas computacionais diferenciase das interfaces de máquinas convencionais por exigir dos usuários um maior esforço cognitivo em atividades de interpretação e expressão das informa ções que o sistema processa Grande parte da investigação da IHC visa melhorar a usabilidade e as outras facetas da experiência do usuário concentrandose principalmente em BENYON 2011 2 métodos para a concepção de novas interfaces de computador e oti mização do desenho das propriedades desejadas pelo usuário final como a capacidade de aprendizagem ou a eficiência de utilização 2 métodos para avaliar e comparar as interfaces no que diz respeito a suas propriedades por exemplo sua capacidade de uso 2 métodos para estudar o uso de computadores e suas implicações socioculturais 2 perspectivas para reflexão crítica sobre os valores do design com putacional do uso do computador e da pesquisa de interação humanocomputador 6133 Diálogos São as sequências que ocorrem entre o sistema e o homem Os diálo gos estão associados às formas com que os objetivos práticos dos usuários se efetivam nas interações com o sistema Um componente básico do diálogo é a ação que pode ser entendida como uma interação elementar em que a entrada significativa do usuário deverá ser acompanhada de feedback do sis tema NIELSEN 2000 6134 Objetos de interação São objetos de software que geram imagens que devem ser apresentadas ao usuário com o qual haverá uma interação Esses objetos devem ter ligação Qualidade e Usabilidade de Software 118 com as interfaces bem como com o ambiente incluindo o primeiro plano o pano de fundo e as bordas NIELSEN 2000 Alguns objetos de interação são 2 janelas 2 caixas de diálogo 2 botões 2 barras de rolagem 2 menus 2 caixas de mensagem etc A figura a seguir demonstra a disposição desses objetos em uma interface Figura 5 Objetos de interação Botões Janela Caixa de mensagem Barra de rolagem Fonte IESDE BRASIL SA A Figura 6 traz exemplos de popups janelas que abrem no navegador quando uma página é acessada Geralmente traz publicidade anúncios ou mensagens de redirecionamento de links 119 Fundamentos da interação homemcomputador IHC Figura 6 Exemplos de popups Fonte GalIstvaniStockphoto 6135 Sistemas de significados A semiótica é uma ciência que estuda os signos e seus processos de sig nificação e comunicação Já signo é aquilo que sob certo aspecto ou modo representa algo para alguém PEIRCE 2005 p 46 ou seja o signo substi tui uma coisa por outra coisa produzindo um efeito interpretativo O signo é o mediador entre o objeto e o interpretante Segundo Peirce o signo é produto de três elementos 2 a expressão aquilo que ele representa 2 o objeto aquilo que é representado 2 o interpretante a capacidade mental empregada no contexto de processo do signo A engenharia semiótica estuda a relação do design e da interação no processo comunicativo entre o designer emissor da mensagem e o usuá rio receptor Esse processo comunicativo entre designer e usuário faz parte Qualidade e Usabilidade de Software 120 do processo de design A engenharia semiótica está presente no processo de design quando o designer busca adequar a mensagem por meio de signos que o usuário compreenda ou seja ele precisa traduzir a linguagem de programação em signos que fazem sentido para o usuário Contudo não há garantias de que o usuário vai interpretar os signos da mesma forma que o designer Por exemplo um usuário experiente sabe que o ícone abaixo Figura 7 significa salvar O disquete é o objeto representado já a ideia de salvar é a expressão aquilo que ele representa e o interpretante é a capacidade mental que o usuário emprega para processar o objeto em signo Figura 7 Ícone salvar Fonte PanptysiStockphoto O disquete foi usado como disco de armazenamento de informações até o ano 2000 depois disso seu uso foi abandonado Pela sua função acabou se tornando o ícone de vários aplicativos para a função salvar Contudo para um jovem que nunca teve contato com um disquete na vida esse ícone não lhe diz absolutamente nada por si só O jovem precisa aprender o significado desse ícone que se tornou cultural Portanto não é possível prever o modo como todos os usuários vão interpretar um signo mas o designer deve refletir sobre o modo como sua mensagem pode ser interpretada a fim de escolher a forma mais adequada de transmitila2 2 O ícone mantém uma estreita relação com o objeto que ele representa como o ícone salvar porque ele representa um disquete cuja função era de salvar arquivos Já o símbolo não tem uma relação direta com o objeto representado Por exemplo uma pomba é o símbolo da paz 121 Fundamentos da interação homemcomputador IHC 614 Interface cérebrocomputador A interface cérebrocomputador ICC é um caminho comunicativo direto entre o cérebro e um dispositivo externo como se o dispositivo lesse as informações que estão na mente do usuário O termo mente diz respeito à intenção do participante na pesquisa de IHC visto que suas ondas neuroelé tricas são gravadas por um eletroencefalograma EEG ligado por meio de eletrodos colocados sobre sua cabeça WEBER 2012 Segundo Rogers et al 2013 o dispositivo capta alterações no funcio namento do cérebro Os neurônios tornamse ativos toda vez que pensamos falamos nos movemos etc emitindo sinais elétricos que são detectados pelos eletrodos colocados no couro cabeludo ou embutidos em fones de ouvido toucas ou bonés especiais É desse modo que uma pessoa pode dominar um computador ou qual quer máquina sem usar as mãos ou qualquer outro meio ou seja sem o uso de qualquer músculo ou nervo do próprio corpo Essa tecnologia pode aju dar pessoas com deficiência visual ou auditiva a voltar a enxergar ou a ouvir e pessoas com deficiência física a mover uma prótese mecânica por exemplo Também tem sido usada em jogos como o Brainball em que os jogadores controlam com as ondas cerebrais o movimento de uma bola sobre uma mesa podendo manterse mais concentrados e relaxados Outro emprego dessa tecnologia é no controle de robôs e na possibilidade de se pilotar um avião virtual apenas pelo pensamento ROGERS et al 2013 p 204 62 Interação das atividades de IHC com a engenharia de software Desde 1960 quando o conceito de interatividade homemcomputador surgiu numerosas metodologias de design de software têm sido desenvolvi das A maioria delas é baseada no fato de que os designers têm de capturar a interatividade entre o usuário e o sistema técnico Nesse processo de criação é preciso considerar o processo cognitivo do usuário Nesse aspecto a engenha ria de software conta com o auxílio da engenharia cognitiva que se baseia na psicologia cognitiva e na ciência cognitiva para entender como o ser humano constrói o conhecimento A engenharia cognitiva estuda as limitações da Qualidade e Usabilidade de Software 122 mente e a sua capacidade para criar sistemas interativos que sejam fáceis de usar e agradáveis Assim os modelos teóricos mais recentes focam em um feedback na comuni cação entre os usuários os designers e os engenheiros de software Para otimizar a interação das atividades de IHC no desenvolvimento do software recomendase a adoção de WEBER 2012 2 Teoria da atividade É usada para definir o contexto no qual a interação entre pessoas e computadores ocorre Essa teoria con sidera que as ferramentas tecnológicas servem de instrumentos mediadores entre as pessoas e o mundo partindo do conceito de mediação proposto por Vygotsky Afinal as pessoas agem como sujeitos do mundo por meio da tecnologia A teoria da atividade procura compreender como se dá a interação entre o usuário e a tecnologia fornecendo informações aos desenvolvedores para pro jetar o design de interação 2 Design centrado no usuário Sua filosofia é a ideia de que o usuá rio é o centro do projeto em qualquer sistema de computador Usuários designers e equipe técnica trabalham em conjunto com o objetivo de articular o que é desejado assim é necessário conhe cer as limitações dos usuários para se criar um sistema adequado Essa metodologia é semelhante à concepção de participação a qual enfatiza a possibilidade de que os usuários finais devem contribuir para a criação do sistema 2 Princípios de design de interface Devese considerar em todos os momentos ao se projetar a interface para o usuário 2 a simplicidade deve ser de fácil utilização 2 a visibilidade deve ser visível para facilitar a usabilidade 2 a viabilidade deve ter design projetado com orçamento adequado 2 a coerência deve ser feito em conformidade com o requerido pelos usuários 2 a estrutura deve ter uma estrutura que permita a navegabilidade 123 Fundamentos da interação homemcomputador IHC 2 e o feedback deve possibilitar o contato entre usuários e desenvolvedor 63 O computador o homem e os limites do sistema A interação homemcomputador ocorre por uma alternância de controle da situação ora pelo usuário ora pelo computador em três fases lerexami nar pensar e responder como demonstra a Figura 8 Os softwares devem ser desenvolvidos de forma a facilitar essa interação entre o homem e a máquina MAYHEW 1992 Figura 8 O computador o homem e os limites do sistema HOMEM Pensar Processamento de input de acordo com os algoritmos Responder Resposta do computador envia da ao usuário Lerexaminar Reconhecimento e interpretação da informação apresentada pelo computador Pensar Tomada de deci sões o que fazer com a resposta recebida do computador Responder Ação do usuário gerando input para o computador Lerexaminar Reconhecimento e interpreta ção dos inputs do usuário Domínio do controle do computador Domínio do controle do homem COMPUTADOR I N T E R F A C E Fonte MAYHEW 1992 É possível perceber na Figura 8 que a interface faz a intermediação entre o homem e o computador O modelo de Mayhew se baseia na teoria da Qualidade e Usabilidade de Software 124 atividade ou teoria da ação apresentando um sistema interativo composto pelo homem pelo computador e pelos limites do sistema As fases lerexa minar pensar e responder são cíclicas e interligam as ações do usuário às reações do computador e viceversa A engenharia cognitiva foca nessas ques tões procurando auxiliar o designer a entender como o usuário constrói o conhecimento de modo a criar interfaces que sejam adequadas ao seu perfil e ao ambiente de uso facilitando ainda mais o aprendizado Uma das causas de problemas na interação homemcomputador é que os desenvolvedores muitas vezes não levam em conta que o software desen volvido não é um produto independente ao contrário pois pertence a um sistema maior que terá diferentes tipos de usuários e fará parte de vários subsistemas MAYHEW 1992 Mayhew 1992 alerta que qualquer sistema novo que utilize a IHC deveria iniciar com a definição de um sistema interativo assim decisões sobre usabilidade e funcionabilidade deveriam partir da compreensão clara dos objetivos da organização do usuário e do trabalho Isso também engloba a compreensão das limitações humanas para a realização do processamento das informações bem como o perfil a habilidade e o conhecimento especí fico dos usuários Nesse modelo os computadores são pensados para suprir as dificuldades do usuário de modo que a interação seja o mais simples possível devido ao esforço da engenharia cognitiva Esses conhecimentos auxiliam o designer a criar modelos mentais adequados ao sistema que sejam mais pró ximos das expectativas dos usuários Ampliando seus conhecimentos O texto a seguir explica de que modo a interação homem computador envolve outras áreas do conhecimento e se beneficia dessas áreas para melhorar a experiência do usuário com as novas tecnologias 125 Fundamentos da interação homemcomputador IHC IHC como área multidisciplinar BARBOSA 2011 p 12 IHC se beneficia de conhecimento e métodos de outras áreas fora da computação para conhecer melhor os fenô menos envolvidos no uso de sistemas computacionais inte rativos Áreas como Psicologia Sociologia e Antropologia contribuem para aquisição de conhecimento sobre a cultura e o discurso dos usuários e sobre seus comportamentos no ambiente onde realizam suas atividades sejam elas individuais ou em grupo A definição da interface com usuário faz uso de conhecimentos e técnicas de áreas como Design Ergonomia Linguística e Semiótica Alguns conhecimentos e técnicas importados de outras áreas além da computação são adaptados às necessidades de IHC Por exemplo a Psicologia utiliza extensamente entrevistas para ter acesso às concepções emoções e subjetividade das pessoas Isso é muito mais profundo e complexo que a utilização mais frequente de entrevistas em IHC através das quais normalmente investigamos a compreensão sobre um domínio opiniões sobre certos sistemas interativos e o que ocorreu durante uma experiência de uso para avaliação da interface com usuário Algumas técnicas de apresentação de conteúdos estáticos como as utilizadas em jornais revistas e livros foram adaptadas em IHC para lidar com a dinâmica da interface bem como conteúdos hipermídias A área de IHC articula uma grande quantidade de conhe cimentos oriundos de diversas áreas Isso torna muito mais difícil que um único profissional tenha conhecimento pro fundo de todos os objetos de estudo de IHC Se um único profissional dificilmente conhece em profundidade todos os assuntos relacionados com a interação entre pessoas e Qualidade e Usabilidade de Software 126 sistemas computacionais como é possível cuidarmos das questões relacionadas com a IHC de forma adequada Idealmente a responsabilidade de cuidar de IHC deve ser atribuída a uma equipe multidisciplinar Dessa forma profis sionais com formações diferentes podem trabalhar em con junto concebendo e avaliando a interação de pessoas com sistemas computacionais Esse ambiente heterogêneo de profissionais com diferentes formações facilita o surgimento de ideias a criatividade e a inovação bem como auxilia a análise do problema e de alter nativas de soluções sob pontos de vista bem variados enri quecendo assim o resultado do trabalho Atividades 1 A interação ser humanocomputador envolve desde requisitos para a criação de uma aplicação até as análises das reações dos usuários ao utilizaremna Quais são os fatores fundamentais da interação huma nocomputador 2 Cite os modelos recentes de IHC com foco no usuário que se desti nam a obter a experiência deste 3 Quais são as facetas da experiência do usuário presentes no honeycomb 4 Quais os desafios que a multidisciplinaridade da IHC traz aos pesqui sadores e desenvolvedores da área Usabilidade de software Introdução A usabilidade é considerada um atributo de qualidade que avalia a facilidade com que uma interface gráfica de software é utili zada Ela também se refere à aplicação de métodos durante um pro cesso de design para melhorar essa utilização NIELSEN 1993 Entre os fatores que determinam a usabilidade podese mencionar a acessibilidade a legibilidade a navegabilidade a faci lidade de aprendizado a eficiência do usuário e os índices de erros A expansão da usabilidade tem forçado uma simplificação nos sistemas de software Compreender e pesquisar a interação entre o usuário e o especialista em usabilidade pode antecipar e identificar a funcionalidade do produto que está sendo desenvolvido levando em conta o perfil do usuário a que se destina 7 Qualidade e usabilidade de software 128 Desse modo a usabilidade como abordada neste capítulo é uma das vertentes importantes da qualidade em software 71 Definições de usabilidade do software A capacidade com que as pessoas podem utilizar uma ferramenta é cha mada de usabilidade que também pode se referir ao estudo dos princípios da eficácia percebida de um objeto Esse modelo conceitual engloba o desenvol vimento de um produto focado no usuário A usabilidade tem relação com o grau de facilidade de utilização de um sis tema e é mensurada por testes relativos e empíricos o teste empírico baseiase em testes de usabilidade ou em trabalho em campo já o relativo depende das metas estabelecidas ou de uma comparação com outro guia de sistemas similares A International Organization for Standardization ISO fornece duas definições de usabilidade A ISOIEC 9241 afirma que a usabilidade se refere à medida na qual um produto pode ser usado por usuários específicos para alcançar objetivos específicos com eficá cia eficiência e satisfação em um contexto específico de uso ABNT 2002 p 3 Já a ISO 91261 ampliando esse conceito define a usabilidade como a capacidade do produto de software de ser compreendido aprendido operado e atraente ao usuário quando usado sob condições especificadas ABNT 2003 p 9 Então essa concepção abrange um conjunto de critérios tais como segurança e utilidade que estão relacionados principalmente aos sistemas de computador 129 Usabilidade de software Essas são definições centradas no conceito de qualidade em uso ou seja referemse à forma como o usuário executa determinadas tarefas em cenários específicos de forma eficaz Tendo por base esses conceitos dados pela ISO os princípios básicos da usabilidade podem ser assim definidos facilidade de uso facilidade de aprendizado flexibilidade e robustez O Quadro 1 a seguir explica cada um desses princípios Quadro 1 Princípios de usabilidade Princípio Característica Facilidade de uso Facilidade com que o usuário faz uso da ferramenta com menos etapas para chegar a seu objetivo proposto estando relacionada à eficiência da ferramenta Facilidade de aprendizado Facilidade com que novos usuários desenvolvem uma interação com o sistema ou produto relacionada com a familiaridade e a previsibilidade Flexibilidade Relacionada à diversidade de formas de executar uma deter minada tarefa e otimização entre usuário e sistema Robustez Facilidade e nível de serviço oferecido de suporte para cum prir os objetivos estando relacionado com a recupera ção de informações e o ajuste de tarefas do usuário Fonte WEBER 2006 Adaptado 72 Métodos de usabilidade No centro do processo de criação do software a usabilidade representa um projeto que incorpora os desejos e as necessidades do usuário os quais são especificados desde o início do processo e têm papel importante nas decisões sobre o produto Nesse projeto devem ser envolvidos em conjunto os usuá rios os especialistas em teste e os avaliadores Assim identificar as demandas do usuário algo essencial para a construção de um software é a primeira etapa no processo de desenvolvimento Qualidade e usabilidade de software 130 A abordagem do usuário para investigação de suas necessidades possui duas variantes distintas Ela pode ser uma abordagem contextual com uma entrevista estruturada para compreensão do seu contexto no processo de design determinando um foco na sua aplicação ou uma abordagem etno gráfica na qual é observado o usuário e sua interação com o produto em seu ambiente habitual 721 Métodos empíricos Os métodos empíricos para avaliar a usabilidade das interfaces do software podem ser realizados com ou sem a participação dos usuários Entre esses métodos estão os especificados a seguir 7211 Arranjo de cartões card sorting É uma técnica realizada por um grupo de especialistas que fazem testes com usuários para gerar um dendograma árvore de categorias com uma abor dagem útil para projetar uma arquitetura de informações o fluxo de trabalho a estrutura de menus ou os caminhos de navegação do site JORDAN 1998 A classificação de cartões utiliza uma técnica relativamente simples A pes soa que conduz o teste analista de usabilidade desenvolvedor entre outros identifica primeiro os conceitoschave e os grava em cartões Geralmente a aplicação é testada individualmente ou em grupos que podem ser colaborati vos grupos focais no entanto na literatura da área não existe um consenso sobre o número de indivíduos necessários para produzir resultados confiáveis Um cartão é comumente utilizado para projetar uma estrutura de nave gação a um ambiente que oferece uma variedade de conteúdos e funções como um site da web Nesse contexto os itens a serem organizados são aque les mais significativos nesse ambiente de uma forma que faça sentido para o públicoalvo Como o campo da arquitetura de informação se baseia no estudo da estrutura das informações a classificação de cartões é útil quando 2 a variedade de itens a organizar é tão grande que nenhuma taxono mia existente é aceita como organização dos itens 2 as semelhanças entre os itens tornam difícil uma divisão clara em categorias 131 Usabilidade de software 2 os membros do público que usam o ambiente diferem significativa mente em termos de como veem as semelhanças entre os itens e os agrupamentos apropriados destes Figura 1 Técnica card sorting de categorização de informações Fonte Abscent84iStockphoto O card sorting como ilustrado na Figura 1 ajuda na classificação e orga nização dos conteúdos de um website sob o ponto de vista dos usuários 7212 Avaliação cooperativa cooperative evaluation É um procedimento para obter dados sobre problemas experimentados na utilização de um software de modo que é aplicado com o intuito de melho rar o uso do produto final O que distingue esse método é a cooperação que ocorre à medida que pesquisador e participantes avaliam juntos uma interface JORDAN 1998 O objetivo da técnica não é fornecer uma lista exaustiva de todos os problemas que poderiam ser identificados mas sim ajudar a identificar com o mínimo de esforço os problemas mais importantes a serem considerados Qualidade e usabilidade de software 132 Essa metodologia de avaliação pode ser usada com 2 um produto existente que deve ser melhorado ou ampliado 2 um protótipo ou uma simulação parcial precoce 2 um protótipo de trabalho completo Além disso para a avaliação ser considerada cooperativa ela deve especi ficar tarefas permitindo que cada participante explore áreas da interface con sideradas mais relevantes à pesquisa Depois da interação os participantes verbalizam os problemas encontrados e o pesquisador registra as observações Por fim o pesquisador com base no que foi levantado e anotado analisa os resultados e propõe soluções PUCRIO 2017 7213 Diários de incidentes incident diaries Segundo Jordan 1998 os diários de incidentes são miniquestionários emitidos para os participantes a fim de que tomem notas de qualquer pro blema encontrado durante a utilização de uma interface Geralmente é solicitado que os indivíduos forneçam uma descrição por escrito do problema depois perguntase como eles resolveriam tal problema e de que forma essa situação os incomodava Esse método é apropriado para utilização no caso de interfaces finalizadas e que já estão em uso sendo que os diários registram informações sobre os problemas que ocorrem durante o ciclo de vida da interface em questão Os dados coletados podem ser aplicados para avaliar a usabilidade da interface atualmente utilizada ou para a tomada de decisões sobre projetos futuros 7214 Grupo focal focus group Essa é uma técnica de pesquisa qualitativa em que um grupo de pes soas é reunido para discutir um assunto particular em relação ao produto de software seguindo um roteiro de questões proposto e coordenado por um moderador JORDAN 1998 Essa discussão pode ser por exemplo sobre experiências dos usuários na utilização de uma interface com informações em relação a tarefas específicas 133 Usabilidade de software ou problemas de usabilidade Também abrange requerimentos para uma nova interface com base nos pontos que de acordo com os participantes necessi tam de melhorias Em geral a investigação de problemas de usabilidade envolve grupos de em média cinco ou seis indivíduos Nesse processo o trabalho do mode radorlíder do grupo é principalmente assegurar que todos os participantes exponham suas opiniões a respeito do produto PUCRIO 2017 7215 Experimentos controlados controlled experiments Um experimento controlado é aquele em que tudo é mantido constante exceto uma variável Geralmente um conjunto de dados é tomado para um grupo de controle que é comumente o estado normal ou usual e um ou mais grupos são examinados com condições idênticas a esse grupo controle exceto a variável Às vezes é necessário alterar mais de uma variável mas todas as condições experimentais são controladas de modo que apenas as variáveis que estão sendo examinadas mudam e a quantidade ou a maneira em que mudam é medida JORDAN 1998 7216 Lista de verificação de recursos características feature checklists Esse método visa avaliar a importância que os participantes dão a deter minadas características de uma interface A primeira coisa a se fazer na construção de uma lista de verificação de recursos é a definição dos tipos de software programas ou componentes deles A segunda etapa é definir atributos úteis para cada tipo de objeto de avaliação Como o principal princípio de organização é ser orientado para o usuário é importante seguir as características de qualidade para o software como definido pela ISO 9126 Além disso a lista de verificação deve ser cons truída sob o princípio de métodos de ensaio rigorosos atributos são incluídos apenas se eles se baseiam em valores formais bem definidos Qualidade e usabilidade de software 134 As listas de verificação de características são mais eficazes no caso de interfaces finalizadas que estão sendo utilizadas há algum tempo Assim é possível usar os dados obtidos para a fase de requisitos do projeto de uma nova interface JORDAN 1998 7217 Protocolos pensar alto think aloud protocols O protocolo de pensamento em voz alta é usado para coletar dados em testes de usabilidade em design e desenvolvimento de produtos em psicolo gia e em diversas ciências sociais por exemplo leitura escrita pesquisa de tradução processamento e rastreamento de processos O método foi intro duzido no campo de usabilidade por Clayton Lewis1 enquanto ele trabalhava na IBM e desenvolvido com base nas técnicas de análise de protocolo de Ericsson e Simon 1993 No entanto existem algumas diferenças significativas entre a forma como Ericsson e Simon propõem que os protocolos sejam conduzidos e como isso é realmente feito na prática devido às necessidades específicas e ao contexto dos testes de usabilidade Assim os profissionais devem estar cientes dessas diferenças e ajustar seu método para atender às suas necessi dades enquanto ainda coletam dados válidos Por exemplo eles podem pre cisar solicitar informações adicionais com mais frequência do que Ericsson e Simon permitiriam mas devem tomar cuidado para não influenciar o que os participantes dizem e fazem Os protocolos think aloud envolvem participantes pensando em voz alta enquanto executam um conjunto de tarefas especificadas ou seja eles são convidados a dizer o que vêm à sua mente enquanto completam ati vidades Isso pode incluir o que eles estão olhando pensando fazendo e sentindo o que dá aos observadores uma visão dos processos cognitivos dos participantes e não somente do seu produto final para tornar os mecanis mos de pensamento tão explícitos quanto possível durante o desempenho de cada tarefa Em um protocolo formal de pesquisa todas as verbalizações são transcritas e depois analisadas 1 Clayton Lewis é professor de Informática conhecido por suas pesquisas sobre métodos de avaliação no design da interface do usuário Ele deu grandes contribuições ao método de pen samento em voz alta usado regularmente em organizações de desenvolvimento de software no mundo todo 135 Usabilidade de software Em um contexto de teste de usabilidade os observadores são convi dados a tomar notas do que os participantes dizem e fazem sem tentar interpretar suas ações e palavras e especialmente observando em que pontos eles encontram dificuldade As sessões de teste são frequentemente gravadas em áudio e vídeo para que os desenvolvedores possam verifi car posteriormente o que os participantes fizeram e como reagiram Um método de coleta de dados relacionado mas ligeiramente diferente é o protocolo de conversa em voz alta que envolve os participantes apenas descrevendo suas ações mas não outros pensamentos O think aloud pode ser distinguido em dois tipos diferentes de procedi mentos experimentais O primeiro é o protocolo de pensamento em voz alta simultâneo coletado durante a tarefa e o segundo é o retrospectivo think loud reunido após a tarefa Existem benefícios e desvantagens em cada abordagem mas em geral um protocolo simultâneo pode ser mais completo enquanto um protocolo retrospectivo tem menos chance de interferir no desempenho da tarefa 7218 Questionário questionnaires Segundo Eduardo Brandão a palavra questionário é utilizada para distinguir um arranjo de questões incluindo algumas perguntas listas de checagem técnicas projetivas escalas de avaliação e uma variedade de outros métodos A função deste arranjo de questões é estabelecer obter gradualmente uma comunicação particular BRANDÃO 2006 p 182 Essas questões são compiladas pelo pesquisador e propostas aos participantes Os questionários podem conter listas de perguntas abertas ou fechadas e devese evitar linguagem muito técnica complexa JORDAN 1998 No caso de questionários fechados as questões precisam ser bem elaboradas para fazer com que as categorias de respostas sejam significativas para a pesquisa Assim as alternativas apresentadas ao participante devem cobrir uma ampla gama de respostas possíveis para cada situação Os questionários abertos por sua vez necessitam de perguntas mais abrangentes permitindo aos respondentes destacar todos os assuntos que considerem importantes em relação à interface avaliada Esse tipo de questionário é geralmente mais adequado no caso de Qualidade e usabilidade de software 136 interfaces que se encontram em estágios iniciais antes de elementos específicos de usabilidade serem claramente definidos PUCRIO 2017 7219 Registro de conversações private camera conversations Para evitar a interferência do pesquisador nesse método o participante vai a um estande e conversa em frente a uma câmera sobre os tópicos dados a elea A gravação de vídeo pode fazer com que os participantes tragam à tona aspectos mais intuitivos do que na presença de um entrevistador quando tendem a querer agir mais racionalmente Normalmente a conversa diante de uma câmera privada acontece depois de o participante ter lidado com um protótipo de software por um tempo mas pode acontecer também durante o uso de teste Esse registro de conversações pode desencadear dados experienciais mais autênticos do que em uma entrevista cara a cara Se dois amigos estiverem juntos no estande por exemplo a discussão poderá revelar aspectos experienciais interessantes No entanto o registro não garante que os participantes falarão sobre os temas que são de interesse do pesquisador Além disso nem todo tipo de partici pante se sente confortável para conversar em frente a uma câmera de vídeo JORDAN 1998 PUCRIO 2017 72110 Registro de uso logging use Nesse método softwares gravam interações entre os usuários permitindo a coleta de informações sobre a utilização do produto Para tanto é utilizado um laboratório de usabilidade em que duas salas são interligadas por um espe lho translúcido proporcionando uma observação livre Uma câmera de vídeo registra a expressão facial e a fala dos usuários ao longo do teste De acordo com Brandão 2006 p 186 a utilização de um método de registro de uso resulta na informação sobre a extensão da interação de um participante com um aspecto da interface ou o número de vezes que um comando particular foi utilizado No entanto esta informação necessita de interpretação 137 Usabilidade de software 722 Métodos não empíricos Na avaliação de usabilidade em interfaces de software também são utiliza dos os métodos não empíricos como os descritos na sequência 7221 Análise da tarefa task analyses É o processo de aprendizagem sobre os usuários comuns observandoos em ação para entender em detalhes como eles executam suas tarefas e atingem seus objetivos pretendidos Esse tipo de análise ajuda a identificar as tarefas que sites e aplicativos devem oferecer e também pode ajudar a refinar ou redefinir a navegação ou a pesquisa de um site determinando o escopo de conteúdo apropriado A análise de tarefas ajuda a suportar vários outros aspectos do processo de design centrado no usuário incluindo coleta de requisitos desenvolvi mento de estratégia de conteúdo prototipagem e execução de testes de usa bilidade Entre as técnicas mais comumente utilizadas estão a análise de tarefas cognitivas focada na compreensão de tarefas que requerem tomada de decisão resolução de problemas memória atenção e julgamento e a análise de tarefas hierárquicas focada na decomposição de tarefas de alto nível em subtarefas JORDAN 1998 7222 Avaliação heurística heuristic evaluation O objetivo principal das avaliações heurísticas é identificar quaisquer problemas associados ao design de interfaces de usuário O consultor de usa bilidade Jakob Nielsen2 1993 desenvolveu esse método com base em seus vários anos de experiência em ensino e consultoria sobre engenharia de usa bilidade Essas avaliações são um dos métodos mais informais de inspeção da usabilidade no campo da interação homemcomputador 2 Cientista da computação com PhD em interação homemcomputador Inventou vários métodos de usabilidade entre eles a avaliação heurística Qualidade e usabilidade de software 138 Existem diversos conjuntos de usabilidade de avaliação heurística os quais não são mutuamente exclusivos e cobrem muitos dos mesmos aspectos do design da interface do usuário Os problemas de usabilidade descobertos são categoriza dos muitas vezes em uma escala numérica de acordo com seu impacto estimado no desempenho ou na aceitação do usuário Esse tipo de avaliação é frequente mente realizada no contexto de casos de uso tarefas típicas do usuário para for necer feedback aos desenvolvedores sobre a medida em que a interface é suscep tível de compatibilidade com as necessidades dos usuários JORDAN 1998 7223 Avaliação de peritos expert appraisals Nesse método a interface é avaliada por meio da opinião de um ou mais peritos especialistas da área que pode trabalhar individualmente ou em conjunto É uma avaliação geralmente utilizada para verificação de designs iniciais e protótipos O grupo de especialistas selecionados tem knowhow para ins pecionar de modo mais aprofundado os princípios de usabilidade oferecendo meiossoluções para eventuais inadequações JORDAN 1998 7224 Lista de verificação de propriedades property checklists As listas de verificaçãochecklist relacionam uma série de propriedades de projeto que de acordo com as teorias do design da ergonomia e do ergo design asseguram que uma interface é fácil de ser usada Podem conter itens como consistência da interface compatibilidade padrões retorno ao usuário feedback posição de displays e controles nomenclatura de botões tamanho de caracteres na tela entre outras propriedades PUCRIO 2017 Os participantes da avaliação devem marcar na lista as características utilizadas na interface em questão Para Jordan 1998 os checklists são mais eficazes para análise de interfaces já finalizadas 7225 Percurso cognitivo cognitive walkthroughs É um método de avaliação da usabilidade também realizado por peritos No percurso cognitivo no entanto como afirma Brandão 2006 p 191 o pesquisador realiza a sua avaliação 139 Usabilidade de software de acordo com o ponto de vista de um usuário típico da interface Desta forma o investigador tenta desempenhar uma tarefa como se fosse o próprio usuário buscando predizer se este usuário pode enfrentar algum tipo de dificuldade durante os vários estágios ou pas sos necessários para completar a tarefa Jordan 1998 ressalta que para essa técnica funcionar é preciso que o perito tenha uma compreensão exata das características dos usuários para os quais a interface foi projetada incluindo suas habilidades e expectativas em relação ao produto 73 A importância das recomendações de usabilidade As recomendações de usabilidade ao serem incorporadas no desenvolvi mento do software mensuram a facilidade do uso de um produto Entre elas pode ser citada a aplicação dos testes que determinam quanto o usuário demora para encontrar determinado recurso e os erros cometidos durante esse caminho A acessibilidade do usuário é o principal ponto de estudo das indicações de usabili dade garantindo que a qualidade seja priori zada Interfaces amigáveis e com adaptação para os usuários em diferentes tarefas e ambientes tecnológicos são uma tendência no desenvolvimento de produtos e sistemas Assim a usabilidade determina a preocupação com a interação do usuá rio com o sistema por meio de uma interface O teste com usuários reais é a única maneira confiável de determinar suas necessidades o que pode ajudar na redução no número de chamadas de suporte tendo em vista que uma usabili dade ineficaz é a razão principal desse tipo de chamada por parte dos usuários PRESSMAN MAXIM 2016 A usabilidade também ajuda na redução do custo com treinamentos Um software fácil de se aprender evita custos de manutenção e revisão de produtos e versões Além disso o produto é mais bem aceito pelo usuário o Qualidade e usabilidade de software 140 que ajuda a aumentar a produtividade e a probabilidade de recomendação a outros possíveis usuários PFLEEGER 2004 Portanto a usabilidade inter fere na utilidade e na aceitação do produto e na fidelidade do cliente Assim a usabilidade também influi no processo de diferenciação do pro duto em relação aos concorrentes ou seja se dois produtos têm a mesma utilidade o que tiver maior usabilidade será considerado superior O usuário vai preferir o produto que apresentar vantagens em relação à usabilidade mesmo que as diferenças sejam pequenas Ele irá testar o produto cada vez que o utiliza comparandoo com o da concorrência e dependendo do resul tado continuará usandoo ou o abandonará Daí a importância de se testar adequadamente o produto antes de lançálo no mercado visto que isso pode garantir que a experiência do usuário seja positiva evitandose dessa forma revisões no processo de produção PRESSMAN MAXIM 2016 As indicações de usabilidade do sistema devem ser obedecidas desde o projeto inicial para que ela possa ser atingida Quando isso ocorre há uma chance maior de o software ser bem elaborado tornarse mais eficiente com baixa taxa de erros e de fácil memorização Essas características exigirão um esforço menor do usuário que realizará tarefas repetitivas em menos tempo e não se perderá na navegação do sistema Nesse sentido as recomendações funcionam como um guia importante para os programadores ao desenvolve rem testarem e finalizarem um software apontando os problemas e os erros enquanto ainda há tempo de serem solucionados Para abordar as recomendações de melhoria da usabilidade de um pro jeto de interfaces computacionais muitos são os termos e conceitos emprega dos O Quadro 2 a seguir apresenta e explica alguns desses termos Quadro 2 Termos empregados para usabilidade de software Conceito Às vezes também chamado de Como utilizar Metas usabilidade Estabeler critérios de usabilidade para avaliar a aceitabilidade de um sis tema p ex Quanto tempo leva para a realização de uma tarefa 141 Usabilidade de software Conceito Às vezes também chamado de Como utilizar Metas decorrentes da experiência do usuário Fatores de satisfação Identificar os aspectos importan tes da experiência do usuário p ex Como se pode tornar o produto inte rativo divertido e agradável Princípio de design Heurística quando utilizado na prática Conceitos de design Como lembretes do que fornecer e do que evitar durante o design da inter face p ex que tipo de feedback você vai fornecer na interface Princípio de usabilidade Heurística quando utilizado na prática Avaliar aceitabilidade das interfa ces utilizadas durante a avaliação heurística p ex O sistema oferece saídas claramente indicadas Regras Determinar se uma interface adere a uma regra específica quando está sendo projetada e avaliada p ex Sempre oferecer um botão backward e forward em um navegador Fonte PREECE ROGERS SHARP 2005 p 60 A facilidade de utilização do software envolve um processo iterativo e isso significa que os testes devem ser ininterruptos pois se houver a aplicação de apenas um teste durante o seu desenvolvimento tornase difícil corrigir todos os problemas O desenvolvedor de software deve refletir sobre o fato de que o usuário quando tem uma experiência negativa no uso de uma interface deficiente sentese frustrado por não conseguir realizar tarefas que hipote ticamente outros usuários conseguiriam Em interfaces de uso frequente e profissional os aborrecimentos podem levar à ansiedade e ao estresse devido à sequência de experiências negativas e da pressão pela obrigação do uso Assim é recomendável executar pequenos testes e rever a concepção de cada software em específico de modo que os defeitos identificados possam ser reparados Nesse contexto o projeto iterativo é a melhor maneira de aumen tar a qualidade da experiência do usuário Quanto mais versões e ideias forem testadas com as interfaces melhor será a usabilidade A usabilidade é uma condição necessária também para a sobrevivência de sites incluindo o ecommerce porque se o site falhar isso pode indicar Qualidade e usabilidade de software 142 que a empresa oferece informações difíceis de ler ou que não atendam às questõeschave do usuário Embora na teoria muitas empresas reconheçam a importância da usabilidade para o desenvolvimento de seus sistemas na prática elas parecem não saber como agir para atingila Contudo a área de usabilidade de software tem apresentado um cresci mento considerável devido a sua importância No caso de intranets a usabi lidade é um elemento de produtividade dos funcionários o tempo que eles gastam à procura de informações sem encontrálas é custoso para a empresa A facilidade de leitura das informações ajuda na presteza e na redução de custo no desenvolvimento de atividades Portanto as recomendações de usabilidade vão além da fácil utilização de um software trazendo benefícios aos projetos inter nos das empresas Nesse caso a ênfase na usabilidade pode representar uma redução significativa do orçamento em treinamento e a duplicação de desem penho de funcionários horistas o que significaria uma duplicação de vendas e o aumento do número de usuários registrados Ampliando seus conhecimentos A maioria das características e restrições de interface de software implementadas pelos desenvolvedores destinamse a simplificar o modo de interação No entanto é preciso que o projetista esteja atento ao fato de que essa facilidade de interação não necessariamente significa uma adequada usabilidade para o des tinatário do produto o usuário final Ao tratar desse assunto o texto apresentado a seguir dá dicas para que o desenvolvedor proporcione a melhor experiência possível ao usuário Deixar o usuário no comando PRESSMAN MAXIM 2016 p 318319 Como projetista talvez sejamos tentados a introduzir restri ções e limites para simplificar a implementação de interface O 143 Usabilidade de software resultado pode ser uma interface fácil de ser construída mas frustrante sob o ponto de vista do usuário Mandel define uma série de princípios de projeto que permitem ao usuário manter o controle Defina modos de interação para não forçar o usuário a realizar ações desnecessárias ou indesejadas Modo de interação é o estado atual da interface Por exemplo se for escolhido o comando de correção ortográfica no menu de um processador de texto o software entra no modo de correção ortográfica Não há nenhuma razão para forçar o usuário a permanecer no modo de revisão ortográfica se ele quer ape nas fazer uma pequena edição de texto no meio do caminho O usuário deve ser capaz de entrar e sair desse modo com pouco ou nenhum esforço Proporcione interação flexível Pelo fato de diferentes usuá rios terem preferências de interação diversas devese fornecer opções Por exemplo um software poderia permitir a um usuá rio interagir por meio de comandos de teclado movimenta ção do mouse caneta digitalizadora tela multitoque ou por comandos de reconhecimento de voz Mas nem toda ação é suscetível a todo mecanismo de interação Considere por exemplo a dificuldade de usar comandos via teclado ou entrada de voz para desenhar uma forma complexa Possibilite que a interação de usuário possa ser interrompida e desfeita Mesmo quando envolvido em uma sequência de ações o usuário deve ser capaz de interromper a sequência para fazer alguma outra coisa sem perder o trabalho que já havia feito O usuário também deve ser capaz de desfazer qualquer ação Simplifique a interação à medida que os níveis de compe tência avançam e permita que a interação possa ser perso nalizada Geralmente os usuários constatam que realizam a mesma sequência de interações repetidamente Vale a pena Qualidade e usabilidade de software 144 criar um mecanismo de macros que permita a um usuário avançado personalizar a interface para facilitar sua interação Oculte os detalhes técnicos de funcionamento interno do usuário casual A interface do usuário deve leválo ao mundo virtual da aplicação O usuário não deve se preocupar com o sistema operacional as funções de arquivos ou alguma outra tecnologia computacional enigmática Projete para interação direta com objetos que aparecem na tela O usuário tem a sensação de controle quando lhe é permitido manipulara os objetos necessários para realizar uma tarefa de maneira similar ao que ocorreria caso o objeto fosse algo físico Por exemplo a interface de uma aplicação que permita a um usuário arrastar um documento para o lixo é uma implementação de manipulação direta Atividades 1 Defina o termo usabilidade 2 Com base no conceito dado pela ISO quais são os princípios básicos da usabilidade 3 Quando a usabilidade de um sistema é atingida 4 De que modo a usabilidade pode contribuir na redução de custos de um produto de software na aceitação do produto e na fidelidade do cliente Acessibilidade e inclusão digital Introdução O avanço da globalização deve assumir um elemento de inte gração das pessoas Não há como pensarmos em uma sociedade da informação onde as tecnologias não proporcionem acessibilidade aos usuários Nesse contexto a acessibilidade pode ser compreendida de diferentes maneiras Em relação à acessibilidade na web ela diz res peito a uma prática inclusiva no desenvolvimento de websites que possam ser utilizados por todas as pessoas independentemente de elas terem ou não alguma necessidade especial Quando os sites são corretamente concebidos desenvolvidos e editados todos os usuá rios podem ter igual acesso à informação e à funcionalidade Todas as inspeções normas métricas e métodos de software são voltados para a produção em conformidade com padrões de qualidade Desse modo a busca pela qualidade percebida tem como 8 Qualidade e usabilidade de software 146 objetivo principal produzir produtos cada vez melhores e com menos erros para que o usuário final fique satisfeito Nessa ótica o produto software além de usual deve ser acessível às pes soas independentemente de idade necessidades especiais e nível de escolari dade Isso porque o software é na verdade um artefato produzido por pes soas para pessoas e portanto precisa ser acessível a todos a fim de que atinja a função a que se propõe Tendo isso em vista o objetivo deste capítulo é apresentar uma reflexão sobre a inclusão digital na atualidade 81 A acessibilidade digital Acessibilidade referese à facilidade de acesso a um lugar uma pessoa um conhecimento ou um objetobem Com o advento da sociedade da informa ção o conceito de acessibilidade evoluiu tendo em conta as novas realidades Na verdade mobilidade proximidade e distância já não são aspectos essenciais da definição de acessibilidade ou melhor a acessibilidade no espaço físico é agora complementada pela disponibilidade do espaço virtual desafiando os princípios de distância proximidade ou interação espacial NIELSEN TAHIR 2002 A acessibilidade ao ambiente físico está relacionada à qualidade que os espaços disponibilizam a todos inclusive nos casos de deficiência de mobi lidade ou comunicação IBM 2017 incluindo a possibilidade de chegar a todos os lugares e edifícios sem esforço excessivo e acessar as instalações de uso público e serviços fornecidos com segurança e autonomia O Decreto n 5296 do governo federal define a acessibilidade como con dição para utilização com segurança e autonomia total ou assistida dos espa ços mobiliários e equipamentos urbanos das edificações dos serviços de trans porte e dos dispositivos sistemas e meios de comunicação e informação por pessoa portadora de deficiência ou com mobilidade reduzida BRASIL 2004 Em paralelo no caso da web e da internet em geral a acessibilidade se refere ao conjunto de elementos que facilitam o acesso à informação a todas as pessoas de modo igualitário usando a tecnologia computadores 147 Acessibilidade e inclusão digital tablets telefones móveis entre outros independentemente das necessida des especiais dos usuários físicas mentais sensoriais e outras NIELSEN TAHIR 2002 Assim a acessibilidade digital se refere a uma democratização do acesso as redes independentes de qualquer barreira física cognitiva ou a qualquer outro distúrbio préexistente Fazse referência a um projeto que permita que as pessoas percebam compreendam naveguem e interajam com a web IBM 2017 inclusive os mais velhos que viram o mundo mudando e agora precisam se adequar às novas tecnologias Para Kidal Weber 2006 a acessibilidade é a facilidade de uso de uma forma eficiente e bemsucedida de um produto serviço ambiente ou o instru mento por pessoas com deficiência Já a infoacessibilidade referese a produ tos e serviços eletrônicos que podem ser utilizados por usuários com eficiência e satisfação em um contexto de uso específico por exemplo acessibilidade de equipamentos de informática hardware e software acessibilidade da web da televisão digital da telefonia móvel de produtos e serviços de automação e de outros serviços característicos da sociedade da informação WEBER 2006 A inclusão digital requer três instrumentos básicos computador acesso à rede e o domínio dessas ferramentas Portanto não é suficiente ter um computador conectado à internet sendo também necessário saber o que fazer com essas tecnologias IBM 2017 De acordo com o Livro Verde do Ministério da Ciência e Tecnologia TAKAHASHI 2000 a acessibilidade à informação e ao conhecimento é a variável de maior poder de exclusão ou inclusão dos indivíduos no processo político e econômico ressaltando que as políticas públicas de universalização de acesso como o Fundo de Universalização dos Serviços de Telecomunicações FUST também devem se preocupar com a inclusão digital dos menos favo recidos economicamente 2000 p 220 Entre as estratégias e ações inclusivas há projetos que facilitam o acesso de pessoas de baixa renda às tecnologias de informação além do desenvol vimento de tecnologias que estendem a acessibilidade para usuários com deficiência NIELSEN TAHIR 2002 Nesse quadro a inclusão digital é a democratização do acesso às tecnologias de informação e comunicação para permitir a inserção de todos na sociedade da informação Qualidade e usabilidade de software 148 Assim toda a sociedade pode ter acesso a informações disponíveis na internet e com isso produzir e disseminar conhecimento A inclusão digital está portanto inserida no movimento de inclusão social sendo ela um dos principais objetivos partilhados por vários governos ao redor do mundo nas últimas décadas WARSCHAUER 2006 811 Acessibilidade para todos A acessibilidade é também uma condição necessária para a participação social de pessoas com diferentes limitações funcionais Em uma sociedade em que cada vez mais a Tecnologia da Informação e Comunicação TIC é usada para aprender estudar socializar divertir e trabalhar garantir a acessibilidade das novas tecnologias de mídia particularmente a internet é uma prioridade VALERIANO 2005 Acessibilidade digital trata de aspectos relacionados com a codificação e apresentação das informações na concepção de um site permitindo que pessoas com algum tipo de limitação possam perceber compreender navegar e interagir eficazmente com a rede bem como criar e contribuir com conteú dos NIELSEN TAHIR 2002 A acessibilidade abrange muitos tipos de deficiência como visual audi tiva física cognitiva problemas neurológicos e da fala temporárias ou per manentes Há milhares de pessoas com deficiência que ainda não podem usar a web por conta das barreiras de acessibilidade existentes em sites e softwares Assim quanto mais softwares e sites acessíveis forem disponibilizados mais pessoas poderão usar a web e contribuir de forma mais efetiva na sociedade NIELSEN TAHIR 2002 Ainda hoje grande parte dos sites e softwares apresentam barreiras de acessibilidade tornando difícil ou mesmo impossível o seu uso No entanto se eles fossem acessíveis pessoas com deficiência poderiam usar esses serviços de forma eficaz IBM 2017 A acessibilidade para esses indivíduos está regulamentada em lei e pre sente no ambiente organizacional A Lei n 8213 de 24 de julho de 1991 determina que empresas com mais de cem funcionários precisam reservar vagas para pessoas com necessidades especiais 149 Acessibilidade e inclusão digital O decreto n 329899 BRASIL 1999 dispõe sobre a Política Nacional para a Integração da Pessoa Portadora de Deficiência consolidando as nor mas de proteção para esses indivíduos no convívio em sociedade E a Lei n 1009800 BRASIL 2000 estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas com deficiências ou com mobilidade reduzida Já a Portaria MEC n 67999 BRASIL 1999 dispõe sobre os requisitos de acessibilidade a pessoas com deficiência para instruir processos de autorização e de reconhecimento de cursos e de credencia mento de instituições Os princípios de acesso ao ensino e de igualdade de condições de acesso e permanência na escola estão dispostos na Lei de Diretrizes e Bases LDB afirmando no art 208 que o dever do Estado com a educação será efetivado mediante a garantia de acesso aos níveis mais elevados de ensino da pesquisa e da criação artística segundo a capacidade de cada um BRASIL 1996 Além dos usuários com deficiências há também aqueles usuários que têm conexões lentas de internet ou acessam a rede via laptops e PDAs Personal Digital Assistant ou telefones móveis com telas gráficas reduzidas os quais também podem se aproveitar do design acessível Em geral de uma forma ou de outra todos os usuários podem se beneficiar com a acessibilidade na web WARSCHAUER 2006 As dificuldades de acesso ao conteúdo da web podem ser reduzidas con sideravelmente se os responsáveis pelas organizações de gerenciamento de websites os desenvolvedores e os gerentes de conteúdo levarem em conta as necessidades das pessoas a diversidade de formas de acesso condicionada pelos diferentes tipos de terminais existentes softwares velocidade de cone xão e muitos outros fatores e se respeitarem algumas estruturas simples de páginas web IBM 2017 De acordo com Melo 2007 p 98 A acessibilidade na web depende do entrosamento de diferentes componentes relacionados ao desenvolvimento de seu conteúdo e também à interação dos usuários com suas páginas Enquanto desen volvedores web contam com ferramentas de autoria ex editores de páginas web ferramentas de gerenciamento de conteúdo wikis etc e ferramentas de avaliação ex verificadores de linguagem de marca ção ferramentas semiautomáticas de avaliação de acessibilidade para Qualidade e usabilidade de software 150 desenvolver conteúdo web usuários da rede mundial de computado res podem usar navegadores media players e tecnologias assistivas entre outros agentes de usuário para obter informação produzir con teúdo e interagir A acessibilidade na web depende da interação entre esses diferentes componentes e quando um deles falha a experiência do usuário com páginas e aplicações web fica comprometida Na busca pela acessibilidade na web o Consórcio World Wide Web W3C é uma instituição que realiza um esforço para melhorar a acessibili dade à web para pessoas com deficiência Pessoas com necessidades especiais podem encontrar dificuldades ao usar computadores em geral e acessar con teúdos na grande rede O Consórcio disponibiliza informações diretrizes relatórios técnicos materiais educacionais e outros documentos que se rela cionam aos diversos componentes de acessibilidade da web Esses componen tes incluem conteúdo da web navegadores e players de mídia ferramentas de autoria e ferramentas de avaliação1 O Web Accessibility Initiative é a elaboração de diretrizes e técnicas desen volvidas pelo W3C que fornece soluções acessíveis para software como no documento Componentes essenciais de acessibilidade na web que descreve os diferentes papéis da acessibilidade IBM 2017 Essas diretrizes são considera das as normas internacionais para a acessibilidade NIELSEN TAHIR 20022 As diretrizes e técnicas desenvolvidas pelo W3C apontam para a neces sidade de se fazer um website levando em conta fatores como o tipo de con teúdo o tamanho e a complexidade do site bem como as ferramentas de desenvolvimento e meio ambiente Muitos dos recursos acessíveis de um site podem ser facilmente implementados se forem planejados desde o início de seu desenvolvimento ou de sua reformulação Modificar sites com recursos de baixa acessibilidade pode exigir um esforço significativo especialmente aqueles que não são rotulados adequadamente com marcação XHTML padrão e locais com determinados tipos de conteúdo tais como multimídia NIELSEN TAHIR 2002 1 Mais informações sobre o Consórcio W3C podem ser encontradas no endereço http wwww3cbrHomeWebHome 2 Mais informações sobre essas diretrizes estão disponíveis no endereço httpswwww3org WAIguidtech 151 Acessibilidade e inclusão digital Ao desenvolver ou redesenhar um site devese avaliar a acessibilidade de modo a encontrar possíveis problemas desde o início quando é mais fácil de resolvêlos Técnicas simples como mudar as configurações em um navegador podem determinar se uma página da web atende às diretrizes de acessibilidade Uma avaliação abrangente para determinar o cumprimento das orientações é bastante complexa WARSCHAUER 2006 Existem ferramentas de avaliação que ajudam nesse processo no entanto para determinar se um website é realmente acessível é necessária uma avaliação humana NIELSEN TAHIR 2002 A acessibilidade melhora a capacidade de gerenciamento dos sites garantindo que as páginas sejam mais facilmente navegáveis e que possam ser acessados por uma variedade de dispositivos e não apenas do desktop tradi cional WARSCHAUER 2006 Além disso há também uma questão econômica a acessibilidade pode ser uma ferramenta poderosa para a fidelidade do cliente Do mesmo modo empresas e desenvolvedores podem perder clientes potenciais se estes tiverem dificuldades para navegar e interagir nos sites e acessar determinados serviços IBM 2017 De acordo com o Portal Brasil 2017 p 1 Quando falamos em Web acessível é preciso ter em mente que o mais importante para a acessibilidade é o código HTML HyperText Markup Language O leitor de tela e outros recursos de Tecnologia Assistiva interpretam o código HTML seus elementos e semântica Por isso o primeiro passo para garantir acessibilidade ao conteúdo Web é utilizar código semanticamente correto ou seja cada elemento para o seu propósito seguindose os Padrões Web ou Web Standards do W3C World Wide Web Os Padrões de Desenvolvimento Web ou Web Standards são um conjunto de normas diretrizes recomen dações notas artigos tutoriais e afins de caráter técnico produzidos pelo consórcio W3C com a finalidade de atingir uma padronização e a criação de uma Web universal Alguns conceitos devem ser considerados no desenvolvimento de sites acessíveis PORTAL BRASIL 2017 p 1 2 Conceito de Camadas Representa o uso adequado das tecno logias ou seja cada tecnologia deve ser utilizada com o propó sito único ao qual foi criada Por exemplo o HTML é utilizado Qualidade e usabilidade de software 152 apenas para a criação de conteúdo enquanto a apresentação visual é criada através do CSS Já o comportamento é definido pelas lin guagens de script 2 Conceito Tableless As tabelas devem ser usadas apenas para dados tabulares e não para fins de layout Esse conceito surgiu devido ao uso excessivo de tabelas para apresentação visual do site O uso de tabelas para a estruturação da página prejudica a apre sentação da página em determinadas resoluções de tela deixa a página mais pesada tem como consequência um código de difícil manutenção além de causar problemas de acessibilidade 2 Conceito de Semântica Representa o uso correto das tags HTML pois cada tag possui um objetivo específico e para tal deve ser utilizado Após a criação do site seguindose esses conceitos o desenvolvedor deve validar todas as páginas do site no validador do W3C Essa validação encontrará os erros de concordância entre o código criado e as recomendações e fornecerá ao desenvolvedor a forma de corrigilo O conceito de semântica pode ser observado na figura 2 Outro aspecto e possivelmente o mais importante é a consciência social a web deve ser entendida como algo universal e essa universalidade deve levar em conta o acesso por qualquer pessoa às informações forneci das online As empresas devem se atentar a esse contexto de inclusão social porque o fato de ter um site acessível a todas as pessoas independentemente de conhecimento pessoal ou deficiências dos usuários e das características técnicas dos equipamentos utilizados é uma vantagem social sobre a con corrência e um diferenciador NIELSEN TAHIR 2002 82 A inclusão digital Segundo Pedro Demo 2007 a inclusão digital deve ser entendida como uma política social do conhecimento e relevante alavanca contra a desigualdade social As novas tecnologias influenciam de forma marcante as transformações na sociedade No caso do Brasil que possui uma grande extensão territorial e uma intensa desigualdade social as dificuldades para a inclusão digital são mais severas como afirma Demo 2005 do que em países mais desenvolvidos 153 Acessibilidade e inclusão digital onde adultosidosos são inseridos na sociedade digital com mais autonomia utilizando a tecnologia a seu favor e não apenas como consumidores Esse cenário no entanto vem mudando3 desde meados dos anos 2000 observase uma popularização dos aparelhos eletrônicos influenciados pelo barateamento dos preços A democratização do acesso aos computadores à internet e a outras fer ramentas digitais gerou um movimento de acesso a diferentes conhecimentos composto por uma comunicação interativa Hoje o computador está presente nos mais variados contextos empresarial acadêmico domiciliar A informá tica veio para inovar e facilitar a vida das pessoas e não é mais possível ignorar essa realidade tecnológica Para Edgar Morin 1998 é visível a relevância da inclusão das novas tecnologias como meio de se adquirir saber A inclusão digital serve de suporte cultural científico e tecnológico apoiando a educação ampliando a participação social promovendo a interatividade e auxiliando no percurso do longo caminho da formação de cidadãos críticos conscientes de seus direitos e deveres Segundo Pierre Lévy 2000 novas maneiras de pensar e de conviver estão sendo elaboradas no mundo das telecomunicações e da informática Os sistemas de informação e as redes de computadores avançam velozmente e a informatização captura a escrita a leitura a visão a audição a criação e a aprendizagem O autor também aborda a velocidade dos recursos tecnoló gicos e alerta sobre o erro de levarmos tempo demais discutindo suas possi bilidades de uso porque enquanto discutimos possíveis usos de uma dada tecnologia algumas formas de usar já se impuseram tal a velocidade e reno vação com que se apresentam LÉVY 2000 p 26 3 Em diversos estados brasileiros lançamse movimentos em prol da inclusão digital Dentre estes destacamse o Programa GESAC Governo EletrônicoServiço de Atendimento ao Ci dadão 2003 resultado da parceria entre órgãos do Governo Federal Ministério das Comu nicações do Planejamento da Educação da Defesa e Instituto de Tecnologia da Informação o Programa Telecentros 2007 o Programa Acessa São Paulo o qual foi premiado internacio nalmente o Programa Sinergia Digital criado e mantido pela PUCRS e o NAVEGAPARÁ Programa de Democratização do Acesso às Tecnologias de Informação e Comunicação 2007 Qualidade e usabilidade de software 154 A adaptação às novas ferramentas tecnológicas é complexa para alguns indivíduos ela acontece rapidamente outros no entanto devido à heteroge neidade cultural social econômica e cognitiva têm mais dificuldades para se adequarem a esses processos Para Demo 2007 o computador pode ser uma ferramenta de inclusão ou exclusão social visto que a sociedade contemporâ nea exige a inclusão digital para todos porém algumas pessoas ainda não têm acesso a essas tecnologias Exclusão digital é o termo usado para se referir à consequência direta do abismo tecnológico que existe entre as comunidades que têm acesso à tecno logia da informação e aquelas que são excluídas desse processo As diferenças entre elas podem ser socioeconômicas ou em relação à capacidade de usar a tecnologia da informação de forma eficaz devido aos níveis distintos de alfa betização e disponibilidade de recursos 821 Inclusão digital na sociedade Existe uma relação dialética entre a adesão e a crítica aos novos ins trumentos tecnológicos com muitos argumentos a favor e outros que se opõem à inserção das Tecnologias de Informação e Comunicação TICs na comunidade Os conteúdos disponibilizados por meio das TICs favorecem a com preensão de processos culturais e sociais sendo que a tecnologia facilita a conexão e comparação com diversas realidades criando novas oportunidades A universalização do uso da tecnologia digital assim permite uma inclu são dos indivíduos na realidade atual visto que as principais atividades eco nômicas e boa parte da produção cultural e das ações governamentais estão migrando para a web SILVEIRA 2008 Assim hoje em dia quanto mais demorado for o processo global de inclusão digital maior será a desigualdade socioeconômica entre diferentes grupos Ao tratar de políticas específicas para inclusão nessa sociedade em rede Bonilla e Pretto 2011 alegam que o mais adequado seria colocar em prá tica iniciativas que proporcionem a inclusão de cidadãos não como meros consumidores seja de produtos ou de informações mas como sujeitos plenos que participam do mundo contemporâneo enquanto seres éticos autônomos 155 Acessibilidade e inclusão digital e com poder de decisão A disponibilização pelo governo de cursos básicos de informática para a população de baixa renda seria uma medida básica para garantir o acesso digital a um número cada vez maior de pessoas assim como programas para aquisição de equipamentos a preços mais baixossubsidiados Nesse cenário tecnológico as redes sociais e diversos aplicativos apps já são hoje ferramentas amplamente difundidas e utilizadas nos processos de interação entre os indivíduos seja nos relacionamentos pessoais seja nos mais diversos contextos profissionais Isso permite que os sujeitos não só adqui ram conhecimentos mas também os produzam e disseminem de modo descentralizado Esse processo em direção à chamada emancipação digital SCHWARTZ 2010 no entanto envolve um longo caminho de apropria ções socioculturais e educativas Desse modo a criação de ambientes de rede multidirecionais em que usuários estão constantemente em comunicação conectados e interconectados amplia dia após dia os limites antes impostos pelas barreiras físicas Estamos portanto frente a fluxos multidirecionais e imprevisíveis de informação cultura e conhecimento constantemente ressignificados de onde emerge um processo dinâmico marcado pela tensão entre tradição e modernidade necessidade e liberdade BONILLA PRETTO 2011 p 104 822 Inclusão digital e educação No contexto educacional brasileiro muitos professores ainda utilizam métodos tradicionais de ensino por não saberem lidar com as novas tecnolo gias No entanto em grande parte das escolas do país gradativamente é inse rida a mediação tecnológica na aprendizagem de alunos e na capacitação dos docentes para a utilização desses novos recursos De acordo com Meneguelli 2010 com a democratização do uso da internet e o desenvolvimento de ins trumentos tecnológicos e digitais não há mais como a escola utilizar somente quadro e giz A soma dos métodos tradicionais aos novos promove a adequação necessária para um bom desenvolvimento da prática pedagógica tendo como suporte as ferramentas inovadoras que apoiam a pesquisa o conteúdo pedagógico a dinâmica do professor e os demais componentes do ambiente educacional Para ocorrer essa integração é necessário que o educador seja Qualidade e usabilidade de software 156 maleável tendo em vista que a aprendizagem é reconstrutiva fazendo com que o indivíduo participe dessa realidade A capacidade de conviver e inter ferir na realidade está presente no conhecimento é preciso saber inovar e acompanhar as crescentes e constantes inovações científicas e tecnológicas que surgem na sociedade contemporânea Portanto aluno e professor são capazes de se adequar a esse universo de modernidades que invadem as salas de aula os laboratórios as residências não há como isolarse ou ignorar a onda tecnológica que se renova constante mente Docentes e discentes deverão aproveitar a velocidade a interatividade e todos os benefícios fornecidos pelas redes pelas conexões e mídias digitais para evoluírem no saber e na cidadania Assim como o domínio do professor e a apropriação dos alunos das novas técnicas pedagógicas é indispensável também que a escola possua uma boa estrutura física e material possibilitando o uso desses equipamentos durante as aulas São visíveis hoje as melhorias na educação nos diferentes níveis de ensino com um melhor rendimento escolar a elevação na qualidade da aprendizagem uma maior sincronia na relação professoraluno e metodo logias que apresentam flexibilidade para inserção de constantes atualizações e novas ideias No entanto essa inclusão de métodos novos de geração de novos saberes precisa ser planejada bem estruturada reconstruída constan temente para que possa render bons frutos Entrelaçar os fios entre a comunicação o mundo virtual a escola e a sociedade exige uma transformação do pensamento individual e coletivo assim como leva professores e alunos a romper com alguns padrões tradicio nais Portanto são necessárias mudanças interiores e exteriores na educação para que sejam aplicadas as inovações propostas que compõem a inclusão digital fazendo que o aluno aproveite a multiplicidade de oportunidades ofe recidas pelas novas tecnologias 83 Projetos de inclusão digital Com a elaboração de projetos e programas governamentais de incen tivo à inclusão digital foram criados o Programa Nacional de Tecnologia Educacional ProInfo Integrado e em seguida o Projeto Um Computador 157 Acessibilidade e inclusão digital por Aluno ProUCA amparado pela Lei n 122492010 Essa lei também trata do Regime Especial de Aquisição de Computadores para Uso Educacional RECOMPE que facilita a compra de computadores para uso educacional Algumas instituições públicas de ensino conseguiram implementar em seu currículo esses programas e muitos alunos foram beneficiados aprenderam com e sobre a tecnologia criaram blogs educativos grupos para pesquisa de temas significativos e contextualizados com o século XXI e ampliaram seus conheci mentos de informática Português Matemática entre outras disciplinas Assim gradativamente as escolas públicas brasileiras em todos os seus segmentos de ensino são levadas a incluírem o uso das TICs em suas práticas pedagógicas como ferramenta facilitadora de ensinoaprendizagem e inclusão social Da década de 1970 até a atualidade além das redes do governo também se observou a inserção gradativa e a utilização da telemática transmissão de informação a longa distância nas instituições de ensino privadas e em outras áreas profissionais inclusive no que diz respeito a pessoas com deficiência Nesse contexto de inclusão e acesso às tecnologias muitos softwares livres foram criados ou desenvolvidos para facilitar o uso e a experiência por parte das pessoas com deficiência A seguir são apresentados alguns desses projetos 831 Deficiência visual Hoje já são vários os projetos de softwares que visam à acessibilidade por parte dos usuários que apresentam algum tipo de deficiência visual Alguns desses sistemas podem ser destacados 2 O projeto Orca é um leitor de tela para o software livre flexível e extensível desenvolvido pelo projeto Gnome para pessoas cegas ou com deficiência visual Pelo uso combinado de voz eou braile o Orca fornece acesso a aplicativos e ferramentas que suportam provedores de interface de tecnologia assistiva ATSPI por exem plo Gnome aplicações OpenOffice Mozilla FirefoxThunderbird entre outros O desenvolvimento do Orca foi iniciado pelo Escritório do Programa de Acessibilidade da Sun Microsystems Inc atual Oracle O conceito original e o primeiro protótipo foi Qualidade e usabilidade de software 158 realizado em 2004 por Mark Mulcahy um programador cego que trabalhou na Sun Microsystems Disponível em httpswikignomeorgProjectsOrca 2 O projeto Lazarus é uma distribuição Linux para pessoas com defi ciência visual que incorpora várias ferramentas e aplicativos para facilitar seu acesso Pode ser baixado por meio da imagem do Live CD e por isso não é necessário instalálo no disco rígido do computador para usálo Disponível em httpswwwlazarusideorg 2 O projeto LinaccessKnoppix é uma distribuição Linux particu larmente útil para pessoas com deficiência visual desenvolvida no âmbito do projeto Linacess Disponível em httpwwwlinaccessorg 2 O navegador de internet Mozilla Firefox é um popular programa de software livre processado em Windows Linux e outras platafor mas incluindo recursos de acessibilidade importantes que facilitam o uso por pessoas com deficiências visuais Disponível em httpwwwmozillaorgaccess 2 Brltty é um processador de computador interativo que roda em segundo plano e permite ao usuário se conectar e usar um teclado em braile para a porta serial e no console de texto para os sistemas operacionais Linux e Unix Disponível em httpmielkeccbrlttyindexhtml 2 Festival é um sintetizador de voz que reproduz textos em inglês e espanhol disponíveis em diferentes distribuições Ele inclui docu mentação completa e ferramentas para construir novas vozes dis poníveis por meio do Projeto Festvox de Carnegie Mellon Disponível em httpfestvoxorg 159 Acessibilidade e inclusão digital Disponível em httpwwwcstredacukprojectsfestival 2 GnomeSpeech é uma biblioteca geral API simples que faz a programação de software com base em bibliotecas Gnome com funções para produzir voz por meio de texto Ele suporta várias interfaces mas atualmente só está ativa nesse pacote a interface Festival exigindo Java ou outro software proprietário para sua utilização Disponível em httpwwwlinuxfromscratchorgblfsview63 gnomegnomespeechhtml 2 O Gnopernicus permite aos usuários com visão limitada ou nenhuma visão usar o desktop Gnome e suas aplicações Fornece um pacote de utilidade que consiste de um ampliador de tela tela de leitura de voz utilizando o sintetizador Festival e o uso de um teclado em braile para exibir o texto de saída Disponível em httpsdirectoryfsforgwikiGnopernicus 2 Kmagnifier é um ampliador de tela para Linux que funciona como uma lupa que amplia uma parte da tela Ele é usado por pes soas com deficiência visual além de indivíduos que trabalham no campo da análise de imagem de desenvolvimento web etc Disponível em httpkmagsourceforgenet 2 XZOOM é uma lupa de aumento disponível para qualquer dis tribuição com servidor gráfico que atualiza continuamente a área ampliada É rápido o suficiente para exibir pequenas animações Disponível em httplinuxaboutcomcslinux101gxzoomhtm 2 O SVGATextMode redimensiona linhas de texto em cartões con sole SVGA para Linux em modo texto Modifica o tamanho da fonte o cursor a sincronização horizontal e vertical etc Disponível em httpfreshmeatnetprojectssvgatextmode Qualidade e usabilidade de software 160 832 Deficiência motora Os softwares destacados a seguir são destinados para aqueles usuários que apresentam deficiência motora 2 Dasher é um software que permite a realização de uma gravação escrita por meio de uma previsão baseada no movimento do pon teiro do mouse que possibilita a substituição da escrita do teclado pelo movimento do mouse usando a inteligência artificial Disponível em httpwwwblttorgsoftwaredasher 2 GOK é um teclado alfanumérico virtual que permite aos usuários controlar computadores sem um teclado ou mouse padrão Os usuários especificam teclados e métodos de acesso em XML o que lhes permite modificar métodos existentes e criar novos definindo a largura a altura e o espaçamento das teclas bem como o feedback visual e auditivo sobre realce e seleção O GOK também cria dina micamente teclados para se adaptarem a uma situação específica religando os componentes de interface do usuário de aplicativos em execução diretamente dentro do sistema O usuário então tem acesso eficiente aos elementos da interface de usuário e não pre cisa navegar indiretamente através da interface de aceleradores de teclado O GOK também suporta a redefinição de menus de aplicativos e barras de ferramentas e inclui um teclado ativador de janela que lista as janelas atuais e permite que os usuários alternem entre elas Disponível em httpwwwgokca 2 O Xvoice possibilita que o usuário utilize a sua própria voz para controlar o uso de aplicativos Ele reconhece a voz do usuário e permite tanto executar ordens como controlar os comandos por meio de algumas aplicações do servidor gráfico Disponível em httpxvoicesourceforgenet 161 Acessibilidade e inclusão digital 2 OpenMindSpeech é um aplicativo de reconhecimento de voz que pretende ser compatível com KDE Gnome e todas as aplicações existentes para Linux Disponível em httpfreespeechsourceforgenet 2 O Clic é um software educativo que conta com diversas atividades como caçapalavras palavrascruzadas exercícios de texto etc Esse software possibilita que atividades sejam propostas também para o público que possui necessidades especiais Está disponível nas ver sões em espanhol e inglês Disponível em httpsclicxteccat 2 A Hawking Toolbar é um plugin de código aberto gratuito para o navegador Firefox Ele adiciona uma barra de ferramentas que torna as páginas da web acessíveis a usuários com limitações motoras por meio do uso de um ou mais switches de comando comutadores Disponível em httpwwwblttorgsoftwarefirefoxhawkinghtm Como se pode observar atualmente já existem várias ferramentas disponí veis para melhorar a acessibilidade de diversos públicos A liberdade oferecida pelos programas desenvolvidos e distribuídos como software é importante tanto nos casos das deficiências temporárias quanto das permanentes Mesmo assim apesar dos avanços na área da acessibilidade um dos gru pos menos levados em consideração pelos programadores ainda é o das pes soas com deficiência Atualmente um dos importantes recursos incorporados em aplicações de software é a personalização permitindo que os usuários as adaptem ao seu uso de acordo com as suas próprias necessidades E sistemas personalizáveis são particularmente importantes no caso da acessibilidade aos usuários que apresentam algum tipo de deficiência Somente com essa visão e conhecimento é possível que no futuro mais e mais desenvolvedores deem a atenção merecida à questão da acessibilidade Qualidade e usabilidade de software 162 Ampliando seus conhecimentos É notório o movimento cada vez mais intenso para que a população mundial tenha acesso aos conteúdos e ferramentas necessários à inclusão digital O texto apresentado a seguir problematiza justamente o significado do que vem a ser a inclusão digital na atualidade Inclusão digital ambiguidades em curso BONILA PRETTO 2011 p 2325 A compreensão e problematização do termo inclusão digital tem importância crucial no contexto contemporâneo uma vez que tem se constituído em pauta das políticas públicas e objeto das ações de diferentes instituições ONGs uni versidades empresas escolas Tanto pelos diferentes signi ficados atribuídos ao termo pelos diferentes atores sociais envolvidos quanto pelas resultantes socioculturais e polí ticas que emergem das ações e interações relacionadas A percepção dos sentidos construídos em torno da inclusão digital tornase fundamental Numa análise em nível global constatase que o termo inclusão digital entra em cena na dinâmica social e política da implanta ção dos chamados Programas Sociedade da Informação nos diversos países em especial naqueles que compõem a União Europeia UE Diversos estudos sociais políticos culturais e econômicos sobre as transformações que têm ocorrido na socie dade contemporânea em geral têm enfatizado a difusão cres cente das tecnologias da informação e comunicação em escala mundial Em muitos destes são enfatizados e criticados os con textos políticos nos quais nascem as proposições destinadas a construir em escala mundial uma Sociedade da Informação 163 Acessibilidade e inclusão digital O espaço políticoideológico das políticas de governo nacio nais e internacionais para o desenvolvimento do que se con vencionou denominar portanto Sociedade da Informação consolidase na década de 90 do século passado Na esteira desse movimento surgem os denominados Programas para a Sociedade da Informação notadamente aqueles empreendi dos pelos EUA EU e Organismos Internacionais entre os quais a União das Nações Unidas ONU e a União dos Estados Americanos OEA O Brasil incorpora a nova pauta em sua agenda política no ano de 2000 quando lança o Livro Verde Sociedade da Informação no Brasil TAKAHASHI 2000 É justamente no âmbito dessas iniciativas que se identificam as desigualda des quanto ao acesso de grandes contingentes populacionais às Tecnologias da Informação e Comunicação TIC Tais desigualdades vêm sendo denominadas genericamente como digital divide gap digital infoexclusão ou exclusão digital e têm justificado a formulação de numerosas políticas públicas com a finalidade de minimizálas O tema inclusão digital tem assim suscitado diversas discus sões Os significados e objetivos atribuídos ao termo têm motivado intensos debates na comunidade acadêmica Treinar pessoas para o uso dos recursos tecnológicos de comunicação digital seria inclusão digital Para alguns autores tais iniciativas não seriam suficientes para incluir digitalmente Democratizar o acesso a tais tecnologias seria então incluir digitalmente Não há consensos para tais questões No entanto em vista da relevância do fenômeno social relacionado tornase neces sário que o problematizemos Inicialmente analisando os discursos comumente associados ao tema podemos perceber sem muita dificuldade que o termo inclusão digital tem relação direta com o seu antagônico Qualidade e usabilidade de software 164 exclusão digital O dualismo inclusãoexclusão digital compõe os principais sentidos atribuídos aos referidos termos Para minimizar ou combater a exclusão das pessoas de uma dinâ mica social caracterizada pelo uso intensivo das tecnologias de base digital empreendese ações de inclusão digital Atividades 1 Defina a acessibilidade em seus diferentes contextos 2 O que é exclusão digital e quais são suas consequências 3 Quais conceitos estão presentes no desenvolvimento de sites acessíveis 4 Explique a relação entre inclusão digital e inclusão social Gabarito Qualidade e Usabilidade de Software 166 1 Qualidade de software 1 Um produto tem um ciclo de vida em que é concebido desenvolvi do entra em operação e sai de operação Um produto de software é concebido a partir do momento em que se percebe a necessidade da sua existência então um conjunto de requisitos é determinado e de senvolvido para que seja posto em operação Quando o produto não é mais necessário ou tornouse obsoleto seu ciclo de vida termina e ele é retirado de operação 2 Os requisitos descrevem ou expressam as características de um dado produto de software podendo ser funcionais ou não funcionais Re quisitos funcionais são aqueles que determinam o comportamento do produto de software de acordo com uma situação específica enquanto os requisitos não funcionais quantificam aspectos desse produto como por exemplo desempenho disponibilidade ou portabilidade Os re quisitos precisam ser especificados em um documento específico no qual se deve detalhar os requisitos explícitos e os requisitos normativos 3 Os erros relativos ao processo estão relacionados com processos infor mais ou processos oficiais rígidos e burocráticos Os erros mais comuns são desperdícios de tempo antes do início do projeto pressões por prazos otimistas e o não cumprimento destes por serem impossíveis falha no planejamento de projetos em que se omitem as estimativas de atividades como as de garantia da qualidade e a omissão da análise de riscos falha no método de gerir o projeto pressa para começar a etapa de codificação falha na subcontratação de serviços e entrega do produ to antes da hora sem estar pronto ou testado devidamente 4 O modelo codificaremenda é o mais utilizado porque com muita frequência um software é desenvolvido sem um projeto adequado e sem ser documentado corretamente Quando o analista ou o cliente identifica um problema ele é corrigido sem ser analisado sem que se 167 Gabarito verifique se esse problema está associado a outras questões Assim cor rigese um problema visível e criase uma trilha de erros no programa 2 Normas e padrões 1 As normas para os sistemas de gestão ajudam as organizações na ges tão de suas atividades O uso generalizado de normas é um prére quisito para a evolução de uma cultura de qualidade A normalização inclui o desenvolvimento e o estabelecimento de padrões e fornece informações sobre eles para as partes interessadas em vários níveis Empresas associações profissionais e consórcios podem desenvolver padrões para os seus próprios fins 2 SWCMM Capability Maturity Model Software é um modelo de maturidade de capacidades desenvolvido para processos relacionados com a produção e manutenção de sistemas de software Assim pode ser usado para dois fins 2 Melhorar os processos relacionados com a produção e manuten ção de software 2 Definir critérios para a determinação do nível de maturidade de uma organização que produz e mantém software 3 Sob três pontos de vista 2 operação do produto usálo 2 revisão do produto alterandoo 2 transição do produto modificandoo para trabalhar em um ambiente diferente 4 Inicial repetível definido gerenciado e otimizado Qualidade e Usabilidade de Software 168 3 Influência dos requisitos na qualidade do software 1 Não As empresas se diferenciam entre si pela sua capacidade de or ganização e processos de negócio Cada empresa utiliza um processo de negócio para chegar ao seu resultado e assim tem seus processos otimizados e relacionados aos seu produtofim 2 Os requisitos funcionais definem as funções que o sistema será capaz de executar e descrevem as transformações que o sistema executa nas entradas para produzir saídas Requisitos não funcionais têm a ver com as características que podem limitar o sistema tais como desem penho tempo e espaço interfaces de usuário fiabilidade robustez disponibilidade de equipamentos manutenção segurança portabi lidade e normas entre outros 3 Não pois o correto levantamento de requisitos é um processo coo perativo Para que a especificação gerada seja mais fiel à realidade é necessário haver comprometimento de todas as partes envolvidas em um projeto de desenvolvimento de software 4 O erro apontado na figura é que há um esforço para obter qualidade no desenvolvimento do software apenas na fase de testes do produto quando deveria estar presente em todas as fases do projeto inclusive na fase de especificação de requisitos 4 Processo de desenvolvimento de software 1 O ciclo de desenvolvimento de software fornece uma série de etapas a fim de projetar e desenvolver um produto de software de forma 169 Gabarito eficiente Existem vários tipos de modelos de ciclo de vida que se diferenciam principalmente pelo grau de controle aplicado sobre o processo em questão e pela visibilidade deste para o cliente no decor rer do projeto 2 A prototipagem evolutiva deve ser empregada quando o cliente não tem claros os requisitos do sistema sendo incapaz de detalhálo Ao realizar o protótipo a equipe de desenvolvimento torna o projeto mais concreto facilitando a sua compreensão 3 Métodos ágeis enfatizam a comunicação face a face em vez de do cumentação Equipes mais ágeis estão localizadas em um único es critório aberto às vezes chamado de plataformas de lançamento O escritório deve incluir revisores escritores de documentação de signers de iteração e gerentes de projeto Métodos ágeis também enfatizam que o software seja funcional 4 Os principais indicadores segundo Pfleeger 2004 são funcionalida de confiabilidade usabilidade e eficiência No funcionalidade estão implícitas as seguintes características adequação acurácia interopera bilidade segurança de acesso e conformidade A confiabilidade precisa estar em concordância com os seguintes critérios maturidade capaci dade de recuperação e tolerância a falhas Já a usabilidade corresponde aos critérios de aprendizagem compreensibilidade operacionalidade e atratividade Por fim a eficiência se relaciona aos critérios de compor tamento ao longo do tempo e comportamento do recurso 5 Gerência da qualidade de software 1 Tangibilidade confiabilidade sensibilidade garantia e empatia Qualidade e Usabilidade de Software 170 2 O controle de qualidade é uma série de avaliações e testes utilizados para todo o ciclo de desenvolvimento do produto a fim de garantir que ele atenda aos requisitos que lhe foram atribuídos 3 As atividades da gestão de testes de software são controlar e acom panhar mudanças controle de mudança registrar a evolução do projeto controle de versão e estabelecer a integridade do sistema integração contínua 4 A gerência de qualidade deve ser independente da gestão do projeto porque ela pode avaliar de forma objetiva os problemas que existem no software A gestão do projeto e a equipe de desenvolvedores não têm o distanciamento para fazer uma avaliação eficaz dos problemas pois estão envolvidas emocionalmente com o projeto e em vez de apontar os defeitos acabam defendendo as qualidades do produto 6 Fundamentos da interação homemcomputador IHC 1 Usabilidade viabilidade e acessibilidade 2 Teoria da atividade design centrado no usuário além dos princípios do design de interface 3 Utilidade usabilidade desejo encontrabilidade acessibilidade cre dibilidade valor 4 A IHC articula um grande número de conhecimentos advindos de áreas diversas É difícil encontrar um profissional que tenha conhe cimento de todas essas áreas sendo necessária uma equipe multi 171 Gabarito disciplinar que trabalhe em conjunto o que também constitui um desafio para toda a equipe e os gestores 7 Usabilidade de software 1 O termo usabilidade referese à facilidade com que as pessoas podem uti lizar uma ferramenta A usabilidade é considerada um atributo de qua lidade que avalia a facilidade com que uma interface gráfica de software é utilizada Ela também se refere à aplicação de métodos durante um processo de design para melhorar essa utilização NIELSEN 1993 2 Facilidade de aprendizado facilidade de uso flexibilidade em relação às possibilidades que o usuário e o sistema têm de trocar informações e robustez 3 A usabilidade de um sistema é atingida quando recomendações de usa bilidade são obedecidas desde o projeto inicial do software Quando isso ocorre o sistema apresenta atributos relacionados à usabilidade como a facilidade de aprendizado a eficiência de uso a facilidade de memorização a baixa taxa de erros e a satisfação subjetiva 4 A facilidade de leitura das informações proporcionada pela usabilida de ajuda na presteza e na redução de custo no desenvolvimento de ati vidades Portanto as recomendações de usabilidade vão além da fácil utilização de um software trazendo benefícios aos projetos internos das empresas Nesse caso a ênfase na usabilidade pode representar uma redução significativa do orçamento em treinamento e a duplica ção de desempenho de funcionários horistas o que significaria uma duplicação de vendas e o aumento do número de usuários registra dos Os custos com manutenção e revisão também são reduzidos e o Qualidade e Usabilidade de Software 172 produto é mais bem aceito pelos usuários por todas as qualidades de usabilidade que apresenta aumentando a probabilidade de recomen dação a possíveis usuários 8 Acessibilidade e inclusão digital 1 Acessibilidade ao ambiente físico referese à qualidade que os espaços disponibilizam a todos inclusive nos casos de deficiência de mobili dade ou comunicação incluindo a possibilidade de chegar a todos os lugares e edifícios sem esforço excessivo e autonomia acessar as instala ções de uso público e serviços fornecidos com segurança e autonomia O Decreto n 5296 define a acessibilidade como condição para uti lização com segurança e autonomia total ou assistida dos espaços mobiliários e equipamentos urbanos das edificações dos serviços de transporte e dos dispositivos sistemas e meios de comunicação e in formação por pessoa portadora de deficiência ou com mobilidade reduzida BRASIL 2004 Em paralelo no caso da web e da internet em geral a acessibilidade se refere ao conjunto de elementos que facilitam o acesso à informação a todas as pessoas de modo igualitário usando a tecnologia compu tadores tablets telefones móveis entre outros independentemente das necessidades especiais dos usuários físicas mentais sensoriais e outras NIELSEN TAHIR 2002 Já de acordo com o Livro Verde do Ministério da Ciência e Tecno logia TAKAHASHI 2000 a acessibilidade à informação e ao co nhecimento é a variável de maior poder de exclusão ou inclusão dos indivíduos no processo político e econômico 173 Gabarito 2 Exclusão digital é o termo usado para se referir à consequência dire ta do abismo tecnológico que existe entre as comunidades que têm acesso à tecnologia da informação e aquelas que são excluídas desse processo As diferenças podem ser socioeconômicas ou a capacidade de usar a tecnologia da informação de forma eficaz devido aos dife rentes níveis de alfabetização e deficiência 3 Conceito de camadas conceito de tableless e conceito de semântica Conceito de camadas Representa o uso adequado das tecnologias ou seja cada tecnologia deve ser utilizada com o propósito único ao qual foi criada Por exemplo o HTML é utilizado apenas para a cria ção de conteúdo enquanto a apresentação visual é criada por meio do CSS Já o comportamento é definido pelas linguagens de script Conceito de tableless As tabelas devem ser usadas apenas para dados tabulares e não para fins de layout Esse conceito surgiu devido ao uso excessivo de tabelas para apresentação visual do site O uso de tabe las para a estruturação da página prejudica a apresentação da página em determinadas resoluções de tela deixa a página mais pesada tem como consequência um código de difícil manutenção além de causar problemas de acessibilidade Conceito de semântica Representa o uso correto das tags HTML pois cada tag possui um objetivo específico e para tal deve ser uti lizado Essa validação encontrará os erros de concordância entre o código criado e as recomendações e fornecerá ao desenvolvedor a forma de corrigilo 4 Um aspecto importante nessa relação é a consciência social a web deve ser entendida como algo universal e essa universalidade deve Qualidade e Usabilidade de Software 174 levar em conta o acesso por qualquer pessoa às informações forne cidas online As empresas devem se atentar a esse contexto de inclusão social porque o fato de ter um site acessível a todas as pessoas independentemente de conhecimento pessoal ou deficiências dos usuários e das caracterís ticas técnicas dos equipamentos utilizados é uma vantagem social sobre a concorrência e um diferenciador NIELSEN TAHIR 2002 Assim toda a sociedade pode ter acesso ao conteúdo disponível na internet e com isso produzir e disseminar conhecimento A inclu são digital está portanto inserida no movimento de inclusão social sendo ela um dos principais objetivos partilhados por vários governos ao redor do mundo nas últimas décadas WARSCHAUER 2006 175 Referências Referências Qualidade e usabilidade de software 176 ABNT Associação Brasileira de Normas Técnicas NBR ISO 90012000 Sistemas de Gestão da Qualidade requisitos Rio de Janeiro 2000 NBR ISO 924111 Requisitos ergonômicos para trabalho de escri tórios com computadores Rio de Janeiro 2002 NBR ISOIEC 91261 Engenharia de software qualidade de pro duto Rio de Janeiro 2003 NBR ISO 90012008 Sistemas de gestão da qualidade requisitos Rio de Janeiro 2008 NBR ISO 90012015 Sistemas de gestão da qualidade requisitos Rio de Janeiro 2015 ANDRADE A Usabilidade de interfaces web avaliação heurística no jor nalismo online Rio de Janeiro Epapers 2007 ARANTES I L V FIDELIS I S AZEVEDO W A Projeto Integrador 20171 Tecnologia em Gestão de TI Faculdade de Tecnologia SenacGO Goiânia 2017 Disponível em httpgtiprojetointegradorcom br152M154200121Modulo5Auditoria20e20Qualidade20de20 SoftwarePI2020Auditoria20e20Qualidade20de20Software pdf Acesso em 2 ago 2017 AZUMA R A survey of augmented reality Presence Teleoperators and Virtual Environments v 6 n 4 p 355385 Aug 2007 Disponível em httpwwwcsunceduazumaARpresencepdf Acesso em 3 ago 2017 BARBOSA S D J Interação humanocomputador Rio de Janeiro Elsevier 2011 BARTIÉ A Garantia da qualidade de software adquirindo maturidade organizacional Rio de Janeiro Elsevier 2002 BENYON D Interação humanocomputador 2 ed São Paulo Pearson Prentice Hall 2011 BONILA M H S PRETTO N de L Org Inclusão digital polêmica contemporânea Salvador EdUFBA 2011 v 2 177 Referências BOULDING E A et al Um modelo de processo dinâmico de qualidade do serviço a partir de expectativas para as intenções comportamentais Journal of Marketing Research n 30 p 727 2003 BRANDÃO E R Publicidade online ergonomia e usabilidade o efeito de seis tipos de banner no processo humano de visualização do formato do anúncio na tela do computador e de lembrança da sua mensagem 2006 400 f Dissertação Mestrado Departamento de Artes Design Pontifícia Universidade Católica do Rio de Janeiro Rio de Janeiro 2006 BRASIL Lei n 10098 de 19 de dezembro de 2000 Estabelece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas porta doras de deficiência ou com mobilidade reduzida e dá outras providências Diário Oficial da União Brasília DF 20 dez 2000 Decreto n 5296 de 2 de dezembro de 2004 Regulamenta as Leis n 10048 de 8 de novembro de 2000 que dá prioridade de atendimento às pessoas que especifica e 10098 de 19 de dezembro de 2000 que estabe lece normas gerais e critérios básicos para a promoção da acessibilidade das pessoas portadoras de deficiência ou com mobilidade reduzida e dá outras providências Diário Oficial da União Brasília DF 3 dez 2004 BRITO G S Uma análise sobre a implantação de laboratórios de informática nas escolas de 1º grau 1997 122 f Dissertação Mestrado em Tecnologia Programa de Pósgraduação em Tecnologia Centro Federal de Educação Tecnológica do Paraná Curitiba 1997 Disponível em httpdspacec3slufprbrdspacebitstreamhandle188411296 DissertaC3A7C3A3o20MARILUCI20ZANELApdfse quence1 Acesso em 9 fev 2017 CAIÇARA JUNIOR C Informática internet e aplicativos Curitiba Ibpex 2007 CAMPOS F M Qualidade qualidade de software e garantia da quali dade de software são as mesmas coisas Disponível em httpwwwlinha decodigocombrartigo1712qualidadequalidadedesoftwareegarantia daqualidadedesoftwaresaoasmesmascoisasaspxixzz4WjF9RTkw Acesso em 13 jan 2017 Qualidade e usabilidade de software 178 CARNEGIE MELLON UNIVERSITY CMMI para desenvolvimento versão 12 ago 2006 Disponível em httpwwwseicmuedulibrary assetswhitepaperscmmidev12portuguesepdf Acesso em 3 ago 2017 CAVANO J P MCCALL J A Proceedings of the Software Quality Assurance Workshop on Functional and Performance Issues San Diego 1978 CMMI INSTITUTE Disponível em httpcmmiinstitutecomcapabi litymaturitymodelintegration Acesso em 19 jul 2017 CRAIG R D JASKIEL S P Systematic Software Testing Boston Artech House Publishers 2002 CYBIS W et al Ergonomia e usabilidade conhecimentos métodos e apli cações 3 ed São Paulo Novatec 2015 DARIVA R Gerenciamento de dispositivos móveis e serviços de telecom saiba tudo sobre aplicativos móveis gerenciamento de dispositivos móveis e gerenciamento de custos de telecom Rio de Janeiro Elsevier 2011 DEMO P Pesquisa e construção do conhecimento metodologia científica no caminho de Habermas 2 ed Rio de Janeiro Tempo Brasileiro 2005 Marginalização digital Digital Divide Boletim Técnico do Senac a Revista da Educação Profissional Rio de Janeiro v 33 n 2 p 519 2007 Disponível em httpsrevistasutfpredubrrecitarticleview4256 Acesso em 26 jan 2017 ERICSSON K A SIMON H A Protocol Analysis verbal reports asdata Cambridge MA MIT Press 1993 FAGUNDES R M Engenharia de requisitos do perfil do analista de requisitos ao desenvolvimento de requisitos com UML e RUP Salvador 2011 Disponível em httpsbooksgooglecombrbooksidi2pIB QAAQBAJprintsecfrontcoverdqengenhariadosrequisitoshlp tBRsaXved0ahUKEwis6MX925PVAhXMIpAKHddiBhcQ6AEIK TABvonepageqffalse Disponível em 19 jul 2017 179 Referências GANDARA F Qualidade e teste em software São Paulo Clube dos Autores 2012 GARVIN D A Gerenciando a qualidade a visão estratégica e competitiva Rio de Janeiro Qualitymark 2015 GODOI NETO et al A importância do ciclo de vida no desenvolvimento de software Disponível em httprevistaconexaoaemsedubrwpcon tentpluginsdownloadattachmentsincludesdownloadphpid993 Acesso em 14 ago 2017 HAMPSON P J MORRIS P E Understanding Cognition Cambridge MA Blackwell Publishers 1996 IBM Web accessibility for special needs Disponível em httpwww austinibmcomsnsacesswebhtml Acesso em 9 fev 2017 IEEE IEEE Standard for Software Reviews Washington DC IEEE Computer Society 1997 Std 8301998 Práticas Recomendadas para Especificação de Requisitos de Software Washington DC IEEE Computer Society 1998 INMETRO Avaliação da conformidade Disponível em httpwww inmetrogovbrnoticiasconteudoacasp Acesso em 25 jul 2017 ISD BRASIL O que é SCAMPI Disponível em httpwwwisdbrasil combroqueescampiphp Acesso em 3 ago 2017 JOHNSTON R The determinants of service quality satisfiers and dissatis fiers International Journal of Service Industry Management v 6 n 5 p 5371 1995 JORDAN P W An Introduction to Usability Londres Taylor Francis 1998 KOSCIANSKI A SOARES M dos S Qualidade de software aprenda as meto dologias e técnicas mais modernas para o desenvolvimento de software 2007 LAUDON K LAUDON J Sistemas de informação gerenciais São Paulo Pearson Prentice Hall 2004 Qualidade e usabilidade de software 180 LAUDON Kenneth LAUDON Jane Sistemas de informação gerenciais São Paulo Pearson Prentice Hall 2004 LEITE J C Design conceitual de software Universidade Federal do Rio Grande do Norte Natal 2000 Notas de aula Disponível em httpswww dimapufrnbrjairESc5html Acesso em 7 ago 2017 LÉVY P Cibercultura Trad C I da Costa 1 ed São Paulo Ed 34 2000 MARÇAL A S C et al Estendendo o Scrum segundo as áreas de pro cesso de gerenciamento de projetos do CMMI Disponível em https wwwinfufesbrmonalessaPaginaMonalessaNEMOESMestrado ArtigosEstendendoScrumSegundoAreasDeGerenciaNoCMMIpdf Acesso em 28 jul 2017 MARINHO J J Análise e desenvolvimento de requisitos em histórias em quadrinhos Parte 2 a obscura diferença entre requisitos funcionais e requisi tos não funcionais TI Especialistas 18 nov 2015 Disponível em https wwwtiespecialistascombr201511analiseelevantamentoderequisitos emhistoriasemquadrinhosparte2obscuradiferencaentrerequisitos funcionaiserequisitosnaofuncionais Acesso em 7 ago 2017 MARSHALL JUNIOR I et al Gestão da qualidade e processos Rio de Janeiro Ed da FGV 2012 MARTINS J C C Gerenciando projetos de desenvolvimento de software com PMI RUP e UML 5 ed Rio de Janeiro Brasport 2010 MATTHEWS J R The Customerfocused Library reinventing the library from the outsidein Santa Barbara CA Libraries Unlimited 2009 MAYHEW D J Principles and Guidelines in Software User Interface Design New Jersey PTR Prentice Hall 1992 MELO A M Design inclusivo de sistemas de informação na web 2007 339 f Tese Doutorado em Ciência da Computação Instituto de Computação Universidade Estadual de Campinas Campinas 2007 MENEGUELLI F O novo perfil do professor usar as novas tecnologias Nova Escola São Paulo ano 25 n 236 p 49 out 2010 181 Referências MORIN E Os setes saberes necessários à educação do futuro 2 ed São Paulo CortezUnesco 1998 MOUNTAIN GOAT SOFTWARE The Scrum development process Disponível em httpwwwmountaingoatsoftwarecomSc Acesso em 1 fev 2017 NEIL T Padrões de design para aplicativos móveis São Paulo Novatec 2012 NIELSEN J Usability Enginnering San Francisco CA Morgan Kaufmann 1993 NIELSEN J TAHIR M Homepage usabilidade 50 websites desconstruí dos Rio de Janeiro Campus 2002 PARASURAMAN A ZEITHAML V A BERRY L L Um modelo con ceitual de qualidade de serviço e suas implicações para futuras pesquisas Journal of Marketing n 49 p 4150 2005 PEIRCE C S Semiótica Trad de J T Coelho Neto 3 ed São Paulo Perspectiva 2005 PFLEEGER S L Engenharia de software teoria e prática 2 ed São Paulo Pearson Prentice Hall 2004 PORTAL BRASIL Práticas web acessíveis Disponível em http emaggovernoeletronicogovbrcursodesenvolvedordesenvolvimentoweb praticaswebacessivelmarcacaohtml Acesso em 9 fev 2017 PREECE J ROGERS Y SHARP H Design de interação além da inte ração homemcomputador Trad de V Possamai Porto Alegre Bookman 2005 PRESSMAN R S MAXIM B R Engenharia de software uma aborda gem profissional 8 ed Porto Alegre AMGH Bookman 2016 PUCRIO Técnicas para avaliação de usabilidade Disponível em httpswwwmaxwellvracpucriobr21839218394PDF Acesso em 8 ago 2017 Qualidade e usabilidade de software 182 REZENDE D A Engenharia de software e sistemas de informação 3 ed Rio de Janeiro Brasport 2005 ROGERS Y SHARP H PREECE J Design de interação além da interação homemcomputador Trad de I Gasparini 3 ed Porto Alegre Bookman 2013 SAWAYA M R Dicionário de informática e internet São Paulo Nobel 1999 SCHACH S R Engenharia de software os paradigmas clássico e orien tado a objetos Tradução de A Griesi 7 ed Porto Alegre AMGH 2010 SCHNEIDER H N Ergonomia das interfaces humanocomputador como princípio de qualidade em EAD Disponível em httpwww uecebrendipe2014ebookslivro42320ERGONOMIA20DAS20 INTERFACES20HUMANOCOMPUTADOR20COMO20 PRINCC38DPIO20DE20QUALIDADE20EM20EaDpdf Acesso em 7 ago 2017 SCHWABER K Agile Project Management with Scrum Redmond WA Microsoft Press Books 2004 SCHWARTZ G Educação como produção colaborativa de conteúdo In ENCONTRO NACIONAL DAS ESCOLAS DE GOVERNO 11 2010 São Paulo Anais São Paulo Fundap 2010 Disponível em httpwww fundapspgovbregdialogalpdfApresentaC3A7C3A3o2020 texto20Gilson20Schuartz200906pdf Acesso em 8 ago 2017 SILVA R B C AZEVÊDO L S L A importância da engenharia de tes tes para a qualidade de software Revista Eletrônica Científica Inovação e Tecnologia v 2 n 12 juldez 2015 SILVEIRA S A A noção de exclusão digital diante das exigências de uma cibercidadania In HETKOWSKI T M Org Políticas públicas e inclu são digital Salvador EdUFBA 2008 SOMMERVILLE I Engenharia de software 9 ed São Paulo Pearson Prentice Hall 2011 183 Referências SOUZA C S de et al Projeto de interfaces de usuário perspectivas cognitiva e semiótica In JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA 19 CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO 1999 Rio de Janeiro Anais Rio de Janeiro 1999 SUTHERLAND J Scrum a arte de fazer o dobro do trabalho na metade do tempo Trad de N Gerhardt São Paulo LeYa 2014 TAKAHASHI T Org Sociedade da informação no Brasil Livro Verde Brasília Ministério da Ciência e Tecnologia 2000 Disponível em https wwwgovernoeletronicogovbrdocumentosearquivoslivroverdepdf Acesso em 4 ago 2017 TORRES L F Fundamentos do gerenciamento de projetos Rio de Janeiro Elsevier 2014 VALERIANO D Moderno gerenciamento de projetos São Paulo Pearson Prentice Hall 2005 VASQUEZ C E SIMÕES G S Engenharia de requisitos software orientado ao negócio Rio de Janeiro Brasport 2016 WARSCHAUER M Tecnologia e inclusão social a exclusão digital em debate São Paulo SenacSP 2006 WAZLAWICK R S Análise de sistemas de informações orientados a objetos Rio de Janeiro Elsevier 2011 Engenharia de software conceitos e práticas Rio de Janeiro Elsevier 2013 WEBER K C Qualidade e produtividade em software São Paulo Makron Books 2006 Qualidade e produtividade em software 4 ed São Paulo Makron Books 2012 QUALIDADE E USABILIDADE DE SOFTWARE Christina Paula de Camargo Curcio Tecnologia QUALIDADE E USABILIDADE DE SOFTWARE Christina Paula de Camargo Curcio Neste livro vamos apresentar os conceitos fundamentais relacionados à quali dade de software métricas normas e orientações sobre a gestão da qualida de Após este estudo esperamos que você tenha facilidade para reconhecer a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus próprios projetos identificando os requisitos necessários para o desenvolvi mento de um software com qualidade Fundação Biblioteca Nacional ISBN 9788538762966 9 788538 762966 CAPAQualidade e Usabilidade de Softwareindd 1 17082017 100901