Por que o conceito de qualidade é tão importante para a engenharia de software?

O que é Engenharia de software

É uma disciplina de engenharia que se preocupa com todos os aspectos de produção de software (SOMMERVILLE, 2011, p. 4). Esta disciplina descreve como proceder com a análise, projeto, documentação, desenvolvimento, validação, implantação e evolução do software, obviamente não existe uma receita de bolo genérica que se aplica a todo e qualquer escopo de projeto de software, mas sim um conjunto de regras, instruções e práticas que norteiam o desenvolvimento destes.

Efetivamente, não é algo simples conceituar e praticar a Engenharia de Software. Mas é necessário. Primeiramente, deve-se ter em mente que os processos de Engenharia de Software são diferentes, dependendo do tipo de software que se vai desenvolver. […] dependendo do nível de conhecimento ou estabilidade dos requisitos, deve-se optar por um ou outro ciclo de vida, o qual será́ mais adequado ao tipo de desenvolvimento que se vai encontrar. WAZLAWICK (2013, p. 4)

Segundo Bauer (1972) a Engenharia de Software é definida como: “O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter um software economicamente viável, que seja confiável e que funcione eficientemente em máquinas reais”.

É importante observar que, ainda que várias definições tenham sido atribuídas a Engenharia de Software, todas convergem para o fato de que esta disciplina possui uma importância significativa para o desenvolvimento de um software profissional.

Tenha em mente que o uso da expressão “software profissional”, neste contexto, pode ser entendido como software projetado para ser utilizado por terceiros, sendo ele comercializado ou não, ou seja, em sua essencial primária, à Engenharia de Software pode ser vista como complicador ou emprego de esforço desnecessário quando aplicada ao software projetado para o uso pessoal daquele que o desenvolve.

A engenharia de software tem por objetivo apoiar o desenvolvimento profissional de software, mais do que a programação individual. Ela inclui técnicas que apoiam especificação, projeto e evolução de programas, que normalmente não são relevantes para o desenvolvimento de software pessoal. (SOMMERVILLE, 2011, p. 3)

Segundo Sommerville (2011, p. 29) a Engenharia de Software pode ser vista como um processo evolutivo, “no qual o software é constantemente alterado durante seu período de vida em resposta às mudanças de requisitos e às necessidades do cliente”.

O que é software?

A palavra software é bem comum dentro do ramo da tecnologia, até mesmo indivíduos leigos no assunto conhecem seu significado literal (em português: programaou programas de computador), entretanto, dentro do ramo da engenharia de software, seu significado e importância vão além do emprego tradicionalmente utilizado no dia a dia. Segundo Sommerville (2011) todos os componentes necessários para o programa funcionar fazem parte do que chamamos de software, sejam manuais, arquivos de configuração ou quaisquer outros elementos essenciais para o correto funcionamento e configuração do software.

Muitas pessoas pensam que software é simplesmente outra palavra para programas de computador. No entanto, quando falamos de engenharia de software, não se trata apenas do programa em si, mas de toda a documentação associada e dados de configurações necessários para fazer esse programa operar corretamente. (SOMMERVILLE, 2011, p. 17)

Obviamente o software pode ser descrito de muitas outras formas diferentes, entretanto, todas convergem para um entendimento singular. Pressman (2011) aponta 3 características que descreve o software, sendo elas:

Software consiste em: (1) instruções (programas de computador) que, quando executadas, fornecem características, funções e desempenho desejados; (2) estruturas de dados que possibilitam aos programas manipular informações adequadamente; e (3) informação descritiva, tanto na forma impressa como na virtual, descrevendo a operação e o uso dos programas. (PRESSMAN, 2011, p. 32)

Considerando as poucas linhas apresentadas até aqui, já foi possível compreender que o termo software descreve algo um pouco mais completo e complexo do que um “simples” programa de computador, bem como deixa claro que, a concepção de um software pode não ser algo tão simples, obviamente isso irá depender da natureza para a qual o mesmo está sendo ou foi projetado. A Engenharia de Software é responsável por coordenar os processos de identificação das necessidades do cliente, planejamento, análise, desenvolvimento, entrega e evolução do software.

O mundo moderno gira em torno do software, isso é indiscutível já que ele está presente nas telecomunicações, no controle de distribuição elétrica, de água, transporte aéreo, sistema financeiro etc. Já pensou como seria complexo e arcaico, no mundo de hoje controlar uma rede de bancos sem o apoio do software? Será que isso seria possível e/ou viável?

Para determinar quais métodos e técnicas serão utilizadas no desenvolvimento de um software, é necessário primeiramente determinar de que tipo ele será. Segundo Sommerville (2011) alguns dos possíveis tipos de aplicativos são:

1. Aplicações stand-alone. Essas são as aplicações executadas em um computador local, como um PC. Elas contêm toda a funcionalidade necessária e não precisam estar conectadas a uma rede. Exemplos de tais aplicações são aplicativos de escritório em um PC, programas CAD, software de manipulação de fotos etc.

2. Aplicações interativas baseadas em transações. São aplicações que executam em um computador remoto, acessadas pelos usuários a partir de seus computadores ou terminais. Certamente, aqui são incluídas aplicações Web como aplicações de comércio eletrônico em que você̂ pode interagir com o sistema remoto para comprar produtos ou serviços. Essa classe de aplicações também inclui sistemas corporativos, em que uma empresa fornece acesso a seus sistemas através de um navegador Web ou um programa cliente especial e serviços baseados em nuvem, como é o caso de serviços de e-mail e compartilhamento de fotos. Aplicações interativas frequentemente incorporam um grande armazenamento de dados, que é acessado e atualizado em cada transação.

3. Sistemas de controle embutidos. São sistemas de controle que controlam e gerenciam dispositivos de hardware. Numericamente, é provável que haja mais sistemas embutidos do que de qualquer outro tipo. Exemplos de sistemas embutidos incluem software em telefone celular, softwares que controlam antitravamento de freios em um carro e software em um micro-ondas para controlar o processo de cozimento.

4. Sistemas de processamento de lotes. São sistemas corporativos projetados para processar dados em grandes lotes. Eles processam grande número de entradas individuais para criar as saídas correspondentes. Exemplos de sistemas de lotes incluem sistemas periódicos de cobrança, como sistemas de cobrança telefônica, e sistemas de pagamentos de salário.

5. Sistemas de entretenimento. São sistemas cuja utilização principal é pessoal e cujo objetivo é entreter o usuário. A maioria desses sistemas é de jogos de diferentes tipos. A qualidade de interação com o usuário é a característica particular mais importante dos sistemas de entretenimento.

6. Sistemas para modelagem e simulação. São sistemas que incluem vários objetos separados que interagem entre si, desenvolvidos por cientistas e engenheiros para modelar processos ou situações físicas. Esses sistemas geralmente fazem uso intensivo de recursos computacionais e requerem sistemas paralelos de alto desempenho para executar.

7. Sistemas de coleta de dados . São sistemas que coletam dados de seu ambiente com um conjunto de sensores e enviam esses dados para outros sistemas para processamento. O software precisa interagir com sensores e frequentemente é instalado em um ambiente hostil, por exemplo, dentro de uma máquina ou em um lugar remoto.

8. Sistemas de sistemas. São sistemas compostos de uma série de outros sistemas de software. Alguns deles podem ser produtos genéricos de software, como um programa de planilha eletrônica. Outros sistemas do conjunto podem ser escritos especialmente para esse ambiente. (Sommerville, 2011, p. 7, grifo do autor)

Um software projetado para uso individual e local, fará uso de técnicas e métodos de planejamento e desenvolvimento diferentes de um software projetado para controlar sistemas essenciais de infraestrutura. Segundo Sommerville (2011, p. 6) “Tipos diferentes de sistemas necessitam de diferentes processos de desenvolvimento”, ou seja, não é possível ter na Engenharia de Software uma fórmula universal e genérica que dite as técnicas e métodos a serem seguidos em todo e qualquer projeto de software, mas sim um conjunto de técnicas e métodos para diferentes cenários e/ou necessidades específicas.

Os sistemas de software são abstratos e intangíveis. Eles não são restringidos pelas propriedades dos materiais, nem governados pelas leis da física ou pelos processos de manufatura. Isso simplifica a engenharia de software, porque não há limites naturais para o potencial do software. (SOMMERVILLE, 2011, p. 2)

Engenharia de Software: ciência ou engenharia?

Segundo Travassos (2002) a característica de produção do software pode ser vista como engenharia, já os aspectos relacionados ao time-to-market(tempo entre a análise de um produto e sua disponibilização para a venda) faz uso de um processo de melhoria contínua e de qualidade, é justamente neste contexto que enxergamos o lado científico da Engenharia de Software.

O método cientificoobserva o mundo, sugere o modelo ou a teoria de comportamento, mede e analisa, verifica as hipóteses do modelo ou da teoria. Isto é um paradigma indutivo. Esse método pode ser utilizado quando se tenta entender, por exemplo, o processo, o produto de software, ambiente. Ele tenta extrair do mundo algum modelo que possa explicar um fenômeno, e avaliar se o modelo é realmente representativo para o fenômeno que está sob observação. Isto é uma abordagem para construção de modelos. O método de engenharia observa as soluções existentes, sugere as soluções mais adequadas, desenvolve, mede e analisa, e repete até que nenhuma melhoria adicional seja possível. Isto é uma abordagem orientada à melhoria evolutiva que assume a existência de algum modelo do processo ou produto de software e modifica este modelo com propósito de melhorar os objetos do estudo. (TRAVASSOS, 2002, grifo nosso)

Conforme pode ser observado por Travassos (2002), esta disciplina possui uma acentuação tônica para o lado da engenharia, mesmo contendo traços do ramo da ciência frente ao emprego de métodos científicos em casos e cenários específicos.

A “crise do software”

Na década de 70 a expressão “crise do software” explodiu, Segundo Wazlawick (2013, p. 1) ela foi utilizada com impacto pela primeira vez por Dijkstra (1971), nesta época a Engenharia de Software era uma área sem visibilidade, praticamente inexistente. O termo “crise do software” expressava a extrema dificuldade enfrentada principalmente pelas áreas de desenvolvimento frente à complexidade dos problemas a serem resolvidos, e da demanda cada vez maior por soluções de software.

Os principais problemas apontados por Dijkstra (1971) eram:

• Projetos que estouram o cronograma e/ou orçamento
• Produto final de baixa qualidade ou que não atenda aos requisitos
• Produtos não gerenciáveis, difíceis de manter e evoluir

Eis que a Engenharia de software “brotou como uma apaziguadora” de crises, tudo bem que não foi algo tão simples assim, entretanto, veja essa disciplina como um esforço para minimizar os aspectos problemas do processo de desenvolvimento de software.

Gestão de Riscos

Este é um tópico extremamente delicado, uma boa gestão de riscos pode ser vista como um divisor de águas entre o sucesso e uma catástrofe absoluta no escopo de projeto. É importante pontuar que a gestão de riscos não é uma área exclusiva da engenharia de software, basicamente todo e qualquer processo de negócio, construção de hardware e demais projetos de grande porte utilizam a gestão de riscos para mitigar as possibilidades de um problema se materializar, e de alguma forma deturpar a qualidade de algo ou de alguma coisa.

Na engenharia de software, Pressman (2011) descreve a gestão de riscos como sendo:

[…] ações que ajudam uma equipe de software a entender e gerenciar a incerteza. Muitos problemas podem perturbar um projeto de software. O risco é um problema potencial — ele pode ocorrer ou não. Independente do resultado, é aconselhável identificá-lo, avaliar sua probabilidade de ocorrência, estimar seu impacto e estabelecer um plano de contingência caso o problema realmente ocorra. (PRESSMAN, 2011, p. 648)

Segundo Charette (1989), o risco refere-se a acontecimentos futuros. Hoje e ontem já não constituem mais uma preocupação, já que estamos colhendo os resultados de nossas ações.

Segundo Pressman (2011, p. 648), “Quando se considera risco no contexto da engenharia de software, os três fundamentos conceituais de Charette estão sempre em evidência”, sendo eles:

• O futuro é uma preocupação: quais riscos podem fazer o projeto de software dar errado?
• A alteração é uma preocupação: como as alterações nos requisitos do cliente, nas tecnologias de desenvolvimento, nos ambientes-alvo e todas as outras entidades conectadas ao projeto afetam a cadência e o sucesso geral?
• Que métodos e ferramentas deve-se usar: quantas pessoas deverão ser envolvidas, quanta ênfase na qualidade seria “suficiente”?

A gestão de riscos pode ser empregada de forma reativaou proativa, no primeiro caso ela é utilizada para apagar um incêndio gerado por riscos ignorados ou negligenciados. No caso da estratégia proativa o trabalho de gestão de riscos é iniciado muito antes que o trabalho técnico comece, segundo Pressman (2011, p. 649) “São identificados os riscos potenciais, avalia-se a probabilidade e o impacto, e os riscos são classificados por ordem de importância.”. Conforme pode ser observado, a estratégia reativa só se preocupa com os riscos quando ele se materializa, ou seja, quando vira algo real, neste contexto a estratégia proativa representa uma face oposta e mais conservadora.

Bibliografia

SOMMERVILLE, lan. Engenharia de Software; tradução Ivan Bosnic e Kalinka G. de O. Gonçalves; revisão técnica Kechi Hirama. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

WAZLAWICK, Raul Sidnei. Engenharia de software: conceitos e práticas. 1. ed. Rio de Janeiro: Elsevier, 2013.

BAUER, F.L. Software Engineering — Information Processing. Amsterdan: North Holland, 1972.

PRESSMAN, Roger S. Engenharia de Software — Uma Abordagem Profissional. 7. Ed. São Paulo: AMGH, 2011. Ph.D.

TRAVASSOS, Guilherme Horta. Introdução à Engenharia de Software Experimental. 2002. Disponível em: <http://www.inf.puc-rio.br/~inf2007/docs/artigos/RT-Introdução%20a%20ESE.pdf>. Acesso em: 11 fev. 2018.

DIJKSTRA, E. W. The Humble Programmer. Communications of the ACM, 15(10) 1971, p. 859–66.

CHARETTE, R. N., Software Engineering Risk Analysis and Management, McGraw-Hill, 1989.

Qual a importância da qualidade para o desenvolvimento de software?

Qual a relação da Engenharia de Software com a qualidade?

Qual a importância da avaliação de qualidade de software?

Qual é o principal objetivo da qualidade de software?