Qualidade de Software

Introdução à qualidade de software

Olá, estudante! Bem-vindo à aula que aprofundará seus conhecimentos sobre Qualidade de Software. Exploraremos conceitos-chave, adentrando na Garantia de Qualidade de Software (SQA) e investigando as métricas que delineiam o padrão de excelência. Estes insights são indispensáveis para aprimorar a entrega de produtos de software confiáveis. Esteja preparado para adquirir as habilidades necessárias e garantir qualidade em todas as fases de sua prática profissional.

Ponto de Partida

Caro estudante, certamente você já deve ter procurado um aplicativo para resolver determinado problema, ou comprado um serviço ou produto, que, quando foi entregue, estava muito aquém do esperado. Pois bem, como usuário você deve ter percebido que sua concepção sobre a empresa, após a decepção, mudou radicalmente. Porém, nesse momento, seu papel não é mais somente o de usuário, mas o de profissional de TI, o qual deve utilizar as técnicas de desenvolvimento de software para evitar tais situações.

Uma das técnicas para esse fim está relacionada com a qualidade de software e com suas ferramentas. Essa área do conhecimento da engenharia de software se preocupa em utilizar métodos, processos e normas nas atividades de desenvolvimento de software, a fim de se agregar qualidade nos processos e produtos finais. Para isso, é necessário que se tenha conhecimentos acerca de qualidade de software, qualidade do produto e qualidade dos processos. Como você pode ter percebido, existem diversas competências necessárias para se garantir a qualidade de um desenvolvimento.

Agora que você já se convenceu que a qualidade de software é indispensável, vamos supor que uma empresa de consultoria em tecnologia está encarregada de desenvolver um sistema integrado de gestão para uma grande corporação. O projeto enfrenta desafios relacionados à complexidade, prazos apertados e expectativas elevadas do cliente. Diante desse cenário, a equipe decide implementar práticas robustas de Garantia de Qualidade de Software (SQA) para assegurar a entrega de um produto confiável e de alta qualidade.

Os seguintes desafios são identificados:

• Garantir a conformidade com os requisitos do cliente.
• Identificar e mitigar riscos relacionados ao desenvolvimento.
• Estabelecer padrões de qualidade ao longo do ciclo de vida do software.

Sabendo disso, estratégias e práticas de SQA podem ser implementadas por essa empresa, além de apresentar uma síntese do resultado.

Vamos Começar!

Conceitos de Qualidade de software

Até mesmo os programadores mais experientes concordam que alcançar um software de alta qualidade é um objetivo fundamental. Contudo, surge a dúvida sobre como definir essa qualidade. De maneira geral, a qualidade de software pode ser descrita como a aplicação eficaz de gestão de qualidade, visando criar um produto útil que ofereça valor mensurável tanto para os desenvolvedores quanto para os usuários finais.

Um produto de alta qualidade deve ser útil, atendendo às exigências explícitas e implícitas dos usuários, proporcionando confiabilidade. Isso gera benefícios para a empresa, reduzindo manutenção e suporte, permitindo mais inovação. A comunidade de usuários também se beneficia, agilizando processos de negócio. O resultado é maior receita, rentabilidade e disponibilidade de informações cruciais.

O termo "qualidade de software" é comumente definido como a combinação de conformidade funcional e desempenho conforme as expectativas do patrocinador. No entanto, de acordo com Sommerville (2018), a abordagem à qualidade no desenvolvimento de software deve ser mais abrangente, considerando-a em três níveis distintos:

1. Organizacional: este nível amplo concentra-se no estabelecimento de padrões de trabalho para o desenvolvimento de software, incorporando as melhores práticas para minimizar erros e falhas.
2. Projeto: envolve o desenvolvimento baseado em padrões estabelecidos por gestores de projetos, variando de acordo com as peculiaridades do projeto, a política da empresa e o uso de frameworks, entre outros fatores.
3. Planejamento: exige a elaboração de um plano de qualidade, com uma equipe designada para verificar os requisitos acordados. Tanto os processos quanto os produtos desenvolvidos devem passar por revisões para evitar falhas inadvertidas.

Para esclarecer aspectos que impactam diretamente na qualidade, é fundamental observar de que maneira esses elementos se manifestam.

Falhas de Software

Uma falha de software pode manifestar-se como um comportamento inesperado do sistema, resultante de um ou mais erros (Zanin et al., 2018). Para uma compreensão mais aprofundada sobre como essa falha pode impactar um sistema, recomenda-se observar a Figura 1.

Neste exemplo, o sistema gera uma mensagem de erro, impedindo o cadastro de um novo cliente, já que a confirmação do aceite é essencial para concluir o processo. Esse impacto é significativo para o usuário, especialmente se o sistema pertencer a uma loja de departamentos que depende dele para realizar vendas e emitir notas fiscais. O prejuízo resultante seria considerável e preocupante.

É importante destacar que cabe ao desenvolvedor a responsabilidade pela implementação das rotinas destinadas a lidar com falhas e erros. Essas situações podem ser comunicadas ao usuário por meio de mensagens, redirecionamento para uma nova página com imagens indicativas de falhas, ou ainda, utilizando um sistema de relatório para encaminhar os problemas a um repositório, visando ajustes por parte dos desenvolvedores.

Erros de Software

Grande parte dos erros de software estão relacionados a execuções incorretas, o que faz com que os resultados gerados não reflitam a verdade (Zanin et al., 2018). Um exemplo pode ser observado na Figura 2.

Neste exemplo, atente-se para a comparação entre a data do sistema e a data indicada no relógio. Um erro na data do sistema pode acarretar um impacto significativo na integridade dos dados, resultando em registros que não são confiáveis quanto à sua data. Em setores como vendas, logística, contabilidade e fiscal, tal situação pode ser desastrosa. 

Defeito de Software

O defeito de software refere-se a uma implementação incorreta, resultando em erro, interrupção de serviço ou mau funcionamento. Um exemplo seria um sistema de cadastro que, mesmo após o preenchimento dos campos obrigatórios sem retorno de erros, falha em inserir as informações no banco de dados (Zanin et al., 2018).

Quanto às atividades de desenvolvimento, localizar defeitos é mais desafiador, pois em alguns casos, erros de lógica, falhas na escrita do código ou outras referências não fornecem pistas claras para ajudar o desenvolvedor a identificar o problema.

Bugs

Esse termo tornou-se comum entre os jovens para descrever comportamentos inesperados de softwares. Conforme Zanin et al. (2018), um bug de sistema refere-se a erros e falhas inesperados, geralmente mais complexos, exigindo maior tempo e conhecimento técnico para identificação e resolução.

Um problema que causou preocupação significativa entre os administradores de sistemas foi o bug do milênio. Em 1999, havia apreensão sobre o impacto nos sistemas durante a transição de ano, pois os sistemas mais antigos interpretavam apenas os dois últimos dígitos do ano. Isso poderia resultar em uma leitura errônea, levando o sistema, em vez de para o ano 2000, a retroceder para o ano 1900. Daí o nome "Bug do Milênio".

Agora que você entendeu a conexão entre a qualidade de software e os processos de desenvolvimento computacional, certamente surgirá a clássica dúvida: como podemos assegurar a qualidade de um software? Para compreender os aspectos relacionados à garantia da qualidade dos softwares, é importante, neste momento, ampliar a visão além das funcionalidades, desempenho, escalabilidade, entre outros. Isso implica considerar a qualidade dos processos envolvidos no desenvolvimento, teste e liberação para utilização.

Siga em Frente...

Garantia de qualidade de software

A garantia da qualidade conhecida como Software Quality Assurance (SQA). Sua abrangência permeia todo o ciclo de vida do projeto de desenvolvimento de software e requer (Sommerville, 2018):

• A utilização de ferramentas e/ou métodos que viabilizem a análise dos desenvolvimentos e dos testes.
• A condução de revisões técnicas nos componentes e na funcionalidade, sendo realizadas em cada uma das fases do ciclo.
• O controle documental por meio de procedimentos de versionamento.
• A aplicação de métodos para assegurar padrões de desenvolvimento e boas práticas que atendam às exigências das equipes de desenvolvimento.
• A implementação de mecanismos de aferição.

Conforme destacado por Pressman (2021), a garantia da qualidade refere-se aos procedimentos, aos métodos e às ferramentas empregados por profissionais de Tecnologia da Informação para garantir padrões previamente estabelecidos entre as partes ao longo de todo o ciclo de vida do desenvolvimento de um software. É saliente que os padrões de qualidade podem variar conforme as características específicas de cada projeto, e, portanto, a garantia da qualidade deve pautar-se pelos acordos estabelecidos entre as partes envolvidas.

A Figura 3 apresenta os seguintes elementos da SQA: (1) um processo dedicado à SQA; (2) tarefas específicas voltadas para garantia e controle da qualidade, incluindo revisões técnicas e uma estratégia de testes multicamadas; (3) a implementação eficaz de práticas de engenharia de software, compreendendo métodos e ferramentas; (4) o controle abrangente de todos os artefatos de software e das alterações realizadas nesses produtos; (5) um procedimento destinado a assegurar a conformidade com os padrões de desenvolvimento de software, quando aplicáveis; e (6) mecanismos de medição e geração de relatórios.

A garantia de qualidade de software abrange diversas preocupações e atividades relacionadas à gestão da qualidade de software. As principais áreas incluem (Pressman, 2021):

• Padrões: garantir que os padrões estabelecidos por organizações como o IEEE e a ISO sejam seguidos na engenharia de software, seja por escolha da organização ou da imposição de clientes.
• Revisões e Auditorias: realizar revisões técnicas para identificar erros e auditorias para assegurar a conformidade com diretrizes de qualidade no trabalho de engenharia de software.
• Testes de Software: garantir o planejamento e a execução eficiente de testes para encontrar erros e alcançar os objetivos de qualidade.
• Coleta e Análise de Erros/Defeitos: medir o desempenho mediante coleta e análise de dados de erros para entender como são introduzidos e quais atividades são mais eficazes para sua eliminação.
• Gerenciamento de Mudanças: assegurar que práticas adequadas de gerenciamento de mudanças sejam implementadas para evitar confusões e garantir qualidade.
• Educação: liderar o aperfeiçoamento do software por meio da educação contínua de engenheiros de software, gerentes e outros envolvidos.
• Gerência dos Fornecedores: garantir a qualidade do software adquirido de fornecedores externos, sugerindo práticas de garantia de qualidade e incorporando requisitos de qualidade em contratos.
• Administração da Segurança: implementar políticas de segurança para proteger dados em todos os níveis e garantir a segurança do software contra alterações não autorizadas.
• Proteção: avaliar o impacto de falhas de software, especialmente em sistemas críticos, e iniciar medidas para redução de riscos.
• Gestão de Riscos: assegurar que as atividades de gestão de riscos sejam conduzidas adequadamente e que planos de contingência relacionados a riscos sejam estabelecidos.

Além disso, a SQA trabalha para garantir que atividades de suporte ao software, como manutenção, suporte on-line, documentação e manuais, sejam realizadas com qualidade como preocupação principal. 

Métricas de qualidade

A medição de software envolve derivar valores numéricos ou perfis para atributos de componentes de software, sistemas ou processos. Esses valores são comparados entre si e com padrões para avaliar a eficácia de métodos, ferramentas e processos de software. Por exemplo, ao introduzir uma nova ferramenta de teste, é possível registrar o número de defeitos antes e depois do uso da ferramenta para avaliar sua eficácia.

O objetivo a longo prazo da medição de software é substituir revisões para julgar a qualidade do software. Idealmente, métricas de software podem ser usadas para avaliar sistemas com base em diversas métricas, deduzindo um valor para a qualidade. No entanto, apesar dessa aspiração, avaliações automatizadas de qualidade ainda não estão próximas de se tornarem realidade (Sommerville, 2018).

Métricas de software são características mensuráveis de um sistema, uma documentação ou um processo de desenvolvimento. Podem ser métricas de controle, relacionadas aos processos de gerenciamento, ou às métricas de previsão, associadas às características do software. Exemplos incluem o tamanho do código, índice Fog (medida de legibilidade), número de defeitos relatados e complexidade ciclomática de um módulo.

As métricas de controle e previsão desempenham um papel crucial na tomada de decisões de gerenciamento, conforme ilustrado na Figura 4. As métricas de processo guiam os gerentes ao determinar se alterações no processo são necessárias, enquanto as métricas de previsão ajudam a estimar o esforço necessário para implementar mudanças no software (Sommerville, 2018).

Há duas abordagens para o uso de medições em um software de sistema (Sommerville, 2018):

• Atribuir valores aos atributos de qualidade do sistema, avaliando características individuais dos componentes do sistema, como sua complexidade ciclomática, e agregando essas medições para avaliar atributos de qualidade do sistema, como manutenibilidade.
• Identificar os componentes do sistema que não atendem aos padrões de qualidade. As medições podem destacar componentes individuais com características que se desviam da norma. Por exemplo, medir a complexidade de componentes pode revelar aqueles com maior propensão a bugs devido à dificuldade de compreensão associada à alta complexidade.

Vamos Exercitar?

A Garantia da Qualidade de Software (SQA) desempenha um papel essencial na engenharia de software, sendo crucial para assegurar a entrega de um produto confiável e de alta qualidade. Ao estabelecer padrões, diretrizes e práticas robustas ao longo do ciclo de vida do desenvolvimento de software, a SQA visa garantir a conformidade com os requisitos do cliente, identificar e mitigar riscos, e estabelecer uma base sólida para a produção de software de excelência. A implementação efetiva de práticas de SQA resulta em benefícios tangíveis, incluindo a redução de defeitos, a otimização do desempenho, e a melhoria da satisfação do cliente. Além disso, ao criar uma cultura de avaliação contínua, treinamento e inovação, a SQA contribui para o desenvolvimento de produtos que atendem não apenas às expectativas, mas também estabelecem padrões elevados de qualidade na indústria de software. Sabendo disso, uma possível solução para a problematização proposta, está descrita a seguir:

Estratégias e Práticas de SQA Implementadas

1. Definição de Padrões e Diretrizes:

• Estabelecimento de normas para codificação, documentação e testes.
• Utilização de padrões reconhecidos, como ISO/IEC 25010, para orientar o desenvolvimento.

2. Revisões e Auditorias:

• Realização de revisões de código e auditorias de processos regularmente.
• Envolvimento de uma equipe independente para garantir imparcialidade.

3. Testes Abrangentes:

• Desenvolvimento de planos de teste abrangentes, incluindo testes unitários, de integração e de sistema.
•  Automação de testes sempre que possível para garantir consistência e eficiência.

4. Gestão de Mudanças:

• Implementação de um sistema eficaz de controle de mudanças.
• Avaliação de impacto e revisões sistemáticas antes da aprovação de alterações.

5. Treinamento Contínuo:

• Oferta de treinamentos regulares para a equipe de desenvolvimento.
•  Fomento de uma cultura de aprendizado contínuo e melhoria.

Resultados

A implementação efetiva das práticas de SQA resultou em diversos benefícios para o projeto. A conformidade com os requisitos do cliente foi consistentemente atingida, evitando retrabalho e garantindo a satisfação do cliente. A identificação precoce de riscos permitiu ações preventivas, minimizando impactos negativos. A introdução de padrões elevou a qualidade geral do código e da documentação. A gestão de mudanças eficiente assegurou a estabilidade do sistema, mesmo diante de atualizações frequentes. Além disso, a cultura de treinamento contínuo fortaleceu as habilidades da equipe, contribuindo para o sucesso do projeto e consolidando a importância da SQA no desenvolvimento de software.

Saiba Mais

Para ler mais sobre a Qualidade de Software, acesse o livro de Pressman, Engenharia de Software, Capítulo 15.

Quer saber mais sobre a qualidade de Software? Leia o Capítulo 24 de Engenharia de Software - Sommerville.

Leia mais sobre SQA acessando o artigo indicado Garantia da Qualidade de Software (SQA).

Referências Bibliográficas

MAITINO NETO, R. Engenharia de software. Londrina: Editora e Distribuidora Educacional S.A., 2021.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

ZANIN, A. et al. Qualidade de Software. Porto Alegre: Sagah, 2018.

Qualidade de produto

Olá, estudante! Nesta aula você conhecerá a Gestão da Qualidade do Produto. Exploraremos desde os fundamentos até as Métricas de Produto e Normas ISO de Qualidade. Esses temas são fundamentais para sua prática profissional, capacitando-o a assegurar padrões elevados, medir a eficácia do produto e alinhar-se às normativas internacionais. Prepare-se para adquirir conhecimentos essenciais que impulsionarão a excelência na gestão da qualidade em seus projetos profissionais.

Ponto de Partida

Caro estudante, a Engenharia de Software é uma área na qual são discutidos assuntos como gerenciamento, qualidade, processos, entre outros. Dentro da qualidade existem discussões com especificidades, como é o caso da qualidade do produto. Com isso, você deve imaginar que essas discussões tendem à área de desenvolvimento de software.

Onde nós podemos ver a qualidade do produto de software no dia a dia? Diversos sistemas, que utilizamos nos computadores, nos smartphones, nos sistemas embarcados, etc., foram validados em todas as suas características. Tendo isso em vista, as normas de qualidade de produto são um guia para que os processos, as avaliações e as métricas, sejam ajustadas conforme as necessidades do projeto.

Inicialmente, serão discutidos os modelos de qualidade de produto de software quanto a suas características, necessidades e aplicações, o que é de grande importância para que você possa, posteriormente, compreender as estruturas das normas.

Com isso, o próximo passo é compreender como as métricas são utilizadas para aferir a qualidade do produto de software, sendo possível que você entenda como encontrar os pontos que necessitam de avaliações e quais medidas podem ser utilizadas para tal finalidade.

Em seguida, serão discutidas as normas ISO/IEC (NBR), suas características e subcaracterísticas. E, embora toda essa estrutura seja complexa, você terá exemplos de momentos em que são aplicadas as técnicas durante o ciclo de vida do projeto.

Sobre esses assuntos, vamos imaginar que uma empresa de desenvolvimento de games para mobile adotou as normas da ISO 9126 para ajustes de qualidade de produto. Isso fez com que, após alguns projetos, os resultados pudessem ser sentidos por clientes, gestores de projetos e desenvolvedores. Porém, as atividades relacionadas à ISO 9126 têm se tornado uma prática diferente para cada gerente de projetos, causando desconfortos aos desenvolvedores quando são alocados para outros times de desenvolvimento.

Como você é o gerente de projetos com mais tempo de empresa, o gerente geral solicitou um relatório, no qual você deve propor uma solução viável e que, de preferência, não gere custos. Assim, espera-se que haja uma gestão das atividades relacionadas à qualidade do produto durante os projetos de desenvolvimento de software.

Bons estudos!

Vamos Começar!

Gestão da qualidade do produto

Prezado estudante, é provável que você já tenha experimentado a frustração de baixar um aplicativo que, apesar de prometer funcionalidades específicas, revelou-se complexo demais em sua operação, resultando em um desempenho distante das expectativas inicialmente anunciadas. Este descompasso entre a promessa na descrição da loja de aplicativos e a efetiva qualidade do produto final é abordado na Engenharia de Software sob o tema da qualidade de produto de software. Embora possa parecer peculiar considerar o software como um produto tangível, as discussões sobre a qualidade de produtos abrangem uma ampla gama de tópicos, desde modelos e normas de qualidade até gestão, medições, requisitos e avaliações. Dada a complexidade inerente a esses conceitos, exploraremos exemplos concretos para uma compreensão mais aprofundada.

Conforme Mello (2011), ao contrário dos produtos manufaturados, o desenvolvimento de softwares é um processo projetado, demandando habilidades criativas e técnicas dos profissionais envolvidos. Enquanto a produção de bens manufaturados frequentemente se baseia em processos mecanizados, seguindo a automação previamente concebida pelos engenheiros, o desenvolvimento de software é caracterizado por sua natureza criativa e técnica.

Mello (2011) ilustra essa diferença na prática ao abordar os setores de manufatura e desenvolvimento. No setor de manufatura, a produção envolve matérias-primas, processos de transformação, embalagem, acondicionamento e transporte, com diferentes níveis de complexidade no sistema produtivo. Por exemplo, uma padaria especializada em bolos utiliza matérias-primas específicas em seus processos, produzindo bolos com diversos graus de complexidade. Já uma empresa farmacêutica constrói as características de seu setor produtivo com base em insumos variados e diferentes etapas de processamento.

No setor de desenvolvimento, a maioria dos projetos demanda recursos computacionais, como computadores, acesso à internet e aos programas. No entanto, o sucesso do projeto depende significativamente das habilidades, das competências e da criatividade dos profissionais que utilizam o desenvolvimento de software para encontrar soluções em diversas áreas do conhecimento.

A complexidade em assegurar a qualidade do produto de software é evidente. Para enfrentar esse desafio, existem ferramentas conhecidas como modelos de qualidade de produto. Normas internacionais foram estabelecidas para garantir a aderência a premissas específicas, independentemente do local de desenvolvimento do software. 

Métricas de Produto

As métricas de produto são medidas de previsão utilizadas para avaliar atributos internos de um sistema de software, como o tamanho do sistema em linhas de código ou o número de métodos associados a cada classe de objeto. No entanto, características facilmente mensuráveis, como tamanho e complexidade ciclomática, não apresentam uma relação clara e consistente com atributos de qualidade, como capacidade de compreensão e manutenibilidade. Essas relações variam conforme os processos de desenvolvimento, tecnologias utilizadas e o tipo de sistema em desenvolvimento.

As métricas de produto podem ser categorizadas em duas classes distintas (Sommerville, 2018):

• Métricas Dinâmicas: coletadas por meio de medições realizadas enquanto um programa está em execução. Essas métricas podem ser obtidas durante testes de sistema ou após a implementação do sistema. Exemplos incluem o número de relatórios de bugs e o tempo necessário para concluir uma computação.
• Métricas Estáticas: coletadas por meio de medições feitas em representações estáticas do sistema, como o projeto, o código-fonte ou a documentação. Exemplos de métricas estáticas incluem o tamanho do código e o comprimento médio de identificadores utilizados.

Esses tipos de métricas estão associados a diferentes atributos de qualidade. Métricas dinâmicas auxiliam na avaliação da eficiência e confiabilidade de um programa, enquanto métricas estáticas ajudam a avaliar a complexidade, compreensibilidade e manutenibilidade de um sistema ou de seus componentes.

Normalmente, há uma relação evidente entre as métricas dinâmicas e as características de qualidade do software. Medir o tempo de execução de funções específicas e avaliar o tempo necessário para iniciar um sistema é relativamente simples, e essas métricas estão diretamente associadas à eficiência do sistema. Da mesma forma, registrar o número de falhas do sistema e o tipo de falha permite uma correlação direta com a confiabilidade do software.

Métricas estáticas, exemplificadas na Tabela 1, mantêm um relacionamento indireto com atributos de qualidade. Diversas métricas foram propostas, e muitos experimentos foram conduzidos na tentativa de estabelecer e validar conexões entre essas métricas e atributos como complexidade do sistema e manutenibilidade. Embora nenhum desses experimentos tenha fornecido conclusões definitivas, observa-se que o tamanho do programa e a complexidade de controle parecem ser os indicadores mais confiáveis para prever a compreensibilidade, complexidade e manutenibilidade de um sistema.

Métrica de software	Descrição
Fan-in/Fan-out	Fan-in é a medida do número de funções ou métodos que chamam outra função ou outro método (digamos X). Fan-out é o número de funções que são chamadas pela função função de X. Um valor alto para fan-in significa que X esta fortemente acoplado ao resto do projeto e as alterações em X terão repercussões extensas. Um valor alto para fan-out sugere que a complexidade geral do X pode ser alta por causa da complexidade da lógica de controle necessário para coordenar os componentes chamados.
Comprimento de código	Esta é uma medida do tamanho de um programa. Geralmente, quanto maior o tamanho do código de um componente, mais complexo e sujeito a erros o componente é. O comprimento em código tem mostrado ser uma das métricas mais confiáveis para prever a propensão a erros em componentes.
Complexidade ciclomática	Está é uma medida de complexidade de controle de um programa. Essa complexidade de controle pode estar relacionada á compreensibilidade de programa.
Comprimento de identificadores	Esta é uma medida do comprimento médio dos identificadores (nomes de variáveis, classes, métodos etc) em um programa. Quanto mais longos os identificadores, mais provável que sejam significativos e, portanto, mais compreensível o programa.
Profundidade de aninhamento condicional	Esta é uma medida da profundidade de aninhamento de declarações if em um programa. Declarações if profundamente aninhadas são difíceis de entender e potencialmente sujeitas a erros.
Índice Fog	Esta é uma medida do comprimento médio de palavras e sentenças em documentos. Quanto maior o valor de um índice Fog de um documento, mais difícil a sua compreensão.

Tabela 1 | Métricas estáticas de produto de software. Fonte: Sommerville (2018).

Na Figura 1, é apresentado um processo de medição que pode integrar-se a uma avaliação de qualidade de software. Cada componente do sistema pode ser analisado individualmente, utilizando diversas métricas. Os valores dessas métricas podem ser comparados entre diferentes componentes e, possivelmente, com dados históricos de medição obtidos em projetos anteriores. Medições anômalas, que se desviam significativamente da norma, podem indicar problemas na qualidade desses componentes.

Neste processo de medição de componentes, os estágios principais incluem (Sommerville, 2018):

• Seleção de Medições: formular questões específicas que as medições devem responder e definir as métricas necessárias. Utilizar o paradigma Meta-Questão-Métrica (GQM) para decidir quais dados coletar.
• Seleção de Componentes: escolher os componentes a serem avaliados, podendo focar em um conjunto representativo ou nos componentes principais do sistema.
• Medição de Características: medir os componentes selecionados, envolvendo o processamento da representação do componente usando ferramentas automatizadas de coleta de dados.
• Identificação de Medições Anômalas: comparar os valores das métricas entre os componentes e com medições anteriores para identificar valores anormalmente altos ou baixos, indicando possíveis problemas de qualidade.
• Análise de Componentes Anômalos: examinar os componentes com valores anômalos para determinar se isso compromete a qualidade do componente. Valores anômalos não necessariamente indicam má qualidade, podendo haver outras razões.

Manter os dados coletados como recurso organizacional e registros históricos é essencial. Ao estabelecer um banco de dados de medições abrangente, é possível comparar a qualidade do software entre projetos e validar as relações entre atributos internos dos componentes e das características de qualidade.

Siga em Frente...

Normas ISO de qualidade

A International Organization for Standardization (ISO) é uma entidade internacional que desenvolve e publica normas reconhecidas mundialmente em diversas áreas, incluindo a gestão de qualidade.

ISO 9126 (NBR 13596)

A ISO 9126 (NBR 13596) é uma norma destinada à avaliação da qualidade, das características e dos atributos de software. Seu propósito também inclui a padronização das atividades e dos métodos de avaliação da qualidade do produto, proporcionando feedbacks valiosos para equipes de desenvolvimento de software. A estrutura da norma é composta por quatro partes, cada uma abordando aspectos específicos (Wazlawick, 2013):

• ISO 9126-1 de 2001: trata das características, subcaracterísticas e métricas da qualidade do produto de software (foco desta seção).
• ISO 9126-2 de 2003: aborda métricas externas e o controle de falhas.
• ISO 9126-3 de 2003: tem como objetivo verificar a quantidade de ocorrências de falhas e estimar o tempo de recuperação.
• ISO 9126-4 de 2004: lida com User Experience, produtividade, eficácia e segurança.

Segundo Wazlawick (2013), a ISO 9126 é considerada parte integrante da família de normas de qualidade 9000, com ênfase na qualidade do produto de software. No contexto brasileiro, a NBR 13596 é equivalente à ISO, no entanto, a NBR foi substituída pela ISO/IEC 9126-1. A norma presente na ISO 9126 é estruturada em características, subcaracterísticas e métricas, sendo que as seis características podem ser visualizadas na Figura 2.

Para melhor compreensão das características e subcaracterísticas da ISO 9126, a seguir vamos ver o detalhamento de cada uma delas segundo Wazlawick (2013).

Funcionalidade

Descreve os atributos das funções incorporadas nos softwares, abordando diversas subcaracterísticas:

• Adequação: refere-se à concordância do funcionamento adequado da funcionalidade.
• Acurácia: concentra-se nas saídas geradas pelo software, as quais devem estar em conformidade com as necessidades.
• Interoperabilidade: indica a capacidade do software de ser utilizado por diferentes tecnologias.
• Conformidade: deve estar em conformidade com normas, regras e leis específicas.
• Segurança de acesso: envolve a capacidade de prevenir intrusões e incidentes relacionados à segurança da informação.

Para ilustrar a identificação de funcionalidades em um projeto, considere a seguinte situação: uma empresa necessita de um chat para facilitar a comunicação entre colaboradores na rede local, com a exigência de utilizar o protocolo IP em ambas as versões, IPv4 e IPv6. Como evidenciado, a funcionalidade de comunicação interna apresenta características de grande importância em relação à adequação e interoperabilidade. 

Confiabilidade

Refere-se à habilidade do software em permanecer operacional e atender ao desempenho esperado ou estabelecido. Destacam-se as seguintes subcaracterísticas:

• Maturidade: demonstra a frequência das ocorrências de falhas no software.
• Tolerância a falhas: envolve a verificação, em situações de falhas ou incidentes relacionados à segurança (sejam provocados ou decorrentes de violações), dos serviços que permanecerão acessíveis e com a garantia da integridade.
• Recuperabilidade: diz respeito ao tempo necessário para que, após a ocorrência de uma falha específica, a funcionalidade ou sistema esteja novamente disponível.

Os aspectos relacionados à confiabilidade são mais evidentes em nossas atividades diárias, tornando-se mais fácil identificá-los. Por exemplo, ao projetar aplicativos de streaming para smart TVs, foi essencial compreender a confiabilidade, levantando questões como: em caso de falha, o filme ou série será interrompido? Em caso de falhas, quais são? Qual o tempo estimado para que o sistema se restabeleça?

Usabilidade

Refere-se a uma medida para avaliar o nível de experiência do usuário (User Experience) em relação à facilidade de operação do software. As subcaracterísticas podem ser delineadas da seguinte forma:

• Inteligibilidade: relaciona-se à lógica da aplicabilidade, sendo intuitiva e de fácil operação.
• Apreensibilidade: avalia o esforço que o usuário emprega para aprender a utilizar uma funcionalidade ou o software como um todo.
• Atratividade: observa o grau em que as interfaces do software capturam a atenção do usuário.

A usabilidade, em termos de experiência do usuário, é uma das características que demanda especial atenção. É comum que alguns usuários instalem softwares de edição de vídeo e, devido à complexidade para realizar determinadas operações, desistam e busquem soluções mais acessíveis em smartphones. Isso está diretamente relacionado às características de usabilidade do software. 

Eficiência

Nesta característica, a atenção está voltada para a capacidade de modificação, que pode ocorrer em diferentes situações, tais como a exclusão de defeitos e falhas, a adição de novas funcionalidades, a adaptação a novas plataformas ou sistemas operacionais, entre outras possibilidades. As subcaracterísticas são delineadas da seguinte maneira:

• Modificabilidade: aborda a capacidade do software de ser modificado por razões ou necessidades específicas.
• Estabilidade: preocupa-se em verificar se ocorrerão falhas após as modificações.
• Escalabilidade: avalia a capacidade de crescimento do software para atender a uma demanda maior. 

A manutenção de softwares é uma preocupação constante para gerentes de projetos, uma vez que falhas na abordagem dessas subcaracterísticas têm um impacto direto na qualidade dos serviços prestados. 

Portabilidade

Em 2020, o governo federal implementou auxílio financeiro à população por meio de um benefício, em resposta à elevada taxa de desemprego causada pela pandemia do novo coronavírus. Contudo, para ter acesso a esse benefício, era necessário instalar um aplicativo no smartphone. O problema surgiu quando ficou evidente que o aplicativo não havia sido projetado para atender a uma parcela tão extensa da população, comprometendo significativamente o seu funcionamento. A portabilidade torna-se um ponto de grande relevância com o advento dos dispositivos móveis, e suas características podem ser delineadas da seguinte forma (Wazlawick, 2013):

A portabilidade abrange um conjunto de características que indicam a capacidade do software de ser utilizado em outros sistemas, dispositivos e plataformas.

• Adaptabilidade: refere-se à capacidade de se adaptar a ambientes para os quais não foi originalmente projetado.
• Analisabilidade: envolvem a análise dos impactos positivos e negativos que a utilização do software em outros contextos pode acarretar.
• Interoperabilidade: demonstra a capacidade de interagir com outros sistemas, frequentemente desenvolvidos com diferentes tecnologias e arquiteturas.

Um exemplo emblemático e atual da importância da portabilidade surgiu com a popularização dos smartphones. Os sites, inicialmente projetados para monitores de tamanhos consideráveis, apresentaram comportamento inadequado nesses dispositivos, evidenciando a falta de preparo para a portabilidade. 

ISO 9000

Certamente, observou-se que os métodos abordados neste contexto são todos respaldados por normas. Muitos sistemas de gestão de qualidade têm como base as normas ISO 9000:2015 (ABNT, 2015), as quais têm como propósito: 

• Descrever os fundamentos e princípios da gestão da qualidade.
• Compreender os processos de implementação da gestão da qualidade.
• Avaliar a conformidade dos produtos de software desenvolvidos.

De acordo com Carpinetti e Gerolamo (2019), a ISO 9000 incorpora oito princípios de gestão da qualidade, os quais visam orientar os gestores na melhoria de desempenho, especialmente em atividades relacionadas ao desenvolvimento de software. Esses princípios são os seguintes:

• Foco no cliente: adota uma abordagem que busca melhores práticas para entregar o melhor produto.
• Liderança: emprega metodologia e abordagens como meio de liderar.
• Pessoas: utiliza formas para incentivar o comprometimento das pessoas com os processos e a qualidade.
• Processos: verifica constantemente os processos e os repensa.
• Inter-relacionamento: promove o inter-relacionamento de atividades concorrentes.
• Melhoria: busca a melhoria contínua por meio de metodologias, normas e boas práticas.
• Decisão: utiliza os feedbacks gerados a favor da tomada de decisão.
• Benefícios: gera vantagens administrativas e operacionais por meio da adoção de boas práticas.

Para compreender como os princípios da ISO 9000 estão conectados às atividades de desenvolvimento no ambiente profissional, considere o exemplo a seguir. Imagine a existência de "ilhas" de desenvolvimento dentro de uma organização, onde as equipes são segregadas por conhecimento e habilidades. Contudo, em determinado momento do projeto, as funcionalidades desenvolvidas precisam ser integradas para que o sistema efetivamente ganhe existência. Como proceder?

A ISO 9000 oferece orientações específicas para abordar essa situação. Observe como a norma pode ser benéfica nesse exemplo, trazendo impactos positivos para os profissionais envolvidos. A norma fornece diretrizes sobre a abordagem a ser adotada com a equipe, liderança que orienta a integração das funcionalidades, e, sob uma perspectiva diferente, um olhar que mapeia os processos para propor melhorias e ajustes. Isso possibilita um planejamento mais adequado e gera benefícios a curto e longo prazo, conforme a maturidade aumenta.

ISO 9001

Para concluir, é relevante destacar que a norma 9001:2015 adota uma abordagem com foco em tarefas administrativas no âmbito do Sistema de Gestão da Qualidade (SGQ). Conforme o catálogo da ISO 9001:2015 (ABNT, 2015), seus objetivos incluem:

• Gerenciar o controle documental.
• Realizar o controle de registros de qualidade.
• Padronizar a realização de auditorias internas.
• Efetuar o controle de produtos que não atendam às conformidades.
• Implementar ações corretivas.
• Implementar ações preventivas.

Ao longo das discussões apresentadas nesta unidade, você pôde observar como as normas se configuram como excelentes guias para as atividades de desenvolvimento de software, certo? Para alguns profissionais, a utilização dessas ferramentas pode parecer adicionar uma camada extra de atividade além daquelas já necessárias em um projeto. Entretanto, o propósito é, na realidade, o oposto. A intenção é que, por meio da adoção das normas, as atividades sejam realizadas de maneira mais precisa, resultando em uma menor necessidade de revisitar processos e atividades de desenvolvimento.

Vamos Exercitar?

Ao mesmo tempo que a ISO 9126 ajudou essa empresa, ela tem se tornado um problema quando os colaboradores migram de uma equipe a outra, isso porque cada gerente de projetos tem utilizado uma forma de operacionalizar as normas ISO 9126. Para isso, o gerente geral solicitou que você desenvolvesse um relatório com um sistema de gestão de qualidade de produto. 

Dessa forma, foi feita a seguinte sugestão: vamos adotar a ISO 9000, pois a sua estrutura possui oito princípios de gestão da qualidade, os quais têm como objetivo conduzir os gestores nas atividades de desenvolvimento de software. Perceba como nós conseguiremos a padronização de trabalho entre os gerentes de projetos ao observar os princípios dessa norma: foco no cliente, liderança, pessoas, processos, inter-relacionamento, melhoria, decisão e benefícios.

Saiba Mais

Acesse o artigo a seguir sobre a ISO 9126. ISO 9126: O que é e por que é importante para a qualidade de software?

Para ler mais sobre a Qualidade de Software, acesse o livro Engenharia de Software - Pressman, Capítulo 15.

Quer saber mais sobre a qualidade de Software? Leia o Capítulo 24 de Engenharia de Software - Sommerville.

Referências Bibliográficas

CARPINETTI, L. C. R.; GEROLAMO, M. C. Gestão da Qualidade ISO 9000:2015. São Paulo: Atlas, 2019.

MELLO, C. H. P. Gestão da qualidade. São Paulo: Pearson Education do Brasil, 2011.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

WAZLAWICK, R. S. Engenharia de software: conceitos e prática. Rio de Janeiro: Elsiever, 2013.

Qualidade de processo

Olá, estudante! Nesta aula você ampliará a sua compreensão sobre Qualidade do Processo, abordando os renomados modelos CMMI e MPS.BR. Explore desde os conceitos fundamentais até a aplicação prática dessas metodologias. Esses conteúdos são essenciais para aprimorar sua prática profissional, oferecendo ferramentas sólidas para avaliar, aperfeiçoar processos e atingir padrões internacionais de excelência. Esteja preparado para incorporar conhecimentos valiosos e elevar sua expertise na busca pela qualidade em seus projetos.

Ponto de Partida

Caro estudante, muitas vezes nós, enquanto consumidores, estamos acostumados somente a ver o produto final e não os processos envolvidos no desenvolvimento dele. A ideia é a de que, quando você vai a um fast-food, a única parte do processo com a qual você tenha contato seja o momento de fazer e receber o pedido. Seja em um fast-food, seja em um setor industrial ou, no nosso caso, na indústria do software, na grande maioria das vezes, avaliamos se o processo foi bem executado considerando o resultado que é entregue. Mas como são feitas as tratativas referentes à qualidade dos processos de desenvolvimento de software?

Inicialmente, serão discutidos os modelos de maturidade CMMI e MPS.BR, os quais são metodologias que visam, por meio de sua estrutura, posicionar a empresa em um nível de maturidade e, mediante o uso de técnicas, planejar uma evolução em termos organizacionais a fim de promover melhoria em seus processos.

Em seguida, haverá uma discussão acerca da ISO 9001:2015, cujo foco está em utilizar metodologias que permitam aos membros da organização conhecer os processos, os microprocessos e as interações entre os componentes em sua totalidade. Dessa forma, ao se conhecer bem os processos, a chance de erros e falhas é minimizada, proporcionando a melhoria dos processos e consequentes benefícios.

Em termos profissionais, esses temas são de extrema importância pois são largamente utilizados dentro de organizações que buscam técnicas para atingir resultados expressivos. Dessa maneira, conhecer as técnicas e compreender o momento de aplicá-las pode ser um interessante diferencial competitivo.

Para a nossa atividade, imagine que você trabalhe na PROC-TI, uma empresa que já atua no ramo de Tecnologia da Informação (TI) há mais de 25 anos. A PROC-TI foi contratada pelo governo federal para desenvolver uma solução de identificação via drones de áreas devastadas pelas queimadas na Amazônia.

Sabendo que a PROC-TI possui o interesse de implantar um modelo de referência em seus processos, a partir desta contratação do governo federal, explique qual seria o modelo mais adequado para a instituição e quais seriam as vantagens da implantação deste.

Bons estudos!

Vamos Começar!

Quando você utiliza um software pode não perceber a complexidade dos processos necessários para garantir a confiabilidade, eficiência e segurança da aplicação. Para assegurar a qualidade dos processos de software, são empregados normas, métodos, ferramentas e metodologias.

De acordo com a definição de Sommerville (2018), no contexto do desenvolvimento de software, os processos são essenciais para organizar, gerenciar e compreender a sequência de atividades. Para proporcionar uma compreensão mais clara dos processos, tomemos como exemplo um projeto de desenvolvimento da página inicial de um site. Nesse caso, diversos processos podem ser identificados, tais como design de layout, tratamento de imagens, responsividade, entre outros. É evidente que cada etapa do desenvolvimento pode ser orientada por normas específicas, visando atingir os objetivos desejados.

E por que a melhoria dos processos é importante para as atividades de desenvolvimento de software? À primeira vista, pode parecer que melhorar processos é aplicável apenas a atividades de linhas de produção, mas essa percepção não é precisa. Ao empregar ferramentas de qualidade de processos, o objetivo é corrigir erros e falhas, padronizar atividades e alinhar o trabalho com a equipe de desenvolvimento, entre outros benefícios. Antes de adotar qualquer metodologia de qualidade de processos, é essencial realizar o mapeamento detalhado desses processos (Sommerville, 2018).

O mapeamento de processos é uma ferramenta gerencial destinada a identificar a sequência na qual as atividades são executadas. Em uma perspectiva prática, o mapeamento pode proporcionar vantagens adicionais, tais como:

• Compreensão dos processos: possibilita a compreensão de todas as partes que os constituem.
• Análise dos processos: ao realizar o mapeamento, é viável refletir sobre as atividades que integram os processos.
• Melhoria dos processos: ao examinar minuciosamente as atividades que compõem os processos, é possível otimizá-los, ajustá-los ou substituí-los para aprimoramento.
• Padronização dos processos: as atividades alinhadas aos padrões de qualidade estabelecidos pelas políticas da empresa podem tornar-se padrão nos processos.
• Documentação dos processos: ao mapear as atividades que compõem os processos, é possível documentá-los, caso a equipe não tenha realizado essa etapa nas atividades anteriores à fase de desenvolvimento do projeto.

Percebeu que antes de qualquer coisa, devem-se mapear os processos para que se compreendam detalhadamente todas as atividades de desenvolvimento? Até aqui tudo certo. Contudo, qual é o nível de detalhamento adequado para o mapeamento? Conforme indicado por Sommerville (2018), há três níveis de detalhamento dos processos, como pode ser observado:

• Nível 1 – Descritivo: busca-se o alinhamento dos processos com as partes envolvidas no projeto de desenvolvimento por meio de uma descrição básica e abrangente.
• Nível 2 – Analítico: esta fase técnica detalha as atividades de desenvolvimento, os pontos de atenção e o tratamento de exceções.
• Nível 3 – Executável: oferece uma visão mais próxima aos dados e à aplicação em si. O objetivo aqui é detalhar as funcionalidades, os serviços e as saídas.

Dessa forma, após realizar o mapeamento dos processos, seja por meio de softwares ou através de descrições (como textos, tabelas ou quadros), é possível empregar ferramentas como modelos, normas e metodologias. Esses elementos constituem as formas pelas quais as equipes podem assegurar a qualidade dos processos de desenvolvimento de software. Entre essas ferramentas, abordaremos inicialmente os Modelos de Maturidade CMM e CMMI.

Modelos de maturidade – CMMI

As conversas sobre a qualidade dos processos abrangem uma variedade significativa de perspectivas, uma vez que os processos de desenvolvimento podem ser analisados por diversos prismas. O Modelo de Maturidade de Capacidade (CMM) e o Capability Maturity Model Integration (CMMI) são modelos amplamente reconhecidos no âmbito do desenvolvimento de software, desempenhando papéis cruciais na avaliação e no aprimoramento dos processos organizacionais. Desenvolvido nos anos 1980, o CMM delineia cinco níveis de maturidade para representar a evolução progressiva das práticas em uma organização. Em contraste, o CMMI, introduzido em 2002, vai além dessa abordagem linear, apresentando constelações que integram diversas disciplinas, como desenvolvimento de sistemas, aquisição e serviços. Enquanto o CMM concentra-se em disciplinas separadas, o CMMI oferece uma visão mais abrangente e adaptável, permitindo que as organizações aprimorem continuamente suas práticas em sintonia com as demandas em constante evolução do cenário organizacional. Ambos os modelos representam ferramentas valiosas para guiar as organizações rumo à excelência nos processos e à entrega eficaz de produtos e serviços.

O CMMI apresenta duas abordagens principais: Representação por Estágios (Staged) e Representação Contínua (Continuous). A distinção fundamental entre essas duas abordagens reside na forma como as organizações implementam e progridem nos níveis de maturidade (Sommerville, 2018).

Na Representação por Estágios, a abordagem é sequencial, exigindo que uma organização alcance todos os objetivos de um determinado nível de maturidade antes de avançar para o próximo. A avaliação global é realizada com base na adoção e implementação integral de todos os processos associados ao nível de maturidade em questão. As organizações podem buscar certificação em um nível específico, demonstrando conformidade com todas as áreas de processo desse nível.

Por outro lado, na Representação Contínua, a abordagem é mais flexível. As organizações têm a liberdade de selecionar e implementar áreas de processo específicas de diferentes níveis de maturidade, de acordo com suas necessidades e prioridades. Isso permite que se concentrem em melhorar áreas específicas do processo sem a obrigação de atingir todos os objetivos de um nível antes de avançar. A avaliação é conduzida de maneira detalhada, avaliando cada área de processo individualmente para um controle mais granular do progresso e do aprimoramento (Sommerville, 2018).

Ambas as representações compartilham o objetivo final de promover a melhoria contínua dos processos e aumentar a maturidade organizacional. A escolha entre a abordagem por estágios ou pela contínua dependerá das necessidades específicas, dos objetivos e das capacidades da organização em questão.

Os cinco níveis no modelo CMMI por estágios são representados na Figura 1 e correspondem aos níveis de capacidade de um a cinco no modelo contínuo. Cada nível de maturidade possui um conjunto associado de áreas de processo e metas genéricas, refletindo as melhores práticas em engenharia e gerenciamento de software, bem como a institucionalização da melhoria de processos. Os níveis de maturidade mais baixos podem ser alcançados introduzindo boas práticas; no entanto, os níveis mais elevados demandam um comprometimento com a medição e com o aprimoramento contínuo de processos.

A principal vantagem do modelo CMMI por estágios é sua compatibilidade com o modelo de maturidade e capacidade de software proposto na década de 1980, o que facilita a aceitação e a adoção por muitas empresas em seus esforços de melhoria de processos. A transição do modelo original para o CMMI por estágios é relativamente simples para organizações que já se comprometeram com esse modelo. Além disso, o modelo por estágios estabelece um caminho de melhoria claro para as organizações, permitindo que planejem a transição de um nível para outro, como, por exemplo, do segundo para o terceiro nível.

No entanto, a principal desvantagem do modelo por estágios (e do CMM para Software) reside em sua natureza prescritiva. Cada nível de maturidade possui metas e práticas específicas, assumindo que todas devem ser implementadas antes da transição para o próximo nível. Entretanto, as circunstâncias organizacionais podem demandar uma abordagem mais flexível, tornando mais adequado implementar as metas e práticas em níveis superiores antes das práticas de nível mais baixo. Quando uma organização opta por essa abordagem, uma avaliação de maturidade pode apresentar uma imagem distorcida de sua verdadeira capacidade.

Os modelos de maturidade contínuos não categorizam uma organização em níveis discretos; em vez disso, são abordagens mais refinadas que analisam práticas individuais ou conjuntos de práticas, avaliando a adoção de boas práticas em cada grupo de processos. Dessa forma, a avaliação de maturidade não se traduz em um único valor, mas em um conjunto de valores que indicam a maturidade da organização para cada processo ou grupo de processos.

No contexto do CMMI contínuo, são consideradas as áreas de processo e é atribuído um nível de avaliação de capacidade de zero a cinco para cada área de processo. É comum que organizações operem em diferentes níveis de capacidade para distintas áreas de processos. Portanto, o resultado de uma avaliação CMMI contínua é um perfil de capacidade que expõe cada área de processo e sua avaliação de capacidade correspondente. Um trecho de um perfil de capacidade, exemplificando processos em diferentes níveis de capacidade, é ilustrado na Figura 2. Nessa representação, é possível observar que o nível de capacidade em gerenciamento de configuração é elevado, enquanto a capacidade de gerenciamento de riscos é classificada como baixa. Empresas podem desenvolver perfis de capacidade reais e de metas, sendo o perfil-alvo uma expressão do nível de capacidade desejado para uma determinada área de processo.

A principal vantagem do modelo contínuo reside na capacidade das empresas de selecionar os processos de melhoria de acordo com suas necessidades e seus requisitos específicos. Diferentes organizações apresentam distintos requisitos de melhoria de processos. Por exemplo, uma empresa dedicada ao desenvolvimento de software para a indústria aeroespacial pode direcionar seus esforços para melhorias na especificação de sistema, gerenciamento de configuração e validação, enquanto uma empresa de desenvolvimento web pode focar em processos relacionados ao atendimento ao cliente. Em contraste, o modelo por estágios impõe às empresas uma sequência específica de estágios a serem seguidos. No entanto, o CMMI contínuo oferece critérios e flexibilidade, permitindo que as empresas atuem dentro do framework de melhoria do CMMI de maneira mais adaptável e alinhada com suas necessidades particulares.

Siga em Frente...

Melhorias de processo de Software brasileiro – MPS.BR

O Programa MPS-BR, estabelecido em dezembro de 2003 como uma iniciativa brasileira, busca aprimorar de forma contínua os processos de software. Uma das metas essenciais do MPS-BR é desenvolver e aperfeiçoar um modelo para a melhoria e avaliação de processos de software, com foco preferencial nas micro, pequenas e médias empresas, atendendo às suas necessidades de negócio e obtendo reconhecimento tanto nacional quanto internacional como um modelo aplicável à indústria de software.

Os componentes fundamentais do MPS-BR incluem o Modelo de Referência (MR-MPS), o Método de Avaliação (MA-MPS) e o Modelo de Negócio (MN-MPS), como apresentado na Figura 3.

Para a compreensão das siglas que compõem o MPS.BR, acompanhe os tópicos a seguir:

• Modelo de Referência (MR): contém informações a forma como a organização deve conduzir os seus processos para atingir os resultados. Ainda é possível, nesse mesmo documento, determinar o nível de maturidade e da capacidade dos processos descritos na NBR ISO/IEC 12207.
• Modelo de Avaliação (MA): trata-se do processo no qual são determinados os parâmetros e requisitos para se aferir a qualidade do desenvolvimento. É baseado na norma ISO/IEC 15504.
• Modelo de Negócio (MN): determina o nível de maturidade dos processos, que podem ser: (A) Otimizado, (B) Gerenciado, (C) Definido, (D) Largamente definido, (E) Parcialmente definido, (F) Gerenciado e (G) Parcialmente gerenciado.

O MPS.BR é organizado em sete níveis de maturidade, cada um representando um estágio de aprimoramento nos processos. Os níveis são uma maneira de avaliar e guiar as organizações no desenvolvimento e na implementação de práticas mais maduras e eficientes. A seguir, estão os sete níveis do MPS.BR:

1. Nível G (Inicial): este é o nível inicial e básico. As práticas neste estágio são realizadas de maneira ad hoc, muitas vezes dependendo das habilidades individuais dos profissionais envolvidos.
2. Nível F (Gerenciado): neste estágio, a organização começa a adotar uma abordagem mais disciplinada para a gestão de processos. Há uma conscientização maior sobre a importância de seguir processos definidos.
3. Nível E (Definido): Aqui, a organização estabelece processos padronizados e documentados. Há um esforço para definir e documentar processos para torná-los compreensíveis e consistentes.
4. Nível D (Gerenciado Quantitativamente): neste ponto, a organização começa a medir quantitativamente seus processos. Isso envolve a coleta e a análise de dados para entender melhor o desempenho do processo.
5. Nível C (Definido Detalhado): neste nível, os processos são refinados e otimizados. A organização trabalha em melhorias contínuas, identificando áreas específicas para aprimoramento.
6. Nível B (Gerenciado Quantitativamente para o Negócio): aqui, a organização expande a abordagem quantitativa para se alinhar melhor aos objetivos de negócios. A medição e a análise se tornam mais integradas aos objetivos organizacionais.
7. Nível A (Em Otimização): no nível mais alto, a organização busca a inovação e a otimização contínua. Os processos são ajustados e adaptados para atender às mudanças nas condições e nos objetivos organizacionais.

Esses níveis do MPS.BR fornecem um caminho claro para as organizações melhorarem seus processos de software, passando de abordagens ad hoc para práticas mais disciplinadas, mensuráveis e otimizadas. Cada nível representa um avanço na maturidade e na eficácia dos processos organizacionais.

Vale ressaltar que cada modelo apresenta o seu formulário específico: MR (Guia Geral e Guia de Aquisição), MA (Guia de Avaliação) e MN (Documentos do projeto). Segundo Rocha (2005), a construção das técnicas constituintes ao MPS.BR é composta pelas NBR ISO/IEC:

• NBR ISO/IEC 12207 para processo de ciclo de vida de software.
• ISO/IEC 15504 para avaliação de processo.
• ISO/IEC 15504-5 para modelo de avaliação de processo de software.

Na prática, como o MBS.BR deve ser iniciado no nível G, para o qual o manual determina 28 GPR, que são os objetivos que a equipe deve alcançar para atingir de maturidade. A seguir as três primeiras GPR do nível G, segundo MPS.BR (2012):

GPR 1. O escopo do trabalho para o projeto é definido.

GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados.

GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos.

Os GPRs necessitam de documentação, gestão e monitoramento. O manual sugere um modelo de documento, mas permite flexibilidade para que as empresas incluam ou removam campos conforme necessário.

Normas ISO de qualidade de processos

A norma ISO 9001 pode ser uma ferramenta valiosa para os desenvolvedores de software que buscam aprimorar a qualidade de seus processos. De acordo com Valls (2003), a ISO 9001:2015 destaca-se por promover uma visão sistêmica que deve orientar as atividades de desenvolvimento. Isso implica que os profissionais devem possuir um conhecimento aprofundado dos processos, sendo essencial que esse entendimento seja uniforme entre os membros de toda a organização.

Valls (2003) argumenta ainda que a ISO 9001 representa um sistema de qualidade projetado para assegurar a otimização dos processos. Conhecida no âmbito profissional como Sistema de Gestão da Qualidade (SQA), essa norma é considerada pelos gestores de projetos de desenvolvimento de software como uma ferramenta robusta para a correção e para o aprimoramento contínuo dos processos.

Ao implementar o modelo ISO 9001:2015, é essencial estabelecer, manter e buscar aprimoramentos na gestão da qualidade, com foco nos processos e nas suas interações. Desta maneira, o objetivo claro é alcançar um entendimento aprofundado de cada componente dos processos e das relações entre eles, evitando qualquer dissociação entre as etapas.

Você notou como a compreensão das conexões entre as partes facilita a compreensão dos processos? Além dessa percepção, Valls (2003) destaca que, para a melhoria dos processos, as organizações devem ter uma compreensão nítida dos seguintes pontos:

• Entradas e Saídas: em todo software, é fundamental que as entradas e as saídas sejam explicitamente definidas desde a fase de levantamento de requisitos, contribuindo para o aprimoramento da maturidade nesse aspecto.
• Sequência dos Processos: a clareza e a definição precisam dos processos possibilitam que a equipe compreenda a sequência de trabalho, assegurando uma lógica bem estruturada em todas as etapas.
• Interação dos Processos: o conhecimento aprofundado dos processos viabiliza a compreensão das interações entre eles, permitindo a identificação de pontos críticos no projeto.
• Recursos Disponíveis: além dos recursos computacionais, a escassez, muitas vezes, está relacionada a prazos e à mão de obra especializada, sendo crucial considerar esses aspectos na gestão.
• Responsabilidades: cada membro da equipe deve ter clareza sobre suas atribuições no projeto, conhecendo as interações com colegas e reconhecendo as lideranças presentes.
• Riscos: uma compreensão aprofundada dos processos possibilita aos gestores identificar riscos e pontos críticos, permitindo a implementação de ações preventivas para garantir qualidade e cumprimento de prazos.

O processo de implementação da ISO 9001 é relativamente simples e aplicável a empresas de todos os portes. No entanto, obter o reconhecimento total por meio da certificação exige que a empresa já possua um sólido nível de maturidade em seus processos de desenvolvimento de software, além de um conhecimento profundo das normas e das diretrizes que compõem a ISO 9001.

Vamos Exercitar?

Nesta atividade, o mais indicado seria o MPS.BR, pois é um modelo brasileiro e possui características para pequenas empresas. Algumas características do MPS.BR são:

o MPS.BR é um modelo de maturidade brasileiro, o qual possui sete níveis de maturidade. Os níveis são:

Nível G:

1. GRE- Gerência de Requisitos.
2. GPR- Gerência de Projetos.

Nível F:

1.  MED- Medição.
2. GQA- Garantia de Qualidade.
3. GCO- Gerência de Configuração.
4. AQU- Aquisição.
5. GPP- Gerência de Portfólio de Projeto.

Nível E:

1. GPR- Gerência de Projeto (evolução).
2. AMP- Avaliação e Melhoria do Processo Organizacional.
3. DFP- Definição do Processo Organizacional.
4. GRH- Gerência de Recursos Humanos.
5. GRU- Gerência de Reutilização.

Nível D:

1. DRE- Desenvolvimento de Requisitos.
2. ITP- Integração do Produto.
3. PCP- Projeto e Construção do Produto.
4. VAL- Validação.
5. Verificação.

Nível C:

1. DRU- Desenvolvimento para Reutilização.
2. GDE- Gerência de Decisões.
3. GRI- Gerência de Risco.

Nível B:

1. GPR- Gerência de Projetos

Nível A:

Não é necessário especificar os níveis, só foi utilizado no gabarito pala ilustrar quais melhorias nos processos podem ocorrer com a utilização do MPS.BR.

Saiba Mais

Quer ler mais sobre o modelo de referência CMMI. Acesse o livro a seguir e leia o Capítulo 11.1. Engenharia de Software - Hirama

 Quer ler mais sobre o modelo de referência MPS.BR. Acesse o livro a seguir e leia o Capítulo 11.2. Engenharia de Software - Hirama

No site oficial do MPS.BR você pode obter mais informações sobre o modelo de referência brasileiro.

Referências Bibliográficas

HIRAMA, K. Engenharia de software. Grupo GEN, 2011.

MAITINO NETO, R. Engenharia de software. Londrina: Editora e Distribuidora Educacional S.A., 2021.

SOFTEX. MPS BR. Softex, Brasília, [s. d.]. Disponível em: https://softex.br/mpsbr/. Acesso em: 22 abr. 2024.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

VALLS, V. M. A documentação na ISO 9001:2000. Banas qualidade, São Paulo, v. 12, n. 133, p. 100-105, jun. 2003.

Auditoria de sistemas

Olá, estudante! Nesta aula você desvendará os fundamentos da Auditoria de Tecnologia da Informação. Nesta jornada, exploraremos os conceitos-chave, mergulhando nos Ciclos de Vida da Auditoria e na abordagem específica para Sistemas de Informações. Esses conhecimentos são essenciais para fortalecer sua prática profissional, capacitando-o a avaliar, assegurar e aprimorar a segurança e a eficiência dos sistemas de informação. Prepare-se para adquirir habilidades cruciais no universo da auditoria tecnológica!

Ponto de Partida

Você já ouviu falar sobre auditoria? Existem diversos segmentos que utilizam essa ferramenta de verificação a fim de gerar informações que permitem compreender as falhas de processos, de produtos e de gestão. As auditorias possibilitam o conhecimento, em detalhes, das atividades desenvolvidas, tornando possível a análise dos processos. Além disso, pode-se dizer que a auditoria não verifica somente falhas, mas também pontos de melhorias e potencialidades.

Você sabia que em Engenharia de Software também são utilizados os processos de auditoria? Evidentemente, aquela que é feita na área de desenvolvimento de sistemas possui algumas particularidades em relação à aplicada em outros segmentos, porém é preciso lembrar que o intuito comum a qualquer auditoria é compreender os processos, diagnosticar falhas ou pontos de melhorias e, posteriormente, buscar os ajustes necessários, ou seja, utilizá-la como instrumento de melhoria. Interessante, não é?

Sobre esse assunto, vamos supor que uma organização de renome no setor de tecnologia, está comprometida em garantir a segurança, integridade e eficácia operacional de seus sistemas de informação. Diante desse compromisso, a empresa decidiu realizar uma auditoria abrangente em seus sistemas, abordando áreas críticas de TI, práticas de segurança e conformidade com padrões regulatórios e internos.

O objetivo deste estudo de caso é explorar o ciclo de vida da auditoria de sistemas da empresa, destacando as fases de planejamento do cronograma, planejamento da auditoria, condução e reporte. Portanto, apresente uma compreensão detalhada de como a empresa estrutura e executa o processo de auditoria para assegurar a segurança de seus sistemas de informação.

Bons estudos!!!

Vamos Começar!

Conceitos de auditoria de tecnologia da informação

Normalmente, quando as pessoas abordam a experiência de passar por auditorias, os relatos frequentemente incluem momentos de tensão, pressão no trabalho, ajustes de conduta e revisões detalhadas das atividades profissionais.

Assim como em outras áreas do conhecimento, como fiscal, contábil e administrativa, a Engenharia de Software também incorpora processos de auditoria para avaliar o desenvolvimento de software. Dado que essas atividades requerem habilidades técnicas de programação, criatividade e aplicação precisa de processos, são naturalmente sujeitas a processos de auditoria.

Mas, de fato, o que é uma auditoria?

Conforme mencionado por Cardoso (2015), as atividades de auditoria têm como função principal analisar de forma parcial ou abrangente os processos, resultados e, em alguns casos, fornecer sugestões de ações corretivas ou melhorias. Essas atividades podem ser conduzidas por meio de diversos métodos, como questionários, testes práticos de uso, análise documental, entre outros, sendo essencial que os resultados obtidos não suscitem dúvidas.

Para ilustrar essa abordagem, consideremos o exemplo de uma empresa que necessita auditar o desenvolvimento de uma funcionalidade específica em um aplicativo de uma operadora de convênio odontológico, o qual possibilita o agendamento de consultas. A auditoria se tornou necessária devido a um substancial atraso na entrega do aplicativo. Esse processo visa identificar o momento exato do atraso e as razões que o causaram, informações cruciais para corrigir possíveis falhas no processo. Nesse cenário, a equipe de auditoria poderia analisar documentos ou realizar entrevistas com os envolvidos, obtendo dados suficientes para gerar informações valiosas na compreensão do problema.

É evidente que, apesar da existência de processos de auditoria para avaliar atividades em diversas áreas, a tecnologia da informação dispõe de métodos e normas específicas. As atividades de auditoria em Engenharia de Software são reconhecidas como auditoria em sistemas da informação. Essas atividades não se limitam à verificação de códigos, instruções e outras formas de codificação de uma aplicação computacional, mas também englobam a aplicação de esforços, conforme demonstrado a seguir (Cardoso, 2015):

• Processos: refere-se à maneira como são direcionados os métodos de execução das atividades de desenvolvimento. Em termos práticos, considere que a empresa adote o SCRUM com a finalidade específica de priorizar as atividades. A auditoria de processo poderia examinar detalhadamente se o SCRUM foi seguido ao longo do ciclo de vida do desenvolvimento do software.
• Desenvolvimento: envolvendo a análise dos scripts, essa fase consiste na verificação dos possíveis erros de escrita na linguagem de programação ou marcação utilizada. Um exemplo contemporâneo é a auditoria de responsividade em desenvolvimentos web, que examina a aplicação correta dos frameworks destinados a tornar a aplicação responsiva. Os processos de auditoria revelarão, por exemplo, quais dispositivos apresentam erros ou desconforto de navegação, oferecendo avaliações cruciais para a qualidade dos desenvolvimentos.
• Testes: nesta etapa, a auditoria busca verificar a eficácia dos testes realizados nos desenvolvimentos de software. Em termos profissionais, isso implica que as atividades executadas pelos testadores de software serão auditadas para assegurar se as funcionalidades desenvolvidas estão sendo testadas adequadamente ou se há falhas, vícios ou outras inconformidades.
• Segurança e proteção dos dados: envolve as ações realizadas para garantir a segurança e a proteção dos dados, visando evitar incidentes indesejados. Por exemplo, durante o processo de auditoria, a utilização de pentest (teste de invasão realizado por profissional de segurança da informação) pode ser empregada para verificar, na prática, a segurança de um sistema.
• Estrutura de desenvolvimento: concentra-se nas atividades administrativas e de recursos humanos, no ambiente de trabalho e nos recursos disponíveis para o desenvolvimento profissional. Por exemplo, durante suas análises, o auditor pode revisitar as atividades profissionais para avaliar se o ambiente de trabalho favorece um bom desempenho dos profissionais de desenvolvimento de software.

Sem dúvida, é evidente a amplitude das áreas em que auditorias podem ser conduzidas no contexto do desenvolvimento de software. Contudo, é crucial compreender as atribuições e as responsabilidades de um elemento fundamental nos processos de auditoria de software: o auditor.

Conforme destacado por Gallotti (2016), o auditor é um profissional que possui conhecimentos técnicos, gerenciais, operacionais e analíticos necessários para conduzir as atividades relacionadas ao desenvolvimento de auditorias em sistemas da informação.

Para compreender o papel do auditor, observe o Quadro 1.

TIPOS	ATRIBUIÇÃO
Inspeção	Efetuar inspeção dos processos e dos desenvolvimentos. Verificar onde ocorrem inconformidades e apresentar provar convincentes.
Controle	Efetuar a análise de controle dos processos, podendo ser operacionais, de desenvolvimento ou gerenciais.
Risco	Verificar quais riscos podem afetar o projeto, a fim de se indicar a equipe na qual existe um risco. Isso permite que o gerente de projetos possa tomar medidas corretivas/preventivas. Analisar de forma mais abrangente os riscos, apresentando consequências externas que possam ocorrer.
Contínua	Elaborar relatórios das análises em espaços curtos de tempo. Utilizar sistemas de verificação constantes para que se faça uma análise de diversos momentos. Contratar especialistas da área em que é necessária uma análise mais profunda, a fim de se permitir o aumento do detalhamento dos processos.

Quadro 1 | Atribuições e responsabilidades do auditor de tecnologia da informação. Fonte: adaptado de Gallotti (2016).

No que diz respeito às responsabilidades e atribuições de um auditor de desenvolvimento de software, consideremos um exemplo: suponha que uma empresa de desenvolvimento de jogos para dispositivos móveis optou por criar um jogo exclusivo para um público específico. Um processo de auditoria poderia identificar os impactos positivos e negativos de um jogo com um tema que exclui determinados jogadores. Entretanto, a decisão sobre o produto elaborado cabe aos níveis administrativos e gerenciais da empresa, os quais, com base nos resultados das auditorias, decidirão sobre o rumo a ser seguido. Embora uma auditoria aponte falhas, erros e pontos de atenção, ela não impõe à empresa a necessidade de adotar outras direções; essa decisão é de responsabilidade da própria empresa.

Além disso, é importante salientar que as atividades de auditoria de software são fundamentadas em testes, análises, avaliações e outras abordagens que evidenciem a existência de inconformidades ou a execução inadequada (Gallotti, 2016).

Ciclos de vida da auditoria

Você percebeu a importância da auditoria na Engenharia de Software? Em nossas discussões, destacamos que as auditorias não devem ser encaradas como um processo doloroso e negativo, mas sim como uma ferramenta para identificar falhas, contribuindo para a qualidade do projeto, da equipe e da organização, refletindo positivamente no atendimento ao cliente. Contudo, na prática, em qual fase do projeto de desenvolvimento de software a auditoria deve ser empregada?

Os processos de auditoria em sistemas da informação podem ser aplicados ao longo de todo o ciclo de vida do projeto de desenvolvimento. O ciclo de vida da auditoria é composto por quatro processos, abrangendo desde as atividades preparatórias anteriores à auditoria propriamente dita até o seu acompanhamento (Weill e Ross, 2006). Esses processos de auditoria são sequenciais, e para entender a organização dessas atividades, consulte a Figura 1.

A elaboração do cronograma de auditoria é flexível, adaptando-se ao nível de detalhamento exigido pelo projeto. A simplicidade, com informações básicas como atividade, datas inicial e final, e responsável, é suficiente, embora outras informações possam ser adicionadas. Em muitos casos, a aprovação do planejamento do cronograma pela contratante é crucial. Por exemplo, a auditoria de um aplicativo de votação on-line. Se a data final do relatório estiver marcada para após o dia da votação, a aprovação do cronograma é vital para evitar conflitos e garantir que a auditoria seja realizada conforme as necessidades do projeto (Vetorazzo, 2018).

O planejamento da auditoria, como primeira etapa, inicia-se com o mapeamento dos processos, identificando os agentes responsáveis por cada um. Durante esse processo, o auditor pode consultar documentos de auditorias anteriores para direcionar suas atividades com base em apontamentos feitos. Uma das atividades essenciais é a definição clara do objetivo da auditoria, permitindo que a empresa de desenvolvimento de software ajuste-se às necessidades do cliente. A divulgação desse objetivo é crucial, como destacado por Rainer (2016), pois fornece clareza sobre quem será auditado, o que será auditado e quando a auditoria ocorrerá. Essa transparência facilita a focalização da auditoria nas áreas específicas que podem impactar diretamente no desempenho da aplicação, evitando auditorias em setores desnecessários, como exemplificado com equipes de front end que não impactariam diretamente a performance do sistema.

Vetorazzo (2018) ressalta que após o planejamento da auditoria ser elaborado e aprovado, inicia-se a fase de execução, na qual são aplicadas atividades de coleta de informações, como revisão documental, conversas, entrevistas, análise de dados de processos e observações, entre outras técnicas. O autor destaca a importância do checklist como um guia para o auditor, contendo os pontos a serem auditados. Esse checklist é fundamental para permitir análises abrangentes, e sua estrutura pode variar de acordo com o detalhamento necessário para o projeto, com informações básicas, como atividades, datas, horários, locais e responsáveis, podendo incluir outros dados conforme a necessidade.

De acordo com a fase de encerramento da auditoria consiste em reuniões, relatórios e apresentações que fornecem feedback sobre o que foi auditado. Essa etapa possibilita a discussão de melhorias e ajustes, dependendo do que foi acordado na contratação do serviço. No entanto, é ressaltado que a empresa ou equipe de auditoria não é responsável por implementar as mudanças sugeridas no relatório. Na prática, esse momento marca o fim de um período de auditoria, proporcionando à equipe auditada a oportunidade de conhecer os resultados, identificar acertos e erros, e projetar objetivos e melhorias futuras. Geralmente, é realizada uma reunião com a equipe auditada e os cargos administrativos para a apresentação dos resultados e a discussão de sugestões (Vetorazzo, 2018).

Siga em Frente...

Abordagem de auditoria de sistemas de informações

As abordagens de auditoria de Tecnologia da Informação (TI) ou Sistemas de Informação (SI) fundamentam-se na avaliação dos riscos empresariais relacionados à validação das transações econômicas, financeiras e contábeis, considerando a perspectiva da efetividade, especialmente diante de recursos limitados. Ao realizar auditorias em ambientes de tecnologia da informação, o auditor tem a flexibilidade de escolher abordagens adequadas. As abordagens comuns incluem aquelas centradas no computador, aquelas realizadas através do computador e aquelas executadas com o computador. A auditoria tradicional, historicamente associada à verificação da confiabilidade dos registros em conformidade com documentos-fonte, evoluiu devido ao impacto contínuo da tecnologia na gestão, tornando essencial armazenar informações de forma acessível à auditoria. Com a complexidade crescente dos ambientes, especialmente com a expansão para intranets e internet, surgem desafios relacionados à vulnerabilidade dos computadores e casos potenciais de fraudes. Dependendo da complexidade do sistema computadorizado e das características do auditor de sistemas de informações, ele pode optar por uma das três abordagens mencionadas: (1) abordagem ao redor do computador; (2) abordagem através do computador; e (3) abordagem com o computador (Imoniana, 2016).

Abordagem ao redor do computador

No passado, a auditoria ao redor do computador era uma abordagem muito solicitada pelos auditores, devido ao pouco envolvimento com a tecnologia de informação. A premissa subjacente a essa abordagem sugere que, se os dados de entrada estiverem corretos e os procedimentos correlatos estiverem em conformidade com os padrões operacionais e controles predefinidos, e se as saídas estiverem alinhadas com as expectativas, então os procedimentos lógicos de processamento tornam-se menos relevantes. Essa metodologia exige que o auditor avalie os níveis de concordância relacionados à implementação dos controles organizacionais no contexto da tecnologia da informação.

Isso implica conduzir uma auditoria nos documentos-fonte, examinando as funções de entrada subjacentes e compreendendo as funções de saída, as quais estão apresentadas em formatos de linguagem compreensíveis para aqueles que não são especialistas em informática. Pouca ou nenhuma atenção é dedicada às operações lógicas de processamento. O sistema de processamento eletrônico de dados é utilizado apenas para tarefas mais simples, como a obtenção de níveis de estoque e sugestões para realimentação quando necessário. Operações simples, como isolar estoques com pouca movimentação, gerar estatísticas de packing list em relação à distribuição e identificar estoques obsoletos, bem como elaborar uma aging list de duplicatas por meio de transações computadorizadas, são realizadas principalmente nas funções de impressão de relatórios.

Existe frequentemente uma ponderação sobre a aplicação desse método, questionando sua eficácia como uma prática sólida de auditoria. No entanto, a hesitação em adotá-lo pode ser atribuída à capacidade desses sistemas de realizar operações contábeis simples, levando os auditores a considerá-los como tarefas concluídas, avaliando as entradas e as saídas básicas dos sistemas. É importante observar que, embora essa abordagem possa não ser a mais adequada para ambientes complexos, ela ainda é bastante conveniente para sistemas menores, nos quais a maioria das atividades de rotina é realizada manualmente. Essa abordagem é baseada na afirmação de que as entradas do sistema podem ser consideradas corretas se os resultados do sistema refletirem com precisão os dados-fonte. Portanto, a saída também deve ser correta, e as maneiras pelas quais o sistema processou os dados têm pouca consequência. Vale ressaltar que, até o momento, ao adotar essa abordagem, os auditores têm pouco ou nenhum envolvimento direto com os registros gerados pelo computador, limitando-se a realizar consultas, rastrear dados, etc., sem acessar diretamente os programas do sistema.

Esta abordagem apresenta vantagens notáveis, como a não exigência de um amplo conhecimento em tecnologia de informação por parte do auditor, tornando as técnicas e as ferramentas de auditoria acessíveis e válidas. Além disso, sua aplicação é economicamente eficiente, envolvendo custos baixos e diretos. No entanto, as desvantagens são evidentes, incluindo uma restrição operacional devido à falta de compreensão sobre como os dados são atualizados, resultando em auditorias incompletas e inconsistentes devido à dinâmica do processo operacional. A avaliação da eficiência operacional também se torna mais desafiadora, pois não há parâmetros claros e padronizados. A abordagem pode levar a uma avaliação de risco inadequada, pois não exige que o auditor tenha uma capacidade profissional significativa em tecnologia de informação. Além disso, a exclusão das Unidades Centrais de Processamento (CPU) e funções aritméticas e lógicas em procedimentos de auditoria pode resultar em uma representação não abrangente da tecnologia de informação da organização, distorcendo as decisões baseadas nos relatórios resultantes dessas auditorias.

Abordagem através do computador

A aplicação dessa abordagem vai além da simples comparação entre documentos-fonte e resultados esperados, uma vez que os sistemas têm experimentado significativa evolução. No entanto, este método alerta para questões relacionadas ao manuseio de dados, à aprovação e ao registro de transações econômicas, financeiras e contábeis, sem deixar evidências documentais razoáveis por meio dos controles de programas incorporados nos sistemas. Por essa razão, o auditor necessita monitorar o processamento tanto através quanto dentro do computador. Essa abordagem aprimora a metodologia de auditoria centrada no computador. Ao utilizar este método de auditoria, uma pessoa pode solicitar, de diversas maneiras, semelhante à abordagem centrada no computador, a verificação dos documentos-fonte com dados intermediários. No entanto, destaca-se a ênfase do auditor em técnicas que empregam o computador como uma ferramenta para testar tanto a própria tecnologia quanto a entrada de dados.

Aqueles que apoiam o uso da abordagem centrada no computador favorecem a utilização da técnica de test data, que consiste no processamento de um dispositivo capaz de simular todas as transações possíveis com dados fictícios e reais.

Esta abordagem apresenta vantagens notáveis, incluindo a capacitação aprimorada do auditor em termos de habilidades profissionais relacionadas ao processamento eletrônico de dados. Além disso, permite ao auditor verificar com maior frequência as áreas que requerem revisão constante. No entanto, as desvantagens são consideráveis, destacando que, se a operação for realizada incorretamente, pode resultar em perdas incalculáveis, desaconselhando sua execução no ambiente de produção. O uso da abordagem pode ser dispendioso, especialmente no que se refere ao treinamento de auditores, aquisição e manutenção de pacotes de software. Considerando que os pacotes podem estar incorretos, técnicas manuais podem ser necessárias como complemento para assegurar a efetividade da abordagem. Além disso, há o risco de que os pacotes possam estar contaminados devido ao uso frequente na auditoria organizacional.

Abordagem com o computador

A primeira alternativa, a abordagem centrada no computador, demonstra falta de eficiência devido à sua negligência em relação a algumas das características dos controles internos dos sistemas, resultando na ausência de testes substantivos convincentes que são essenciais para chegar a conclusões robustas sobre os sistemas. Por outro lado, a segunda opção, a abordagem através do computador, considerada superior à primeira, também pode levar à produção de registros incompletos. Em vez de realizar uma verificação equilibrada com as ferramentas disponíveis, essa abordagem tem a tendência de negligenciar os procedimentos manuais, deixando incompletas a maioria das tarefas que normalmente são executadas manualmente.

Diante dessas considerações, empresas de auditoria e pesquisadores no campo contábil têm proposto um método para auditar as tecnologias de informações e sistemas de maneira mais aprimorada, empregando a abordagem completamente assistida pelo computador.

Realiza-se uma compilação do processo, aparentemente alcançando certos objetivos, tais como:

• Utilização das capacidades lógicas e aritméticas do computador para verificar a precisão dos cálculos em transações econômicas, financeiras e contábeis, bem como em responsabilidades como depreciações, impostos e taxas, multiplicação e contabilização (footings).
• Aplicação das capacidades de cálculos estatísticos e geração de amostras para facilitar confirmações de saldos necessárias para avaliar a integridade de dados em contas a receber, estoques, ativos fixos, advogados e circularização, entre outros testes com terceiros.
• Utilização das capacidades de edição e classificação do sistema computadorizado para ordenar e selecionar registros contábeis. Por exemplo, ao analisar a base de dados do sistema de estoque, um auditor pode identificar com precisão os itens de movimentação mais lenta ou obsoleta, isolando-os dos itens de movimentação rápida, facilitando análises mais complexas e substantivas.
• Aplicação das capacidades matemáticas do computador para analisar e fornecer listas de amostras de auditoria, seja por estratificação ou por unidade monetária de materialidade. Isso pode incluir a confirmação dos resultados de auditoria executados manualmente, como os cálculos globais.

Uma grande vantagem dessa abordagem é a disponibilidade e o uso eficaz de:

• Capacidades de auditoria para aplicar Técnicas de Auditoria Assistida por Computador (TAAC), também conhecidas como Computer Assisted Audit Techniques (CAAT).
• Possibilidades de desenvolver programas específicos para o uso do auditor ao evidenciar uma opinião sobre o processo contábil.
• Ganho de tempo com os passos aplicados no pacote generalizado de auditoria de tecnologia da informação.
• Integração de todos os processos de auditoria com os papéis de trabalho de auditoria, disponibilizando-os em uma rede de auditoria da firma, acessível via internet para toda a equipe, desde o trainee até o sócio.

Vamos Exercitar?

Este estudo de caso tem como propósito investigar o ciclo de vida da auditoria de sistemas de uma empresa, focando as etapas de elaboração do cronograma, o planejamento da auditoria, a execução e a elaboração do relatório. A intenção é apresentar uma análise minuciosa da maneira como a empresa organiza e conduz o processo de auditoria para garantir a segurança de seus sistemas de informação. Portanto, uma possível solução para este estudo de caso a seguir:

1. Planejamento do Cronograma:

O departamento de TI é responsável por fornecer suporte essencial para os processos de negócios da empresa.

Atividades:

• Identificação de Prazos Cruciais:
  • A equipe de auditoria, composta por auditores internos e externos, realiza uma reunião para identificar os prazos essenciais para a organização.
  • Estabelecimento de prazos para conclusão de projetos críticos, datas de lançamento de novos produtos e revisões regulares de segurança.
• Análise de Disponibilidade de Recursos:
  • Avaliação da disponibilidade de recursos, incluindo a equipe de auditoria, colaboradores internos, e ferramentas necessárias para conduzir a auditoria.
  • Planejamento para garantir que a auditoria não impacte adversamente as operações regulares da empresa.
• Definição de Marcos e Metas:
  • Estabelecimento de marcos de progresso e metas específicas para cada fase da auditoria.
  • Definição de objetivos claros para garantir que a auditoria esteja alinhada com os objetivos estratégicos da organização.

2. Planejamento da Auditoria:

Com base no cronograma estabelecido, a equipe de auditoria começa a planejar a abordagem detalhada para a auditoria.

Atividades:

• Identificação de Áreas Críticas:
  • Revisão das áreas críticas de TI que requerem atenção especial, incluindo sistemas de banco de dados, servidores, controle de acesso e políticas de segurança.
  • Avaliação de riscos associados a cada área crítica identificada.
• Seleção de Metodologia de Auditoria:
  • Escolha da metodologia de auditoria mais apropriada, levando em consideração a estrutura regulatória, os padrões da indústria e os requisitos internos.
  • Planejamento detalhado de como cada área crítica será avaliada.
• Design de Testes e Ferramentas:
  • Desenvolvimento de testes específicos e seleção de ferramentas de auditoria adequadas para avaliar a eficácia dos controles existentes.
  • Preparação de questionários e entrevistas para coletar informações relevantes.

3. Condução da Auditoria

Com o plano de auditoria em vigor, a equipe começa a executar as atividades planejadas.

Atividades:

• Coleta de Evidências:
  • Realização de testes de segurança, análises de logs e revisão de políticas e procedimentos.
  • Entrevistas com pessoal-chave para validar práticas e controles.
• Monitoramento em Tempo Real:
  • Monitoramento contínuo de sistemas durante a auditoria para identificar qualquer atividade suspeita ou não autorizada.
  • Adaptação do plano conforme necessário com base em descobertas em tempo real.
• Documentação Detalhada:
  • Registro detalhado de todas as descobertas, as evidências coletadas e os resultados de testes.
  • Documentação de qualquer não conformidade ou área de melhoria identificada.

4. Reporte:

Após a conclusão da auditoria, a equipe elabora um relatório detalhado para apresentar aos stakeholders.

Atividades:

• Análise de Resultados:
  • Avaliação aprofundada das descobertas, destacando áreas de conformidade, não conformidade e recomendações para melhorias.
  • Classificação de riscos associados a cada descoberta.
• Preparação do Relatório:
  • Elaboração de um relatório de auditoria completo, incluindo uma visão geral do processo, da metodologia utilizada, das descobertas, da análise de riscos e das recomendações.
  • Apresentação clara de ações corretivas sugeridas e seus impactos.
• Compartilhamento com Stakeholders:
  • Apresentação do relatório aos principais stakeholders, incluindo a alta administração, equipe de TI e outros departamentos relevantes.
  • Discussão das descobertas, esclarecimento de dúvidas e obtenção de aprovação para implementação de ações corretivas.

Este estudo de caso ilustra como o ciclo de vida da auditoria de sistemas pode ser aplicado em um ambiente de uma empresa de tecnologia, desde o planejamento do cronograma até o reporte final às partes interessadas. A abordagem estruturada contribui para garantir a eficácia das práticas de segurança e o alinhamento contínuo com os objetivos organizacionais.

Saiba Mais

O livro Auditoria de Sistemas de Informação apresenta de forma detalhada o tema abordado nesta aula.

Quer saber mais sobre as Auditoria de SI, acesse o artigo: Auditoria de sistemas de informação: saiba o que e como é feita.

O plano de contingência e de recuperação de desastres significa medidas operacionais estabelecidas e documentadas para serem seguidas, no caso de ocorrer alguma indisponibilidade dos recursos de informática, evitando-se que o tempo no qual os equipamentos fiquem parados acarrete perdas materiais aos negócios da empresa. Para entender mais como a auditoria trabalha com essa questão, acesse o link a seguir: AUDITORIA DE PLANO DE CONTINGÊNCIA E DE RECUPERAÇÃO DE DESASTRES.

Referências Bibliográficas

CARDOSO, A. Auditoria de sistema de gestão integrada. São Paulo: Pearson Education do Brasil, 2015.

GALLOTTI, G. M. A. Qualidade de software. São Paulo: Pearson Education do Brasil, 2016.

IMONIANA, J. O. Auditoria de sistemas de informação. 3. ed. Grupo GEN, 2016.

VETORAZZO, A. de S. Engenharia de software. Porto Alegre: SAGAH, 2018.

WEILL, P.; ROSS, J. W. Governança de TI: como as empresas com melhor desempenho administram os direitos decisórios de TI na busca por resultados superiores. São Paulo: M. Books do Brasil Editora Ltda., 2006.

Videoaula de Encerramento

Olá, estudante! Nesta aula você conhecerá a Qualidade de Software, Qualidade de Processo e Auditoria de Sistemas de Informação. Estes temas são fundamentais para aprimorar sua prática profissional, destacando a importância de entregar software confiável, otimizar processos e garantir a segurança dos sistemas de informação. Prepare-se para adquirir conhecimentos essenciais que impulsionarão sua excelência no universo da tecnologia.

Ponto de Chegada

Olá, estudante! Para desenvolver a competência desta unidade, que é saber aplicar os conceitos relacionados à qualidade de produto e de processo, nós precisamos começar com os conceitos da qualidade de software. Em linhas gerais, a qualidade de software implica a aplicação eficaz da gestão de qualidade para criar um produto útil com valor mensurável para desenvolvedores e usuários finais. Um software de alta qualidade deve atender às exigências explícitas e implícitas dos usuários, proporcionando confiabilidade e gerando benefícios, como a redução de manutenção e suporte, permitindo maior inovação, agilizando processos de negócio e resultando em maior receita, rentabilidade e disponibilidade de informações cruciais.

O termo "qualidade de software", frequentemente associado à conformidade funcional e desempenho conforme expectativas do patrocinador, segundo Sommerville (2018), aborda a qualidade em três níveis: organizacional, focado em estabelecer padrões para minimizar erros; de projeto, envolvendo o desenvolvimento conforme padrões estabelecidos pelos gestores de projetos; e de planejamento, exigindo a elaboração de um plano de qualidade e revisões para evitar falhas inadvertidas nos processos e produtos desenvolvidos.

Outro ponto importante é a Garantia de Qualidade de Software (SQA), que é uma abordagem sistemática e proativa para assegurar a qualidade dos processos e produtos relacionados ao desenvolvimento de software. Seu objetivo principal é garantir que as atividades de software sejam planejadas, implementadas e monitoradas de maneira eficaz, alinhando-se aos padrões e procedimentos estabelecidos. A SQA abrange uma ampla gama de atividades, desde a definição de processos até a realização de auditorias e revisões, visando identificar e corrigir desvios em relação às normas estabelecidas.

No contexto da SQA, são implementados práticas e métodos para melhorar continuamente a qualidade do software, antecipando e prevenindo defeitos em vez de corrigi-los após a implementação. Isso envolve a criação de planos de qualidade, a realização de revisões de código, o estabelecimento de métricas e indicadores de desempenho, além da promoção de uma cultura organizacional que valorize a qualidade em todas as fases do ciclo de vida do software. A SQA desempenha um papel crucial no fornecimento de confiança aos stakeholders, garantindo que os produtos de software atendam aos requisitos e padrões estabelecidos, resultando em sistemas mais confiáveis, eficientes e alinhados com as expectativas dos usuários.

Um ponto importante da qualidade de software é a medição. Essa prática envolve a obtenção de valores numéricos ou perfis para atributos de componentes, sistemas ou processos de software, comparando esses valores entre si e com padrões para avaliar a eficácia de métodos, ferramentas e processos. O objetivo a longo prazo é substituir revisões para julgar a qualidade do software, embora avaliações automatizadas ainda não tenham atingido esse ideal. Métricas de software, como tamanho do código, índice Fog, número de defeitos e complexidade ciclomática, desempenham um papel crucial na tomada de decisões de gerenciamento. As métricas de controle guiam mudanças nos processos, enquanto as métricas de previsão auxiliam na estimativa do esforço necessário para implementar alterações no software. Há duas abordagens para o uso de medições em um sistema de software: atribuir valores aos atributos de qualidade do sistema ou identificar componentes que não atendem aos padrões de qualidade, destacando características individuais que se desviam da norma.

As métricas de produto são medidas de previsão que avaliam atributos internos de um sistema de software, como tamanho do código e complexidade ciclomática. No entanto, essas características facilmente mensuráveis não têm uma relação clara e consistente com atributos de qualidade, como compreensibilidade e manutenibilidade, devido às variações nos processos de desenvolvimento, tecnologias e tipos de sistemas. As métricas de produto se dividem em métricas dinâmicas, coletadas durante a execução do programa, e métricas estáticas, obtidas a partir de representações estáticas como projeto, código-fonte ou documentação. Esses tipos de métricas estão associados a diferentes atributos de qualidade, em que métricas dinâmicas avaliam eficiência e confiabilidade, enquanto métricas estáticas ajudam a avaliar complexidade, compreensibilidade e manutenibilidade do sistema ou de seus componentes. Métricas dinâmicas, como tempo de execução e número de falhas, possuem uma relação mais evidente com as características de qualidade do software em comparação com métricas estáticas.

Quando falamos em qualidade, o ISO é fundamental para este tema. A norma NBR 13596, também conhecida como ISO/IEC 9126, estabelece padrões e diretrizes para a avaliação de qualidade de software. Essa norma internacional fornece um framework abrangente para medir a qualidade do software em termos de suas características e subcaracterísticas. A ISO/IEC 9126 define seis atributos principais de qualidade do software, que incluem funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Cada atributo é subdividido em diversas subcaracterísticas que abrangem aspectos específicos da qualidade do software.

Além de fornecer uma estrutura para avaliação, a norma ISO/IEC 9126 é uma ferramenta valiosa para desenvolvedores, testadores e stakeholders envolvidos no ciclo de vida do software. Ao adotar essas diretrizes, as organizações podem medir, avaliar e melhorar a qualidade de seus produtos de software, promovendo assim a entrega de sistemas mais confiáveis, eficientes e alinhados às expectativas dos usuários.

A ISO 9000 e a ISO 9001 são normas internacionais que estabelecem diretrizes e requisitos para sistemas de gestão da qualidade. A ISO 9000 fornece uma visão geral dos conceitos fundamentais e do vocabulário relacionados à gestão da qualidade, enquanto a ISO 9001 é uma norma específica que define os critérios para um sistema de gestão da qualidade eficaz. A ISO 9001 estabelece requisitos detalhados que as organizações devem atender para obter a certificação de seu sistema de gestão da qualidade. Essas normas visam garantir a consistência, eficiência e melhoria contínua nos processos de uma organização, proporcionando confiança aos clientes e às partes interessadas de que os produtos e serviços atendem aos padrões de qualidade estabelecidos. A implementação e certificação de acordo com as normas ISO 9000 e ISO 9001 são reconhecidas internacionalmente e contribuem para aprimorar a reputação e a competitividade das organizações no mercado global.

A qualidade do produto está diretamente ligada com o processo de desenvolvimento, portanto ter qualidade no processo é indispensável. O Capability Maturity Model Integration (CMMI) é um modelo de melhoria de processos que fornece diretrizes detalhadas para organizações aprimorarem seus processos de desenvolvimento e manutenção de software. Desenvolvido pelo Software Engineering Institute (SEI) da Universidade Carnegie Mellon, o CMMI visa promover a maturidade dos processos, fornecendo uma estrutura para avaliação e melhoria contínua. Ele se baseia em cinco níveis de maturidade, que vão desde o inicial até o otimizado, cada um representando um estágio específico de maturidade dos processos. Ao adotar o CMMI, as organizações podem avaliar e aprimorar a eficácia de seus processos, aumentar a qualidade do software e a satisfação do cliente, além de proporcionar uma base sólida para a implementação de práticas de gerenciamento de projetos mais eficientes.

A implementação bem-sucedida do CMMI geralmente resulta em benefícios tangíveis, como aumento na eficiência operacional, redução de defeitos, melhoria da previsibilidade e melhor alinhamento com as metas estratégicas da organização. Além disso, o CMMI é aplicável a diversas áreas além do desenvolvimento de software, incluindo engenharia de sistemas, aquisição e serviços. Sua abordagem flexível e abrangente permite que as organizações adaptem e personalizem as práticas de acordo com suas necessidades específicas, tornando-o um guia valioso para alcançar a excelência nos processos.

O Modelo de Referência para Melhoria de Processo de Software (MPS.Br) é uma iniciativa brasileira que visa promover a melhoria contínua dos processos de desenvolvimento e manutenção de software nas organizações. Inspirado em modelos internacionais, como o CMMI, o MPS.Br é adaptado para atender às necessidades específicas do contexto brasileiro. Ele oferece um conjunto de práticas e critérios que auxiliam as empresas a avaliar e aprimorar seus processos, visando maior eficiência, qualidade e satisfação do cliente.

O MPS.Br é organizado em níveis de maturidade, desde o G (Gestão) até o A (Otimizado), proporcionando uma trajetória evolutiva para as organizações aprimorarem seus processos. A obtenção de uma certificação MPS.Br reconhecida internacionalmente demonstra o comprometimento da organização com a excelência e a melhoria contínua. Além disso, o modelo tem se consolidado como uma referência importante para o setor de tecnologia no Brasil, contribuindo para elevar os padrões de qualidade e competitividade das empresas no cenário global.

A auditoria de sistemas desempenha um papel essencial ao avaliar a conformidade, integridade e eficácia dos processos de desenvolvimento de software, contribuindo para garantir e aprimorar a qualidade dos produtos e serviços entregues. A auditoria desempenha um papel essencial no desenvolvimento de software, desafiando-se a analisar e aprimorar processos e resultados, identificando oportunidades para correções e melhorias. Essas atividades, conforme explicado por Cardoso (2015), empregam métodos diversos, incluindo questionários, testes práticos de uso e análise documental, visando fornecer resultados claros e sem ambiguidades. Um exemplo prático desse processo ocorre em uma empresa de convênio odontológico, em que a equipe de auditoria busca entender as razões e o momento exato de um significativo atraso na entrega de uma funcionalidade no aplicativo, fornecendo informações valiosas para corrigir possíveis falhas.

No campo da Engenharia de Software, as atividades de auditoria em sistemas de informação ultrapassam a mera verificação de códigos e instruções, abrangendo processos, desenvolvimento, testes, segurança de dados e estrutura de desenvolvimento. Por exemplo, na auditoria de processo, a equipe pode analisar a conformidade com metodologias específicas, como o Scrum, ao longo do ciclo de vida do desenvolvimento do software. A auditoria de desenvolvimento verifica erros na linguagem de programação, enquanto a auditoria de testes avalia a eficácia dos testes realizados nos desenvolvimentos. A segurança dos dados é validada por meio de técnicas como o pentest, e a auditoria da estrutura de desenvolvimento examina aspectos administrativos, de recursos humanos e do ambiente de trabalho. A abrangência dessas áreas destaca a importância do papel do auditor em garantir a qualidade e eficácia no desenvolvimento de software.

As abordagens de auditoria de Tecnologia da Informação (TI) ou Sistemas de Informação (SI) visam avaliar os riscos empresariais associados à validação de transações econômicas, financeiras e contábeis, priorizando a efetividade diante de recursos limitados. No contexto da auditoria em ambientes de tecnologia da informação, os auditores têm flexibilidade para escolher entre abordagens centradas no computador, realizadas através do computador e executadas com o computador. A evolução da auditoria tradicional, anteriormente focada na verificação da confiabilidade de registros em conformidade com documentos-fonte, é impulsionada pelo impacto contínuo da tecnologia na gestão, exigindo a acessibilidade adequada às informações para auditoria. Com a crescente complexidade dos ambientes, incluindo intranets e internet, surgem desafios relacionados à segurança dos computadores e possíveis casos de fraudes, levando os auditores de sistemas de informações a escolherem entre três abordagens: ao redor do computador, através do computador e com o computador (Imoniana, 2016).

No passado, a abordagem de auditoria ao redor do computador era amplamente adotada devido à limitada familiaridade com a tecnologia da informação. Essa metodologia se baseia na suposição de que, se os dados de entrada estiverem corretos e os procedimentos relacionados estiverem em conformidade, e as saídas estiverem alinhadas com as expectativas, os procedimentos lógicos de processamento tornam-se menos relevantes. O auditor concentra-se em examinar a implementação dos controles organizacionais na tecnologia da informação, realizando auditorias nos documentos-fonte e nas funções de entrada e saída, com pouca atenção às operações lógicas de processamento. Apesar de sua conveniência em ambientes menores, essa abordagem enfrenta críticas quanto à sua eficácia, pois pode resultar em auditorias incompletas e inconsistentes devido à dinâmica operacional, além de limitar a avaliação da eficiência operacional e a compreensão abrangente da tecnologia de informação da organização.

Apesar de apresentar vantagens, como a acessibilidade para auditores com pouco conhecimento em tecnologia de informação e custos baixos, essa abordagem possui desvantagens notáveis. A falta de compreensão sobre a atualização de dados pode levar a auditorias incompletas, enquanto a exclusão de funções cruciais e a falta de parâmetros padronizados dificultam a avaliação eficaz. A abordagem também pode resultar em avaliações de risco inadequadas e distorções nas decisões organizacionais, uma vez que não exige um profundo conhecimento em tecnologia de informação por parte do auditor e exclui aspectos essenciais da infraestrutura tecnológica.

A abordagem ao redor do computador vai além da mera comparação entre documentos-fonte e resultados esperados, considerando a evolução significativa dos sistemas. No entanto, destaca a preocupação com o manuseio de dados, a aprovação e o registro de transações sem evidências documentais adequadas pelos controles de programas nos sistemas. O auditor é orientado a acompanhar o processamento dentro e através do computador, melhorando a metodologia de auditoria centrada no computador. Apesar de permitir verificações semelhantes à abordagem centrada no computador, destaca-se a ênfase em técnicas que usam o computador para testar a tecnologia e a entrada de dados.

Aqueles que apoiam a abordagem centrada no computador favorecem a técnica de test data, que simula transações com dados fictícios e reais. Embora forneça benefícios, como aprimoramento das habilidades do auditor em processamento eletrônico de dados e revisões mais frequentes, apresenta desvantagens significativas. A execução incorreta pode resultar em perdas, sendo desaconselhável no ambiente de produção. O custo associado ao treinamento de auditores, aquisição e manutenção de pacotes de software, além do risco de contaminação, são considerações importantes. Técnicas manuais podem ser necessárias como complemento para garantir a efetividade da abordagem.

A abordagem com o computador na auditoria destaca-se pela sua ênfase no uso das capacidades do computador para aprimorar as atividades de análise e verificação. Nesse método, o auditor se beneficia das capacidades lógicas, aritméticas e matemáticas do computador para avaliar a precisão de cálculos em transações econômicas, financeiras e contábeis. Além disso, são aplicadas técnicas estatísticas e de geração de amostras para confirmar saldos e avaliar a integridade de dados em diversas áreas, como contas a receber, estoques e ativos fixos. A edição e classificação de registros contábeis são otimizadas pelo uso do sistema computadorizado, proporcionando uma análise mais eficaz. A abordagem com o computador também se destaca pela aplicação de Técnicas de Auditoria Assistida por Computador (TAAC), desenvolvimento de programas específicos, economia de tempo e integração de processos de auditoria em uma rede acessível online para toda a equipe auditora. Essa metodologia representa uma evolução na forma como a auditoria aproveita a tecnologia para alcançar eficiência e precisão nas suas atividades.

É Hora de Praticar!

Apresente uma breve explicação sobre o MPS.BR (Melhoria de Processo do Software Brasileiro) e o Capability Maturity Model Integration (CMMI). Destaque suas principais características, seus objetivos e a importância na gestão de processos de software.

Explore as semelhanças e as diferenças entre o MPS.BR e o CMMI. Analise as áreas de processo, os níveis de maturidade e como cada modelo aborda a melhoria contínua nos processos de software. Destaque as peculiaridades que cada um traz para aprimorar a qualidade e eficiência.

Discuta as vantagens de integrar o MPS.BR e o CMMI na melhoria de processos de software. Considere como a combinação dessas abordagens pode resultar em benefícios sinérgicos, otimizando a gestão de projetos e promovendo a qualidade do produto final.

Reflita

• Como a implementação consistente de práticas de garantia de qualidade pode influenciar diretamente na satisfação do usuário e na eficácia de um software?
• De que maneira a implementação do MPS.Br (Melhoria de Processo do Software Brasileiro) pode promover a excelência nos processos de desenvolvimento de software e aprimorar a qualidade dos produtos em organizações brasileiras?
• Como a auditoria de sistemas pode contribuir para fortalecer a segurança da informação e garantir a conformidade em um ambiente empresarial cada vez mais dinâmico e suscetível a ameaças cibernéticas?

 

Resolução do estudo de caso

O MPS.BR é uma iniciativa brasileira que visa a melhoria de processos de software em organizações. Desenvolvido e mantido pela Associação para Promoção da Excelência do Software Brasileiro (Softex) em parceria com a comunidade de software brasileira, o MPS.BR é baseado em normas e padrões internacionais, adaptados à realidade do setor de software no Brasil. Seus principais objetivos incluem promover a melhoria contínua nos processos, aumentar a maturidade das organizações e fortalecer a competitividade no mercado.

O CMMI é um modelo global que oferece uma abordagem integrada para o desenvolvimento de software, sistemas e serviços. Desenvolvido pelo Software Engineering Institute (SEI) da Universidade Carnegie Mellon, o CMMI visa melhorar a eficácia e a eficiência organizacional, fornecendo um conjunto de práticas e diretrizes que abrangem o ciclo de vida completo do desenvolvimento de produtos e serviços. 

Semelhanças e Diferenças: 

Semelhanças:

• Ambos os modelos visam a melhoria contínua dos processos.
• Ambos são baseados em boas práticas e padrões internacionais.
• Ambos oferecem um conjunto de áreas de processo e níveis de maturidade.

Diferenças:

• O MPS.BR foi desenvolvido especificamente para atender às necessidades do setor de software brasileiro, enquanto o CMMI é aplicável globalmente.
• O CMMI é mais abrangente, cobrindo não apenas o desenvolvimento de software, mas também sistemas e serviços.
• O MPS.BR é estruturado em três níveis (A, B e C), enquanto o CMMI utiliza cinco níveis de maturidade. 

Vantagens da Integração:

• Complementaridade: a integração permite aproveitar as fortalezas de cada modelo, cobrindo lacunas específicas e proporcionando uma visão mais abrangente.
• Reconhecimento Internacional: a integração possibilita que as organizações atendam a requisitos globais de qualidade e melhoria de processos.
• Sinergia na Melhoria: a combinação de abordagens promove benefícios sinérgicos, resultando em uma gestão de projetos mais eficiente e produtos finais de maior qualidade. 

Este gabarito serve como um guia para discussão e análise, podendo ser expandido com exemplos específicos e casos práticos durante a atividade discursiva.

Dê o play!

Assimile

Explore o mapa mental que traz de forma concisa informações sobre o MPS.BR, CMMI, ISO 9126 e ISO 9000. Uma referência direta para compreender os padrões e modelos essenciais em qualidade e gestão.

Referências

CARDOSO, A. Auditoria de sistema de gestão integrada. São Paulo: Pearson Education do Brasil, 2015.

IMONIANA, J. O. Auditoria de sistemas de informação. 3 ed. Grupo GEN, 2016.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.