Resumo 2 - Gerência e Qualidade de Software

Engenharia de software

A revisão desempenha um papel fundamental na gerência e qualidade de

um software, pois trata-se da análise ou avaliação de um determinado produto
para identificar as conformidades com padrões estabelecidos, promovendo a
garantia de qualidade, além de falhas e omissões em relação à funcionalidade
do programa, por meio do controle de qualidade, tendo como objetivo melhorar
a qualidade do programa. Desta forma, as técnicas de revisão se caracterizam,
de maneira geral, como estáticas de verificação e validação, já que não
executam o código, mas funcionam como um filtro, ainda que revisões dinâmicas
sejam utilizadas em inspeções de usabilidade.

Desse modo, o modelo de amplificação de defeitos mostra-se como uma

grande ferramenta da revisão para a análise e apontamento de defeitos, o que
acontece desde os primeiros passos do desenvolvimento de um software.
Portanto, a revisão contribui para a correção da maior quantidade possível de
falhas no programa durante os processos, diminuindo o retrabalho, encurtando
os custos e tempo gastos no desenvolvimento do software, como ocorre com a
inspeção de Fagan de 1986.

Além disso, é possível indicar vários defeitos simultaneamente, analisar

características de qualidade, ser executada em artefatos incompletos e ajudar
no treinamento dos membros de equipe. Contudo, tais técnicas de revisão não
substituem os testes, visto que estes são mais competentes na análise de
defeitos derivados de interações entre componentes, como também questões de
temporização e de desempenho. Ademais, o maior custo inicial e a necessidade
de uma equipe preparada também são empecilhos para sua utilização no
desenvolvimento de software.

Sua utilização por pequenos grupos é denominada como revisão formal, ao

exemplo da IEEE 1028, com revisões gerenciais, técnicas, inspeção,
Walkthrough e auditoria. No caso da inspeção, tal técnica de revisão formal
origina-se na IBM, sendo desenvolvida especificamente para códigos por Fagan
em 1976, consistindo de uma experimentação com várias formas de revisão,
porém, ainda pode ser usada para outros artefatos. Dentre suas maiores
características, é possível citar o uso de checklists e a ênfase na preparação,
além da classificação dos defeitos encontrados.

Enquanto isso, o Walkthrough, também conhecido como “teste de mesa”,

se orienta através da análise do produto passo a passo, desempenhando
diversas funções importantes, como na identificação de anomalias e na
avaliação da usabilidade do software.

Assim, percebe-se a importância da revisão e suas técnicas para promover

a qualidade de um software, atuando juntamente aos testes e outros processos,
que são executados com a finalidade de analisar, identificar e classificar defeitos
e obstáculos no programa da maneira mais eficaz possível.

No quesito de gerência e qualidade do software, os testes de software

mostram-se como uma das mais importantes formas de se fazer a verificação e
a validação, ou o processo de se executar um programa com o objetivo de
encontrar possíveis erros. Contudo, os testes não garantem a inexistência de
tais defeitos.

Graças ao enorme volume de dados, instruções e métodos que podem ser

executados em um software, não é possível testar tudo, já que seria preciso uma
quantidade de tempo inconcebível. Assim, torna-se necessário que haja uma
seleção de apenas os testes com maior importância e relevância ao programa,
para serem executados, levando em consideração a maior chance possível de
se encontrar erros em cada um deles.

Neste meio, surgiram as técnicas de testes de software, buscando auxiliar

a escolha dos conjuntos de dados de teste, diminuindo seu número e priorizando
aqueles com a maior probabilidade de existência de erros, podendo ser estrutural
(caixa branca) ou funcional (caixa preta), que se apresentam como as principais
a serem utilizadas. Existem diversas formas para o teste funcional, das quais é
possível citar algumas como a partição equivalente, que divide o domínio de
entrada em classes equivalentes, separadas entre classes validas e invalidas,
com comportamento semelhante e certo grau de correspondência entre si, em
seus respectivos grupos, com relação ao resultado dos testes. Enquanto isso, a
técnica de valores limites trata das condições no limite, inferior ou superior, das
partições que geralmente contém mais defeitos.

Além do mais, os testes podem se apresentar de várias maneiras e níveis,

geralmente considerando a análise em “V”, como é o caso da sequência
configurada pelo teste de unidade, seguido pelo de integração, de sistema e por
fim o teste de aceitação. Ademais, os testes automatizados vêm ganhando cada
vez mais espaço no contexto atual, pois se tratam de uma forma de teste sem a
atividade humana, contendo maior praticidade, confiança e frequência nas
análises. Desta forma, tal método de teste deve ser independente, com unidades
isoladas entre si e minimizar a sobreposição, como também evitar a alteração
manual. Desse modo, o teste de unidade, além de ser automatizado, pode ser
executado tanto antes quanto depois de programar a classe (Desenvolvimento
Dirigido por Teste), podendo ser categorizado como:

• Teste intramétodos

• Teste intermétodos

• Teste intraclasse

• Teste interclasses

A utilização de determinados métodos entre os testes é comum, como um

método executado antes de cada teste, por meio da anotação “@Before”,
seguido pela inicialização “@Test” do próprio teste, onde os nomes dos métodos
exercem grande importância para o programa. Outros métodos de grande
relevância são os de veracidade, como “AssertTrue” e “AssertFalse”. Todavia, é
possível que haja a necessidade ou conveniência de se alterar classes, ou
incrementar formas de “classes dublês”, como o Stub, porém ele não garante ou
verifica se os métodos foram chamados da maneira correta, sendo preciso a
utilização de um Mock, outro tipo de “classe dublê”, para solucionar o problema.

A qualidade de um código é essencial na construção de bons softwares,

buscando garantir a eficácia do programa e a máxima satisfação dos clientes,
assim, um código tem boa qualidade quando desempenha o papel atribuído a
ele de forma eficiente. Porém, o código também deve ser elegante, limpo e
simples.
 A organização de um código pode impactar a sua qualidade de maneira
expressiva, pois a estrutura organizada facilita o entendimento e apontamento
de determinados aspectos no programa. Além disso, um código de qualidade
precisa ser testável, a fim de evidenciar defeitos com mais facilidade. Ainda
assim, entre as boas práticas e recomendações para a estruturação de um
código, é possível enfatizar a utilização de nomes mais claros e sugestíveis nas
variáveis, preferencialmente indicando sua função mesmo sem comentários,
evitando abreviações, palavras genéricas, letras solitárias e nomes redundantes
ou muito longos. Outrossim, os “números mágicos”, ou seja, os números
atribuídos pelo desenvolvedor a determinadas funções, sem uma explicação,
também são indesejáveis, já que não evidenciam o porquê do valor. Todavia, o
excesso de comentários pode poluir um código, de modo que a moderação se
torna necessária, com explicações apenas nos locais em que não é possível
deixar claro as intenções e funções das estruturas, onde o código precisa ser
autoexplicativo sem a utilização de muitos comentários. De forma generalizada,
os nomes das classes devem ser substantivos singulares, representando
conceitos, enquanto os nomes dos métodos devem ser verbos, no infinitivo ou
no presente, assim, representando ações no código.

A endentação e a separação do código através de pular linhas também são

fundamentais para a organização, seguindo o padrão da empresa e não
contendo exageros. A programação defensiva também exerce uma função
importante, com a finalidade de prevenir e evitar erros no software, ainda que
sejam gerados por outras pessoas, se protegendo entradas indesejadas de
fontes externas, como é o caso das técnicas de terminar o programa ou retornar
um código de erro.

Quando se considera as características de qualidade do software, é

possível perceber que elas se definem através da Usabilidade, ou estética da
interface do usuário, que busca apresentar o grau com que a interface permite
interações proveitosas ao usuário, e a especificação de requisitos não
funcionais, estipulando que a interface em questão deve ser agradável, ambas
baseadas em análises quantitativas.

De maneira aparente, a medição do produto, processo e projeto na

qualidade de software é realizada por meio das métricas, as quais tratam-se da
medida quantitativa do grau que um componente, processo ou sistema possui
um atributo específico, servindo como indicador, verdadeiro ou não, para auxiliar
a tomada de decisões.

Dentre as características de boas métricas, é possível destacar a

simplicidade de cálculo, o fato dela não ser ambígua ou dependente de uma
linguagem de programação e conseguir satisfazer noções intuitivas do atributo.
Tais métricas podem ser categorizadas como métricas de produto, métricas de
projeto, que geralmente são utilizadas pela gerência para adaptar o fluxo de
trabalho de atividades técnicas, e métricas de processo, que apontam
indicadores para auxiliar a melhoria do processo. As métricas de produto, ou de
previsão, buscam prever características de qualidade do produto, contudo, há
situações onde a medição direta de determinada característica é impossível,
como é o caso da eficiência de execução. Desse modo, é possível realizar
medições indiretas, por meio do relacionamento de propriedades de qualidade
que podem ser medidas.

Além de que as métricas de produto se dividem entre estáticas, as quais

são coletadas por meio de uma representação do sistema, e dinâmicas, que são
coletadas e contabilizadas através de medições em um programa quando
executado. O número de linhas de código está entre as métricas mais comuns e
usadas no desenvolvimento de software, graças a sua fácil realização e diversos
trabalhos envolvidos, como o erro por KLOC (erro por mil linhas de código).
Entretanto, sua utilização ainda é discutível, pois ela depende fortemente da
linguagem de programação, como também possui problemas na medição de
produtividade de designs.

Outrossim, a forma de métrica conhecida como “Pontos de função” também

é muito importante para o desenvolvimento de um software de qualidade, já que
ela permite estimar o tamanho funcional de um software antes mesmo de ser
implementado, sendo uma fórmula empírica baseada na medição de transações
e dados necessários. Um bom exemplo de padrões definidos para pontos de
função é a ISO 24570:2018 (NESMA). A medição das funções de dados também
é executada identificando grupos lógicos de dados, que são os arquivos de lógica
interna (ILF) e os arquivos de interface externa (EIF), onde o padrão preconiza
critérios para definir a complexidade funcional. Apesar disso, a medição de
funções transacionais, que trata de processos elementares, ou a menor unidade
da atividade, pode ser classificada como:

• Entrada externa

• Consulta externa

• Saída externa

Portanto, o cálculo matemático cria dados derivados, mantendo arquivos

de lógica interna e podendo alterar o comportamento do sistema, além de ser
descrito por meio de fórmulas variadas, como os “Pontos de função ajustados”,
que consideram a influência de 14 características.

Os projetos relacionados à gerência e qualidade de software tratam-se dos

esforços temporários realizados com a finalidade de gerar serviços, produtos ou
resultados exclusivos. Portanto, a gerência de tais projetos se caracteriza pela
implementação de determinados conhecimentos, habilidades, ferramentas e
técnicas que são direcionadas ao atendimento das necessidades e requisitos
estabelecidos.

Todavia, é possível perceber uma certa discrepância entre os projetos de

software com os projetos de outras áreas, principalmente com relação à
dificuldade com qual são trabalhados, pois para o software não existe processo
único e é difícil reaproveitar conhecimentos em diferentes programas, como
também os projetos de software não são tangíveis, ou seja, eles não são
palpáveis, o que pode estorvar o entendimento e visualização de progresso.

Além disso, os requisitos para cada software mudam constantemente,

sendo geralmente imprecisos, tornando o planejamento algo complexo, e a
evolução desenfreada das tecnologias que, apesar de benéfica, implica na
necessidade constante da atualização de conhecimentos para se manter no
mercado competitivo. A gerência de projetos de software é realizada com base
em determinadas atividades básicas, podendo ser definidas como:

• Planejamento de projeto

• Geração de relatórios

• Gerenciamento de riscos
 • Gerenciamento de pessoas

• Elaboração de propostas

O planejamento de projeto pode ser descrito como um conjunto de

atividades, iniciadas pelo estabelecimento de um escopo, seguido pela
determinação da viabilidade do projeto, análise dos riscos, definição de recursos
necessários, estimulo de mão de obra e o cronograma. Outrossim, o
gerenciamento de riscos trata das casualidades incertas que são passíveis de
gerar efeitos positivos ou negativos, podendo ameaçar qualquer um dos
objetivos do projeto, o produto e até mesmo o negócio, as quais são analisadas
por meio da medição de suas probabilidades e gravidade de sua ocorrência.
Algumas das ações importantes para o gerenciamento de riscos são as
estratégias de prevenção, minimização e o plano de contingência.

Enquanto isso, o gerenciamento de pessoas se apresenta como um fator

essencial para a gerência de projetos de software, visto que o desenvolvimento
de software é feito majoritariamente em equipe, onde o gerente deve garantir o
melhor uso e motivação das pessoas, promovendo uma visão alinhada entre o
time, a utilização de padrões de qualidade próprios e o compartilhamento de
conhecimentos. Nesse cenário, a seleção de membros ocorre pelos métodos
ágeis, visando “Habilidades em T”, ou seja, um conjunto de habilidades amplas,
com profundidades em certas especificações.