Você está na página 1de 56

QUALIDADE DE

SOFTWARE

Lucia Tavares

E-book 1
Neste E-Book:
INTRODUÇÃO����������������������������������������������������������� 3
QUALIDADE DE SOFTWARE:
HISTORICIDADE E FUNDAMENTOS������������������ 4
Engenharia de Software: Cultura e Ética���������������������������������4
Engenharia de Software���������������������������������������������������������11
Modelos e Características de Qualidade������������������������������22
Melhoria da Qualidade de Software��������������������������������������36
Segurança de Software����������������������������������������������������������45

CONSIDERAÇÕES FINAIS������������������������������������51
SÍNTESE�������������������������������������������������������������������� 52

2
INTRODUÇÃO
Falar de qualidade de software não se resume a fa-
lar de sistemas, plataformas e desenvolvimento. É
preciso entender a qualidade no seu sentido mais
básico. Por isso, neste módulo estudaremos os con-
ceitos de qualidade e seu diferencial no mercado em
todos os seguimentos, inclusive no que se refere ao
desenvolvimento de softwares.

Visamos, com isso, a compreender os modelos e


os detalhes que permeiam o universo da qualidade
e de que maneira tudo isso impacta no processo de
melhoria contínua dos sistemas.

Estudar a qualidade sem abordar a segurança é re-


sultar em falha. Dessa forma, abordaremos todo o
conceito de segurança de software também. Ainda,
embarcaremos no universo da qualidade, pois a par-
tir dela podemos desenvolver softwares que alcan-
cem seus objetivos e o maior número de usuários
possível.

Pronto para entrar no mundo da qualidade?

Boa sorte, bons estudos e apreciem a jornada!

3
QUALIDADE DE SOFTWARE:
HISTORICIDADE E
FUNDAMENTOS

Engenharia de Software:
Cultura e Ética

A Engenharia de Software segue um princípio de


amplas vertentes, aplicações e visões sobre a uti-
lização dos seus conceitos. Porém, em todas as vi-
sões, estudiosos convergem sobre um conjunto de
três elementos primordiais dentro da Engenharia de
Software: métodos, ferramentas e procedimentos.

Podemos entender que o fluxo de desenvolvimento


ocorre da seguinte maneira: os métodos mostram de
forma detalhada como tirar a ideia do papel para o
desenvolvimento de um software; entramos, então,
na fase de construção do projeto; as ferramentas, por
sua vez, encaixam-se nos métodos, propiciando um
apoio na migração (inclui-se aqui o caminho desde
a ideia até o planejamento do projeto). assim, os
procedimentos são os meios que promovem a rede
de ligação entre métodos e ferramentas.

O resultado é um processo de desenvolvimento trans-


parente, eficaz e prático que certifica a produção
desse software com qualidade, cujo produto gerado
é satisfatório para os envolvidos internos (desenvol-
vedores, programadores) e usuários finais (clientes,

4
parceiros). Isso garante a qualidade e a continuidade
do software.

No tocante ao progresso, observamos que a tecnolo-


gia deu um salto tão grande que, há 50 anos, o mundo
não tinha a menor noção de que a tecnologia seria
elemento indispensável para a sua sobrevivência, ou
seja, o mundo não tinha ideia de como o consumo
e a manipulação de dados e informações teriam a
importância que têm hoje.

Junto à evolução tecnológica, surge a necessidade


de qualidade, de perfeição, de segurança, de como-
didade, de facilidade para o usuário, e um trabalho
muito mais elaborado para o desenvolvedor, visto
que quanto mais requisitos devem ser atendidos,
mais complexidade existe na criação de um software.

Com toda essa gama de elementos indispensáveis,


não se pensa mais em criar um software, o pensa-
mento agora é “vamos partir para a montagem de um
projeto para criar um sistema”. Com isso, todo esse
projeto implica planejamento, cronograma e entrega.
E como entregar esses produtos (sim, softwares são
produtos) da maneira mais rápida, prática e sem pro-
blemas de fabricação, dentro do tempo de entrega
estipulado no cronograma do projeto? A resposta é:
utilizando a Engenharia de Software.

Com o avanço da tecnologia, houve um expressivo


crescimento de empresas que trabalham com o de-
senvolvimento de softwares. Dado que o conceito de
desenvolvimento tornou-se um conceito de projeto,
o número de profissionais especialistas igualmente

5
cresceu, e agora cada um tem sua função e partici-
pação como especialista em um projeto de software.
Nisso, surgiu o conceito de “trabalho em equipe para
desenvolver softwares”.

Este cenário é muito diferente do de um passado re-


cente, quando o mesmo desenvolvedor tinha a ideia,
criava o código fonte, testava, colocava em produção
e assumia todos os riscos, o que gerava um grande im-
pacto no produto entregue (PRESSMAN; MAXIM, 2016).

Diante de tal cenário, passemos então a discutir um


pouco como funciona a ética atrelada à cultura na
Engenharia de Software.

Ética pode ser definida como um conjunto de valo-


res que norteia uma sociedade. A palavra vem do
grego ethos, que quer dizer “caráter”, “jeito de ser”.
Podemos comparar a Engenharia de Software com
a ética na tecnologia, por tratar-se de um conjun-
to de valores que norteia o desenvolvimento de um
sistema.

A fim de compreender melhor esse cenário, enten-


demos que podemos usar a Engenharia de Software
para antever problemas evitáveis. Por exemplo, po-
demos citar problemas com a tecnologia que resulta
em desvantagens pessoais ou de grupo, como os
cartões de banco que apresentam falhas de segu-
rança e são passíveis de clonagem. Nesse caso e em
outros em que a Engenharia de Software é aplicada,
tais riscos podem ser mitigados e excluídos, devido
a todo o trabalho que é feito antes de o software
entrar no mercado.

6
Ao trabalhar com a Engenharia de Software, esquece-
-se do desenvolvimento solitário, da bagunça e dos
ambientes sem planejamento e organização. A ética
na tecnologia não é uma ficção tampouco um campo
não explicado da filosofia (GOTTERBARN, 1999).

Dentre os problemas que enfrentamos em tecnologia


sem a Engenharia de Software, podemos citar os
seguintes:

● Projetos assumidos sem recursos: são projetos


assumidos para conquistar clientes, mas que não
têm os recursos físicos ou lógicos necessários para
levar o projeto até o final.
● Cuidado com a segurança dos dados: preocupar-
-se apenas com o desenvolvimento sem levar em
conta a segurança dos dados e da estrutura onde o
programa vai rodar.
● Manobras e entusiasmo na manipulação de dados:
cria-se uma aplicação que exija mais dados do que
os necessários para o funcionamento.
● Backups defeituosos ou inexistentes: quando não
se cria uma rotina correta de backup ou até mesmo
quando não se usa o backup.

Essas não são situações novas, têm ocorrido há


muito tempo e causado muito mal ao andamento
de projetos. Mas elas podem ser contornadas e até
evitadas. Observe que o erro não é antiético, pois
erros acontecem em qualquer ramo, mas a falta éti-
ca é quando o profissional sabe que pode evitar e
não evita.

7
Assim, o “[...] código de princípios resume o que se
quer da engenharia de software numa escala mui-
to alta de abstração e aspirações” (GOTTERBARN;
MILLER; ROGERSON, 1999). Isso porque, na última
versão, tudo fica no ar para se pensar. Já na versão
completa, temos um verdadeiro manual com deta-
lhes, até do modo de agirmos como profissionais. Se
os detalhes nos cansam, a falta deles nos dão peças
para pensar. Por isso, é interessante ler o código de
conduta completo e o resumido.

Tanto os engenheiros de software quanto quem ado-


ta as boas práticas de desenvolvimento de software
devem entender que, a partir do momento em que se
escolhe trabalhar com as diretrizes, é preciso adotar
um conjunto de métricas para análise, produzir uma
especificação eficaz, desenvolver um projeto que siga
todas as fases (do levantamento à entrega), que seja
claro, transparente e real.

Então, para garantir a saúde, segurança e sucesso


dos projetos, é fundamental seguir os oito princí-
pios resumidos do Código de Ética da Engenharia
de Software:

1. Interesse público: engenheiros de software de-


vem aliar sempre seus projetos com a legislação e
os públicos.

2. Clientes e empregados: a Engenharia de Software


busca equilibrar os interesses de seus clientes, de-
senvolvedores, terceiros e parceiros. Assim, jamais
deseja montar ou direcionar projetos em benefício
próprio.

8
3. Produto: a Engenharia de Software garante que
tudo que for produzido a partir das premissas propos-
tas, alterações e melhorias atendam aos melhores
padrões possíveis, sejam profissionais, de estrutura
e prazo.

4. Julgamento: integridade, honestidade e inde-


pendência nos seus julgamentos profissionais são
itens obrigatórios e garantidos pela Engenharia de
Software.

5. Administração: os líderes e a alta cúpula das


empresas, dentro da Engenharia de Software, têm
a obrigação de disseminar a abordagem ética no
processo de gestão da aplicação.

6. Profissão: engenheiros de software devem pro-


mover a segurança, integridade e reputação da pro-
fissão, entrelaçados à legislação aos interesses do
público, buscando sempre manter a boa reputação
da profissão.

7. Coleguismo: a ajuda mútua entre colegas de de-


senvolvimento de softwares tem como base a união,
justiça e ajuda mútua.

8. Identidade: parte do princípio de que o valor da


prática é essencial para a profissão e seu objetivo é
disseminar sempre uma abordagem ética à prática
da profissão.

9
SAIBA MAIS
Saiba mais sobre os fundamentos, conceitos e
padrões básicos da Engenharia de Softwares, con-
sultando Engenharia de Software: fundamentos,
métodos e padrões, de Paula Filho (2009).

Lembre que é importante ler e saber o que propõe


o Código de Ética da Engenharia de Software, pois
esse código auxilia no que tange a saber aquilo que
pode ou não fazer. O fundamento básico da ética é
zelar pelo interesse público, sem esquecer todo o
contexto do trabalho, sempre alinhados à necessi-
dade do cliente.

Fique atento às pressões do trabalho, alguns se sub-


metem a situações por medo quanto à sua posição,
ao seu emprego, às suas condições de trabalhos e
aos prazos de entrega. A partir dessas premissas,
muitos assumem uma posição contrária ao que se
propõe todo o trabalho e acaba ferindo a ética da
categoria. Note que é o seu nome que está em jogo,
dentro de um mercado de trabalho extremamente
competitivo, sendo assim, cuide de você.

O código de ética veio ajudar a sua carreira, portanto,


busque as melhores práticas, pois elas vão fazer com
que você se torne um profissional melhor.

10
Engenharia de Software
A primeira vez que se usou o termo “engenharia de
software” foi em 1960, devido ao boom de jogos ele-
trônicos e sistemas criados, visto que tudo na área
da tecnologia era novidade. Contudo, foi em 1968
que se batizou oficialmente, pelo comitê científico
da Otan (North Atlantic Treaty Organization).

Aliar tecnologia e engenharia foi uma forma de mudar


a visão da criação de sistemas da época, quando
não se seguia nenhum padrão, como em uma ses-
são de desenho livre, precisava de regras, qualida-
de, mensuração, práticas comuns às áreas exatas e
primordiais nas áreas de engenharia e que, a partir
desse momento, seriam usadas na criação e no de-
senvolvimento de sistemas mais complexos.

Por sistema de software complexo, entende-se o


desenvolvimento cuja base (estruturas de dados e
algoritmos) são os componentes abstratos de sof-
tware, juntos e espelhados como módulos, funções
e algoritmos, objetos ou agentes interligados, dando
vida à arquitetura de software.

Segundo Pressman e Maxim (2016), a Engenharia


de Software nada mais é do que um conjunto de
regras atrelados à tecnologia e que funciona em três
camadas (processos, métodos e ferramentas) e seu
elo, ou seja, o que faz sentido em todas essas cama-
das, é que todas as camadas têm por objetivo um
resultado de qualidade no produto entregue. Vamos,
então, definir cada uma delas:

11
● Processos: são o funcionamento de todas as par-
tes, ou seja, são o elo entre os métodos e as fer-
ramentas, que possibilitam o desenvolvimento de
um software embasado em lógica, racionalidade e
usabilidade. A partir desses processos, monta-se
toda a base para a Engenharia de Software.
● Métodos: trata-se do caminho, isto é, como fazer.
São as regras, as diretrizes, os testes, as premissas
para construir um bom software.
● Ferramentas: são o apoio, o suporte aos métodos
e estabelecem a união entre hardware, software e
banco de dados.

O trabalho realizado pela Engenharia de Software


pode ser dimensionado em três fases, indiferen-
temente da área de aplicação, do projeto ou da
sua complexidade: definição, desenvolvimento e
manutenção.

A partir da Engenharia de software, surgiu uma mu-


dança no desenvolvimento: uma nova ordem para
os testes de implementação que, de acordo com
Pressman e Maxim (2016), seriam unidade, inte-
gração, validação e sistema. Resumindo, podemos
diferenciar Engenharia de Software e Ciência da
Computação assim:

● A Engenharia de Software mantém o foco no modo


lógico, baseado em processos, para produção de um
sistema de software.
● A Ciência da Computação busca uma visão
dentro dos fundamentos teóricos dos aspectos
computacionais.

12
Cabe aos especialistas da equipe propor a metodo-
logia científica a ser aplicada em conformidade com
os modelos abstratos, a fim de especificar, projetar,
implementar e manter funcionando os softwares
desenvolvidos, com garantia de uso e de qualidade.

Além disso, os sistemas criados a partir da


Engenharia de Software devem proporcionar os
meios para que esses mesmos sistemas tenham
processos que se mantenham, com base em plane-
jamento e boas práticas dentro do desenvolvimento.

Nesse contexto, o cenário muda, pois não há mais


um gênio que cria e desenvolve tudo sozinho. Assim,
para que um software seja criado com sucesso, ele
precisa de uma equipe de especialistas que forme
um mercado de empresas especializadas na criação
de softwares, as “Fábricas de Software”.

Principais conceitos de engenharia de


software

Há diversos recursos utilizados para o desenvol-


vimento de software no interior da Engenharia de
Software, mas os insumos são vitais para o desen-
volvimento de produtos de software. Isso significa
que um produto de software desenvolvido para infra-
estrutura de redes, suporte, otimização de recursos,
ERP ou inteligência artificial vai precisar de insumos
para alcançar os objetivos esperado.

Portanto, podemos traçar dois paralelos: de um lado,


percebemos as atividades usadas no processo de de-
senvolvimento de um produto de sistemas; do outro

13
lado, de que maneira a Engenharia de Software ofere-
ce apoio a esse processo de formação de atividades.

Por exemplo, o uso de teorias e princípios aplicados


ao sistema de software a ser desenvolvido, a escolha
dos melhores métodos e técnicas (metodologia),
bem como a facilidade de desenvolvimento com o
uso de ferramentas previstas pela Engenharia de
Software.

Por meio da Figura 1, podemos entender melhor


como a Engenharia de Software trata toda a ques-
tão de um projeto:

Como
Ferramentas
automatizar?
Como
Métodogias
aplicar?
Como
Métodos e técnicas
fazer?
O que
Princípios
fazer?

Figura 1: Resumo dos componentes da Engenharia de Software.


Fonte: Elaboração Própria.

Embora pareçam abstratos em um primeiro mo-


mento, os princípios de Engenharia de Software
são fundamentais para um item não tangível, so-
bretudo quando os utilizamos em um escopo de
projeto. Quando aplicados em um processo de pro-
dução de sistemas de software, eles são firmes e
indispensáveis.

14
Por exemplo, podemos citar o levantamento de re-
quisitos e a análise dos processos de um software,
pois a atividade de análise implica o rigor, a abstra-
ção e a aplicação e separação de conceitos para a
montagem de modelos que vão tratar várias faces
do sistema.

Quando chegada a hora de apresentar um projeto


aos stakeholders, é muito mais prático e interessante
a demonstração do uso de princípios como rigor e
formalidade na implementação, bem como a parte da
documentação dos modelos criados na análise, pois
isso dá ao cliente um panorama palpável do produto,
modularidade aplicada na estrutura do sistema e
incrementabilidade usada nos testes.

Os princípios da Engenharia de Software têm um grau


de importância maior na incidência de planejamento,
desenvolvimento e implantação do software solicita-
do, mas não determinam a qualidade do produto. A
qualidade começa a aparecer quando juntamos mé-
todos, técnicas e ferramentas apropriadas para usar
os princípios no processo de produção de software.

Em suma, os princípios são práticas que foram bem-


-sucedidas e sua aplicação é sempre sugerida na rea-
lização de atividades relativas ao projeto de software.
Nas boas práticas de desenvolvimento de sistemas,
os princípios são seguidos e aplicados para se obter
um produto de qualidade.

Passemos, então, à definição de alguns desses


princípios:

15
● Modularidade: é a divisão de sistemas e, para sua
melhor visualização, podemos pensar em um sis-
tema complexo que é tratado em partes menores.
Assim, cada parte é tradada mais simplesmente de
acordo com suas características dentro do levan-
tamento do projeto (Coesão e Acoplamento). Por
isso, chamamos partes dos sistemas de software de
módulo. Trabalhar com módulos implica o trabalho
com a composição e decomposição: na composição,
juntamos os módulos para deixar o sistema com-
pleto; na decomposição, dividimos os problemas
em subproblemas para tratá-los mais eficazmente.
A modularidade funciona com foco no entendimen-
to de um problema complexo, dividindo em partes
menores como uma estratégia de tratamento. Com
isso, facilitam-se tanto as melhorias quanto a ma-
nutenção do sistema.
● Separação de conceitos: separar os conceitos pos-
sibilita a chance de trabalhar com formas particulares
e diferentes de um mesmo problema. Isso faz com
que a situação seja entendida de uma maneira mais
fácil em todos seus aspectos. Pontos que em con-
junto não seriam vistos, são enxergados e tratados
em um processo particular de abstração.
● Generalidade/Especialidade: refere-se às questões
de soluções genéricas e específicas. Visto que ge-
neralidade trata do todo, impacta nos custos, pois
são necessários mais recursos e mais tempo de
desenvolvimento, o que impacta diretamente na parte
financeira. As soluções específicas são tratadas por
módulos, portanto, recorrem aos mesmos recursos e

16
a um tempo de desenvolvimento menor. Em processo
de desenvolvimento de sistemas, deve-se analisar
muito cuidadosamente para não ter impacto nem
na entrega nem tampouco no custo do projeto de
software.
● Rigor e formalidade: todo processo de criação
surge instável e impreciso, pois para uma ideia ter
valor, ela tem que ter formato, e com o processo de
criação de software não é diferente. Uma ideia chega
abstrata, e o rigor dá forma a essa ideia, tornando-
-a um projeto. A formalidade, por sua vez, trabalha
essa forma até que ela seja entendida por todos e o
processo seja factível de ser implantado, dirigido e
avaliado por regras e leis matemáticas.
● Incrementabilidade: apesar de ser um pouco difícil,
essa palavra determina como vamos fazer acontecer.
Ela prepara o caminho para que todo o processo de
desenvolvimento seja acompanhado passo a passo.
Funciona como um manual para chegar ao objetivo
desejado dentro do desenvolvimento. É muito útil
quando não temos ainda todos os requisitos prontos,
antes do início do desenvolvimento da aplicação.
● Antecipação de mudanças: diz respeito a criar e
desenvolver um software que seja capaz de uma
possível evolução e melhorias no futuro, de forma a
tornar sua manutenção e perpetuação mais fáceis e
a um custo baixo. Depois de pronto e em uso, todo o
sistema pode ser incrementado, melhorado a partir
do feedback dos usuários.

17
Métodos e metodologia em Engenharia
de Software

Primeiramente, é essencial entender que metodologia


e método nem sempre significam a mesma coisa,
e a ciência discute largamente isso. No geral, são
tratados como sinônimos, mas a literatura científica
tem algumas vertentes que afirmam que o método
funciona apenas para um determinado processo, ao
passo que a metodologia funciona para um conjunto
de processos e métodos.

A fim de entender melhor, é necessário saber da ori-


gem dessas palavras: méthodos é uma palavra grega
que significa “caminho para se chegar a um fim”; e
metodologia significa o estudo do melhor caminho
para se chegar a um fim, uma vez que logia é uma
palavra grega que significa “estudo de”.

Há também a definição segundo a qual o método


nada mais é do que um processo, ou seja, o passo
a passo para executar o processo; enquanto a meto-
dologia é um conjunto desses métodos e boas ações
para colocá-los em prática.

Nesse contexto, tomamos como exemplo um méto-


do da Engenharia de Software que pode ser notado
como uma parte da metodologia. Até este momen-
to, a Engenharia de Softwares tem se baseado nos
processos; logo, está cheia de métodos, mas ca-
rece de metodologias. Por isso, listamos as princi-
pais Metodologias de Desenvolvimento de Software
da Engenharia de Software:

18
● Metodologia Estruturada.
● Metodologia Orientada a Objetos.
● Metodologias de Desenvolvimento Ágil.

E também alguns exemplos de métodos em


Engenharia de Software:

● Máquina de estado finito.


● Práxis.
● CDM.
● Flowcharting.
● Programação estruturada.

Modelo de processo de software

Trata-se de um mapa de processos por meio do qual


é possível visualizar a abstração e todas as ativida-
des do projeto de software. É, sem dúvida, um exce-
lente recurso para representar o desenvolvimento do
software e o progresso do projeto. São exemplos de
modelos de processos:

● Modelos ciclo de vida:

○ Cascata ou sequencial: tem fases próprias de es-


pecificação de requisitos, desenvolvimento e projeto.
○ Desenvolvimento interativo e incremental: compõe
um subconjunto de requisitos de software e age de
maneira agregada às outras partes do desenvol-
vimento, cresce no projeto (pode, inclusive, sofrer
melhorias de versão mesmo no desenvolvimento)
até a implantação do sistema completo.

19
○ Evolucional ou prototipação: no projeto, são mon-
tados protótipos das fases do resultado a partir do
planejamento e da especificação.
○ V-Model: é mais bem organizado e tem compara-
tivos com modelos mais modernos.
○ Espiral: são demonstrações dos ciclos completos
de especificação através da evolução espiral do pro-
jeto e desenvolvimento.
○ Componentizado: são as melhorias e o uso do
módulo para o desenvolvimento de outros módulos
a partir de componentes já existentes.

Os modelos, os métodos e a metodologia caminham


juntos na Engenharia de Software. Por isso, temos
um exemplo dessa união na qualidade de ciclo de
vida de um processo de software, de acordo com a
ISSO 9126 (Figura 2):

produto de efeitos do
processo software produto de
software

Atributos da Atributos da Atributos da


Qualidade do
qualidade qualidade qualidade em
processo
interna externa uso

Medidas Medidas Medidas Medidas de


de processo internas externas qualidade em
uso

influencia
depende de

Figura 2: Junção de modelos, métodos e metodologia. Fonte:


Elaboração Própria.

20
Projetos em Engenharia de Software
A ideia de projeto carrega, mesmo que implicitamen-
te, o desenvolvimento de software. Vamos, então,
entender o conceito de projeto.

Podemos entender projeto como uma atividade que


tem princípio e fim, que seja temporária e englobe
um conjunto de atividades finitas e interligadas em
um período preestabelecido.

Um projeto tem várias fases com as quais se podem


controlar ou rastrear os processos, e os ciclos são o
tempo que as fases vão durar. Assim, entendemos
que, para montar um projeto relativo a um software,
precisamos nomear as fases como: requisitos, testes,
fases de implementação. Por exemplo, um projeto
de construção de um prédio tem nomes diferentes
para cada fase, como edificação, concretagem etc.
Portanto, os nomes das fases dependem do projeto
e do que se pretende entregar.

Essas fases são definidas na declaração inicial de es-


copo, seguindo ao longo do projeto (PMBOK, 2012).

A gerência/gestão de projetos

A gerência de projetos tem como premissa básica a


entrega de um projeto bem-sucedido, ou seja, confor-
me foi solicitado pelo cliente, dentro dos requisitos
estabelecidos, respeitando o orçamento e o prazo.

Quando trabalhamos em um projeto de software,


entendemos que o resultado é um produto abstra-

21
to e intangível, pois toda a execução pode mudar o
escopo ao longo do projeto. Cabe, então, ao gerente
de projeto trabalhar dentro desse cenário de maneira
que o produto alcance um bom resultado, ou seja,
dentro do acordado, respeitando limitações financeira
e o prazos.

É fundamental portanto que o projeto dentro da enge-


nharia de software siga as etapas segundo o PMBOK
de concepção, análise, projeto, desenvolvimento,
testes e manutenção.

Segundo Pressman e Maxim (2016), para um proje-


to de software alcançar os resultados esperados, é
necessário que itens como escopo, riscos, tarefas,
indicadores e custo sejam acompanhados de perto.
Portanto, a gestão de projetos é fundamental para a
Engenharia de Software, e a gerência de projetos é
primordial para o resultado favorável de um projeto
de software.

Modelos e Características de
Qualidade
Normas, modelos e métodos da Engenharia de
Software somados à qualidade têm como objetivo
maior o sucesso do software criado. Para isso, du-
rante o processo de criação, levantamento de escopo
e montagem do projeto, a qualidade precisa atender
tanto ao processo quanto ao produto.

A conformidade com os requisitos funcionais e o


desempenho dos sistemas são tópicos requisita-

22
dos durante o desenvolvimento de um projeto de
software, o que torna possível criar um sistema de
qualidade (GUERRA; COLOMBO, 2009).

O tema qualidade de software é balizado pelas nor-


mas e diretrizes disseminadas pelo mundo e ado-
tadas por diversas instituições. As normas são fun-
damentais para os modelos de qualidade atingirem
seu objetivo.

Entre as diversas normas, vamos citar algumas que


tratam somente de qualidade de produto de software:

● ISO/IEC 14598: é um conjunto de normas para


direcionar e construir a sequência de processos de
avaliação de um software.
● ISO/IEC 12119: é um conjunto de normas para
avaliar produtos de software disponíveis no mercado,
conhecidos como produtos de prateleira.
● ISO/IEC 9126: é um conjunto de normas internas
e externas que define a qualidade de um software.
● Software Product Quality Requirements and
Evaluation (Square): é um conjunto de normas que
contempla uma nova visão do processo e uma nova
abordagem das normas para a qualidade de produto
de software.

Em um projeto, há muitos meios possíveis de desen-


volver um produto de qualidade de acordo com méto-
dos, técnicas e avaliação, isto é, pode-se avançar na
criação de softwares. Com isso, novas empresas em
novos negócios são capazes de garantir e assegurar

23
a qualidade. Observe, na Figura 3, que as normas
convergem nessa estrutura:

Qualidade do produto de Medidas de qualidade


Indicam
software de software

Composta de Gera

Características de Função de
qualidade medição

Composta de São aplicados a

Subcaracteristicas de Elementos de medida de


qualidade qualidade

Figura 3: Estrutura da qualidade de software. Fonte: Elaboração Própria.

A qualidade tem de ser integrada às empresas e tor-


nar-se um processo real e diário, ou seja, todos os
membros e processos da empresa têm de se pautar
dentro de normas e conceitos de qualidade. Somente
assim a qualidade de fato será parte da estrutura,
dos recursos e dos métodos que vão constituir um
sistema de qualidade dentro da empresa.

O que é qualidade?

Podemos tratar a qualidade como um conceito sub-


jetivo, como o entendimento e a maneira de dar quali-
dade a produtos, serviços, pessoas, softwares, enfim
a tudo. Essa palavra tem sua origem na palavra em
latim qualitate, que quer dizer o melhor, de acordo
com as percepções de cada um. Assim, o conceito
de qualidade está atrelado ao melhor de cada um.

24
Em linhas gerais, no mundo empresarial, pode-se
definir qualidade como um conjunto de atributos cuja
finalidade é o atendimento das necessidades dos
clientes e ao padrão de produtos e serviços dispo-
nibilizados por uma empresa.

Esse conjunto de atributos pode ser classificado


como:

● Moral: significa caráter, trazer para si e para a equi-


pe o valor agregado do seu trabalho na produção
de qualquer produto. É a base de uma organização,
um pilar.
● Qualidade intrínseca: são critérios de qualidade
usados na fabricação de produtos e sua consonância
com as leis, bem como a qualidade do produto dentro
dos parâmetros oferecidos ao mercado.
● Entrega: significa cumprir os prazos dentro da qua-
lidade esperada.
● Custo: é o alinhamento entre a relação custo-be-
nefício na produção de um produto.
● Segurança: são as condições de produção do pro-
duto, que podem ser internas (na produção) e exter-
nas (dentro das normas de segurança) ao cliente.

Quanto à qualidade dentro das empresas, podemos


afirmar que se trata de um processo contínuo de
melhorias (SOLTANI; LAI; JAVADEEN; GHOLIPOUR,
2008). De acordo com as normas internas e externas,
a qualidade dá ao cliente a segurança de saber que
vai levar exatamente o que comprou. Para entender
melhor a evolução da qualidade, analise a Figura 4:

25
Linha do tempo - Evolução de qualidade

Sistema de gestão de processos e


2015 em diante
riscos

Sistema de gestão de anos 2000


procesoss

Sistema de gestão de
anos 90
qualidade

Garantia de
anos 80
qualidade

Controle de
qualidade anos 60

Inspeção anos 30

Figura 4: Evolução da qualidade. Fonte: Elaboração Própria.

O conceito de qualidade evoluiu muito desde o


Taylorismo-Fordismo, período em que o trabalho
começou a ser produtivo e em série. Na Primeira
Guerra Mundial (1914-1919), o problema com a qua-
lidade se agravou, e o americano Walter A. Shewhart
revolucionou o mercado com seu artigo Economic
Control of Manufactured Products (1931). Nisso,
o conceito de inspeção se expandiu. Na Segunda

26
Guerra Mundial (1939-1945), expandiram-se os con-
ceitos de qualidade e prazos. Na década de 1960, o
Japão entra na guerra pela qualidade com o modelo
5S, evoluindo para o controle de qualidade com os
conceitos:

● SEIRI: organização, utilização, seleção, descarte,


classificação.
● SEITON: arrumação, ordenação, sistematização,
organização.
● SEISO: limpeza, inspeção, zelo.
● SEIKETSU: padronização, saúde, asseio, higiene,
aperfeiçoamento.
● SHITSUKE: autodisciplina, autocontrole, harmonia,
educação.

Na Figura 5, temos uma divisão de como isso se


distribui:

Figura 5: Como funciona o 5 S. Fonte: Medium

27
O Controle Total da Qualidade (CTQ) foi trazido para
o Brasil pelo engenheiro Vicente Falconi Campo. O
conceito do CTQ é formado pelos seguintes itens:

● Cliente e qualidade em primeiro lugar.


● Prioridades.
● Fatos e dados.
● Processos.
● Dispersão.
● Processos do cliente.
● Controle a montante, ação de bloqueio.
● Funcionário é ser humano.
● Comprometimento da alta administração.

As normas da ISO têm evoluído desde seu surgimen-


to, trazendo o conceito de gestão e riscos. Portanto,
a estrada percorrida pela qualidade é grande, pois
tem acompanhado os grandes fatos da humanidade,
atingindo a tecnologia e a área de softwares.

Modelos e normas de qualidade

A propósito de atender aos requisitos de qualidade


direcionados aos softwares, modelos, metodologias
e normas são fortes aliados da melhoria dos proces-
sos internos, através de uma produção de qualidade
com o uso da normatização de produtos e serviços.

Ter um programa de qualidade dentro da empresa


significa que a qualidade começa com um processo
de documentação dos processos, em que se criem

28
rotinas de processos realizados. A partir desse ponto,
como se pode conferir em um mapa, promovem-se
melhorias dentro das normas ditadas pelos critérios
de qualidade.

Esse levantamento mede todas as atividades reali-


zadas na empresa, tudo que é necessário para que
o processo seja realizado, desde a estrutura (física e
lógica) até os recursos necessários (humanos, har-
dware e software).

Com isso, as mudanças necessárias acontecem e


passam a medir segundo os indicadores (resultados)
auferidos a partir da implantação de normas e pa-
drões de qualidade. Dentro da qualidade de software,
podemos destacar alguns indicadores de qualidade:

● Referente ao produto.
● Referente ao processo de desenvolvimento.
● Referente ao nível de maturidade.

No tocante a resultados na implantação de um siste-


ma de qualidade, o carro-chefe é controlar e avaliar
a produção em todas as suas fases. O controle de
qualidade faz parte da fase em que o mercado se
encontra atualmente, seja ele de tecnologia seja de
qualquer outro seguimento. A ISO nos traz exatamen-
te isso: o foco na gestão de qualidade de processos.
Contudo, tudo isso só faz sentido quando está atre-
lado à satisfação do cliente.

Os resultados são visíveis, pois as normas se torna-


ram poderosas ferramentas para a produtividade e
a inovação, elevando as empresas a outro patamar,

29
trazendo facilidade e economia ao dia a dia, promo-
vendo o sucesso. Tudo isso com a garantia de que
os produtos consumidos foram submetidos a um
controle de qualidade, o que nos dá segurança de
ter algo realmente bom nas mãos.

A Organização Internacional de Padronização (ISO)


edita padrões e normas desde 1947. Tais normas e
padrões visam a melhorar a qualidade de produtos,
produção ou serviços.

Essas normas tratam de vários processos, os quais


perpassam a construção de softwares, o desenvolvi-
mento, a usabilidade, o valor de mercado e a gestão
ambiental agregada à segurança da informação. Em
outras palavras, perpassa todos os seguimentos de
mercado.

A aplicação das normas de qualidade traz harmonia,


de modo que a expectativa do cliente e a produção
do produto sejam direcionadas ao mesmo fim, o que
melhora e traz os seguintes benefícios:

● Melhora e facilita as trocas comerciais nacionais


e internacionais.
● Melhora a estrutura da economia.
● Melhora a proteção e a confiança dos
consumidores.

Além disso, as normas certificam produtos e serviços


no mundo todo, e tudo isso pautado nas diretrizes
que norteiam a implantação dentro das empresas de
um Sistema de Gestão de Qualidade. A partir desse

30
momento, há um sistema de gestão de qualidade,
que é a série de normas da ISO 9000 (de 9000 a
9004), as quais têm orientado desde o atendimento
até a produção final da empresa, implementando um
novo conceito de qualidade total.

Dentro da família ISO 9000, temos a ISO/IEC 9126,


uma norma criada especialmente para a qualidade de
desenvolvimento de produtos de software. A norma
contempla um conjunto de parâmetros cujo foco
principal é a padronização da inspeção e a qualidade
de software. Observe a Figura 6:

Qualidade
interna
e externa

Funcionalidade Confiabilidade Usabilidade Eficiência Manutenibilidade Portaibilidade

• Maturidade • Adaptabilidade
• Adequação • Inteligibilidade • Comportamento em • Analisabilidade
• Tolerância e falhas • Capacidade para ser
• Acurácia • Apreensibilidade relação ao tempo • Modificabilidade
• Recuperabilidade instalado
• Interoperabilidade • Operacionabilidade • Utilização de • Estabilidade
• Conformidade • Coexistência
• Segurança de acesso • Atividade recursos • Testabilidade
• Capacidade para
• Conformidade • Conformidade • Conformidade • Conformidade
substituir
• Conformidade

Figura 6: Resumo da qualidade. Fonte: Elaboração Própria.

Em relação às normas referentes à qualidade de sof-


tware, muitas foram criadas de uma maneira especial
para atuar na qualidade de software, mas vamos à
ISO/IEC 14598, que tem destaque especial por avaliar
se a empresa ou entidade que vai desenvolver o sof-
tware atende a todos os requisitos necessários para
fabricar um sistema. Já a norma ISO/IEC 15504 foi
desenvolvida a partir de um estudo sobre a necessi-
dade de padrões internacionais para a avaliação de
processos de software.

31
Seguindo a lógica de conceito quanto às normas
ISO, temos:

● Primeiro: estabelece-se um padrão de qualidade


para o software dentro da família de normas ISO
9000.
● Segundo: estabelece-se um padrão de qualidade
das empresas que vão desenvolver o software.
● Terceiro: estabelece-se um padrão internacional
de desenvolvimento de software.

Na Figura 7, temos um mapa mental de como tudo


está inter-relacionado:

• Confidencalidade • Modularidade
• Maturidade • Integridade • Recusabilidade
• Disponibilidade • Não recuperação • Analisibilidade • Adaptabilidade
• Tolerancia a Falhas • Accountability • Modificabilidade • Instabilidade
• Recuperabilidade • Autenticidade • Testabilidade • Substituibilidade

Confiabilidade Segurança Manutenbilidade Portabilidade

Qualidade de produto de
sistema e software

Adequação Funcional Eficiencia de Compatibilidade Usabilidade


Desempenho
• Completude • Co-existência • Adaptabilidade
funcional • Comportamento de
• Interoperaibilidade • Instabilidade
• Correção funcional tempo
• Substituibilidade
• Propriedade • Utilização de
funcional recursos
• Capacidade

Figura 7: Qualidade de produto de sistemas e softwares. Fonte:


Elaboração Própria.

Concluímos que, dentro das normas ISO, a qualidade de


software na Engenharia de Software trabalha com padrões
internacionais de qualidade, para clientes e empresas.

32
FIQUE ATENTO
O que significa IEC?
IEC é um acrônimo de International Electrotechnical
Commission. Trata-se de uma organização mundial
que prepara e publica Normas Internacionais em
parceria com a ISO. Assim, comprova a qualidade
para as áreas de tecnologia, elétrica, eletrônica e cria
normas e certificados para áreas como eletrônica, re-
des, eletromagnética, performance, segurança e meio
ambiente. As Normas da IEC atestam e facilitam o
comércio internacional, tendo como base as normas
que servem de referência para o funcionamento do
acordo sobre Barreiras Técnicas ao Comércio da
Organização Mundial do Comércio (OMC).

A qualidade de software não se restringe às normas


ISO. Na década de 1980, o Departamento de Defesa
dos Estados Unidos criou um modelo de avaliação de
risco chamado Capability Maturity Model (CMM), ou
Modelo de Maturidade e Capacitação. A partir dos anos
1990, sofreu uma evolução e passou a ser Modelo de
Maturidade da Capacitação para Software (CMMI).

O modelo de riscos passou a ser um manual das


melhores práticas para o desenvolvimento e a pro-
dução de software. Vem com a proposta para que
empresas e organizações produtoras de software
entrem em um processo de evolução, de acordo com
os níveis de capacitação e maturidade impostos nas
melhores práticas, ou seja, a mudança da empresa,
acompanha a mudança na a produção de software, e

33
ambos caminham com a qualidade esperada, prazos
e recursos acordados.

Baseado na Engenharia de Software, o CMMI foca a


documentação dos processos e pauta melhorias a
partir do que está documentado, mesmo que exis-
tam adaptações de acordo com a cultura organiza-
cional da empresa, ou modificações já constituídas
em projetos por ela desenvolvidos, minimizando os
impactos negativos do retrabalho, custos com re-
cursos adicionais, processos desorganizados, fatos
decorrentes da falta de documentação e análise.

Além disso, o Brasil também tem um padrão criado


para a melhoria de desenvolvimento de software: O
modelo MPS.BR.

O Modelo MPS.BR (Melhoria de Processo do Software


Brasileiro) foi criado em 2003 pela Associação para
Promoção da Excelência do Software Brasileiro
(Softex) com vistas a criar um padrão brasileiro
para empresas brasileiras de desenvolvimento de
software, com reconhecimento nacional e interna-
cional, mas com custo mais baixo em certificação
(SOFTEX [s. d.]).

Existem normas e procedimentos diversos, e até


entendemos o que eles significam para a qualidade
de software.

FIQUE ATENTO
Muitas são as normas e certificações na área de
qualidade de software. Para aprofundar seu en-

34
tendimento em normas ISO, acesse o site: http://
www.abnt.org.br.
Você pode entender mais do modelo CMMI se ins-
crevendo em: https://cmmiinstitute.com/. Também
pode acessar o modelo brasileiro na integra em:
http://softex.br/mpsbr/modelos/#mpssw

Aplicação da qualidade em softwares

Erros e defeitos geram custos que oneram os pro-


dutos. Quando falamos em qualidade, o impacto é
grande para empresas e usuários. Pense no risco,
por exemplo, de um software instalado na UTI de
um hospital apresentar defeitos.

O hospital terá que contratar recursos para avaliar e


consertar, mas a vida dos pacientes estará em risco.
Trata-se de um caso que poderia ser checado antes,
se os riscos fossem levantados no desenvolvimento
do software.

Então, quer dizer que usando qualidade no desen-


volvimento de software os problemas acabam? A
resposta é não. Mas eles podem ser tratados antes;
o problema que aconteceu depois de implantado
pode ser resolvido com testes antes da implantação.

Se a qualidade de software não fosse aplicada, ne-


nhuma empresa de software sobreviveria, mediante
perdas financeiras com consertos. A tecnologia é
um item que já foi incorporada à nossa civilização.
Uma simples alteração em um número, como quando

35
adicionaram o 9 aos celulares, sem a aplicação de
qualidade, seria uma grande catástrofe.

Quanto mais fácil, prático e com as melhores con-


dições de segurança e manutenção, mais interes-
sante é um software. A qualidade de software gera
segurança, pois toda estrutura de desenvolvimento
baseia-se em normas e procedimentos que geram
produtos de qualidade. Sempre em conformidade
com as necessidades dos usuários.

Melhoria da Qualidade de
Software
Dentro de todo o processo de qualidade, temos o
de melhoria contínua, desde a fase de testes até a
implantação. Serve tanto para pequenos projetos
(aplicativo de smartphone) quanto para projetos de
grandes empresas. Nesse processo, o usuário final
tem um papel primordial, porque parte da premissa
que todos os processos são avaliados, o usuário é a
melhor pessoa para nos falar se o software entregue
é condizente com o que foi pedido, planejado e feito.

Para isso, recorremos a duas ferramentas simples


antes, durante e depois do desenvolvimento de
software:

● Ações corretivas: são apontadas na fase de teste


do software e estão ligadas a não conformidades.
Por exemplo, softwares com falhas na exposição de
dados de clientes, que são detectadas e corrigidas a
tempo para não gerar impactos ruins à empresa, por-

36
que é uma falha relevante. Isso entra em um padrão
de não conformidade, dentro dos padrões de quali-
dade, e que pode ser melhorada. As ações corretivas
podem acontecer depois da implantação também.
● Ações preventivas: são ações levantadas antes
que o problema aconteça, antes de gerar uma não
conformidade. Em geral, durante o levantamento de
riscos, são levantados os riscos, as ações preventivas
que eliminam ou diminuem o impacto na implantação
do software.

Essas ações funcionam na prática mais ou menos


assim: criei um aplicativo para entregar gás, mas ele
misturava os preços. Detectei o problema a partir de
um teste, no qual as tabelas de preços não estavam
configuradas corretamente. Tirei o aplicativo do ar e
apliquei as ações corretivas e preventivas:

● Ação corretiva: ao detectar o problema das tabelas,


corrigi o problema de desenvolvimento e progra-
mei uma manutenção e a atualização periódica das
tabelas.
● Ação preventiva: antes da liberação do aplicativo,
listei as modificações feitas, informei e treinei os
usuários para uso do aplicativo, coloquei em período
de testes e corrigi os problemas no cronograma de
manutenção, para isso não ocorrer jamais.

O projeto não acaba na implantação, o acompanha-


mento do produto, sua manutenção e melhorias têm
de ser constantes.

Acesse o Podcast 1 em módulos

37
Otimização nos processos de criação de
software

O mundo está cada vez mais rápido, e as empresas


de sistemas buscam a padronização de processos, e
a gestão de projetos busca a otimização dos produ-
tos e o sucesso nas entregas, bem como a melhoria
contínua de produtos e operações.

Então, a Metodologia Ágil (ágile) aparece trazendo


uma proposta diferente, que acompanha o ritmo do
mundo, pois tem a rapidez nas entregas, o trabalho
em equipe e a diminuição de hierarquia, fatores que
trazem ganhos rápidos. Chamam a atenção das orga-
nizações que trabalham diretamente em seguimentos
atrelados à tecnologia.

A Metodologia Ágil vem com a proposta de melho-


rar a qualidade e a produtividade dos projetos. Com
isso, chegamos à conclusão de que ela é capaz de
melhorar realmente as perspectivas de sucesso do
seu negócio.

A partir das mudanças propostas no Manifesto Ágil,


muitas ferramentas foram criadas e chamadas de
metodologias ágeis, por apenas agilizar o lado ope-
racional da equipe, melhorando a sua produção.

Essa metodologia não deixa de ser um modelo pio-


neiro de projeto que visa a transpor barreiras para dar
autonomia às empresas que buscam agir quando há
atrasos e eventuais problemas nos projetos. Além da
divisão de fases, há os ciclos pequenos de entrega
que promovem maior conexão entre clientes e equipe

38
de desenvolvimento. Esses ciclos de entregas par-
ciais dão ao cliente o valor agregado de resultado,
antes mesmo de o projeto terminar.

E qual é a implicação do Manifesto Ágil


em meio a tudo isso?

A história começou nos EUA, nos anos 2000, quan-


do um grupo de 17 desenvolvedores renomados se
reuniu em Utah, para encontrar a melhor forma de
desenvolvimento; seu objetivo era encontrar novos
meios de execução dos projetos baseados em experi-
ências, pois o modelo tradicional já não se encaixava
na nova realidade.

Nasceu assim o documento assinado por eles, o


chamado Manifesto para o Desenvolvimento Ágil de
Software, no qual foram criadas as bases da metodo-
logia ágil, do qual destacamos quatro fundamentos-
-chave, que norteariam os projetos:

● Indivíduos e interações eram mais importantes do


que os processos e as ferramentas.
● Softwares funcionais e otimizados eram mais im-
portantes do que uma documentação abrangente.
● Colaboração ao consumidor/cliente satisfeito aci-
ma de uma negociação de contratos.
● Responder a transformações/mudanças viáveis
no meio do projeto, nada engessado.

O conceito de projetos agora passa a ser aquele em


que o cliente estivesse satisfeito, e que agregasse

39
valor ao que foi produzido e entregue a ele. O trabalho
aqui é conjunto e agregado.

O cliente passa a ser a peça-chave dos projetos, o


que faz com que a metodologia junte sua filosofia
e um tratado das melhores práticas e regras de de-
senvolvimento para otimizar e melhorar as fases e o
projetos entregues, assim como os itens produzidos.

Portanto, chega-se ao conceito de que as metodolo-


gias ágeis têm como objetivo otimizar e obter resul-
tados de maneira mais firme do trabalho das equipes
de projetos proporcionando aos clientes, os melhores
resultados foram gerados a partir dos 12 princípios
(SANTOS, 2013):

● A prioridade é a satisfação do cliente; isso ocorrerá


por meio de entregas de valor agregado e contínuo
e em prazos rápidos.
● O projeto é aberto a mudanças nos requisitos, mes-
mo que já levantados, em qualquer fase do processo.
Ambientes flexíveis podem ser aplicados em qual-
quer fase do projeto para que a entrega ao cliente
crie, por exemplo, lucros ou vantagens de mercado.
● Entregas frequentes (fases de curto prazo para
projetos de produto ou serviço).
● Envolvimento da equipe de projetos e cliente em
todas as entregas do projeto.
● Ambiente favorável para clientes e equipes de su-
porte, com acesso a ferramentas, suporte e projeto
(ambiente transparente).

40
● Uso da comunicação contínua e pessoal sem
muitas barreiras para a equipe e para os clientes,
entrosamento das partes. Aqui chamamos a aten-
ção especial para reuniões presenciais sempre que
possível, pois são as mais eficientes para o sucesso
do projeto.
● Um projeto entregue com sucesso é um projeto
entregue no prazo e funcionando. No caso da tecno-
logia, o produto entregue consiste em entregar um
software funcionando.
● O ritmo de trabalho dos profissionais envolvidos
no processo em que usamos a metodologia ágil tem
que manter o ritmo de trabalho independente de mu-
danças, porque os processos de fluxos ágeis tendem
a estimular uma entrega harmoniosa e sustentável.
● Ater-se sempre à excelência de design e técnica,
melhora e atinge resultados mais satisfatórios do
que os esperados, além da rapidez das entregas.
● Cortar os esforços que não agregam valor ao pro-
duto, porque a otimização, a desburocratização e a
simplicidade são primordiais.
● Equipes coesas e autogeridas, bons profissionais
que conseguem deslanchar tanto o desenvolvimento
quanto a comunicação com o cliente sem burocra-
cia, capazes de resolver problemas sem colocar o
projeto em risco.
● Intervalos regulares de planejamento, o time de
colaboradores do projeto em processo de melhoria
contínua busca otimizar o seu comportamento e
prazos ao longo do projeto.

41
Com o aumento da satisfação do público com entre-
gas rápidas e comunicação constante entre a equipe
de desenvolvimento do projeto e os clientes, a redu-
ção de custos é clara, porque não há necessidade
de um time enorme, mas sim de um time eficiente.

A redução dos prazos de entrega e o valor agrega-


do das entregas mostram que é possível fazer um
casamento feliz entre o planejado no cronograma
de execução de orçamento do projeto, o valor agre-
gado com as etapas e entregues de acordo com as
necessidades dos clientes.

O impacto da melhoria na entrega dos


softwares

Melhorias no caso do desenvolvimento de software


passam por algumas fases que determinam o proje-
to. A melhoria de processos, implícita na engenharia
de software e presente na qualidade dos softwares,
tem como objetivo principal a entrega do melhor
produto possível, dentro do menor prazo e custo.
Assim, tende a otimizar cada uma das atividades do
projeto a implantação, promovendo a escalabilidade,
a mensuração, a eficiência e a eficácia em cada fase
do projeto, eximindo custos extraordinários, otimi-
zando processos e trazendo ganhos ao processo de
desenvolvimento e implantação.

Analisemos quatro pontos essenciais para a melhoria


de processos acontecer:

42
● Contato com o cliente: é o momento de interação
com o cliente e com o qual se expressa sua opinião,
ou seja, se é satisfatória ou não.
● Gargalos no desenvolvimento: são os pontos crí-
ticos, com grau de risco médio ou alto que afetam o
projeto de software e têm impacto direto no tempo
do projeto, provocando atrasos, acúmulo de tarefas
e, caso não sejam resolvidos a tempo, tornam o de-
senvolvimento de software um fracasso.
● Valor agregado a entregas e atividades: as entre-
gas e atividades de um projeto de desenvolvimento
de software têm que agregar valor ao negócio do
cliente, por isso devem caminhar para melhorar ao
máximo seu valor para o negócio, pois são os pro-
cessos que agregam vantagens aos clientes.
● ​Integração de sistemas: pode-se ter a opção dos
softwares com integração com outros sistemas,
facilitando as melhorias e com um plano de conti-
nuidade, pois há condições da troca de informações
e economia com a compra de outros softwares.

Com a evolução da tecnologia, foram necessárias al-


gumas técnicas de melhoria dos processos. A seguir,
listamos algumas que têm feito sucessos na busca
por produtividade, economia e eficiência:

● Business Process Management (BPM): na busca


por melhoria de processos, é uma metodologia que
visa a analisar os processos e a influência do am-
biente externo no ambiente interno das empresas.
Seu ponto forte são a transparência das informa-
ções e os procedimentos, isto é, o apontamento de

43
processos assim que podem ser melhorados. Como
trabalha em cima dos processos da empresa e com
transparência, promove uma gestão e controle ad-
ministrativo eficazes, com mais automação e ganho
de produtividade.
● Ciclo PDCA: é uma poderosa ferramenta usada
pelas empresas devido à sua simplicidade e eficácia,
pois em quatro passos é possível fazer um planeja-
mento estratégico, estudar os processos, melhorá-
-los e promover um acompanhamento contínuo, pois
suas quatro fases são: Planejar, Fazer, Avaliar e Agir.
É extremamente importante nos ciclos de melhoria
contínua (Figura 8):

Melhoria Ajustar Planejar

contínua

Estudar Executar
Ajustar Planejar

Padrão
Estudar Executar
Melhoria
de qualidade
Consolidação
Padrão através de
padronização

Tempo

Figura 8: Ciclo PDCA. Fonte: Elaboração Própria.

● Capability Maturity Model Integration (CMMI): é a


melhoria de uma metodologia. É praticamente um
sistema de maturidade em desenvolvimento de sof-
twares. Baseado em processos, podemos dividi-lo
em três partes que são referência de boas práticas
na melhoria dos processos:

44
○ CMMI-DEV: criada para desenvolvimento de
softwares.
○ CMMI-SVC: criada para o fornecimento de serviços.
○ ​CMMI-ACQ: criada para a aquisição de produtos
e serviços.

Um diferencial muito importante CMMI é a certifica-


ção que garante à empresa um modelo baseado em
maturidade em desenvolvimento específico de sof-
tware nacional e internacionalmente. Uma empresa
com certificação CMMI é possível ter excelência de
qualidade tanto no desenvolvimento, atendimento
e na entrega de um software, e seus resultados são
garantidos. E isso é um diferencial no mercado.

Acesse o Podcast 2 em módulos

Segurança de Software
Atualmente, a informação é uma arma estratégica
em qualquer empresa e um triunfo ou fracasso de
acordo com a gestão. A segurança da informação
tem função primordial e faz parte do negócio, não
do suporte das empresas.

Dependendo do nicho de negócio, falhas de segu-


rança trazem prejuízos enormes para as organiza-
ções. Portanto, é primordial que todas as vulnerabi-
lidades sejam de estrutura, sistema e dados sejam
bloqueadas.

45
O que é vulnerabilidade?
A vulnerabilidade é definida como uma falha que
pode ser explorada e que pode terminar como uma
inacessível. As vulnerabilidades dos softwares não
estão restritas ao desenvolvimento, mas a todo o
ambiente relacionado, como estrutura, dados e am-
biente. Dentre milhares de formas de ataques às vul-
nerabilidades, enumeramos oito para nosso melhor
entendimento:
1. Controle de acesso físico e remoto a áreas restri-
tas da empresa: controle de acesso tem que passar
por um crivo da segurança da informação. Muitas
falhas acontecem por acesso indevido.

2. Sustentabilidade: ameaças naturais existem, e


a empresa tem que manter uma rotina sólida de
backup mínimo e uma rotina de contingência e di-
saster recovery, pois alagamentos, incêndios e ou-
tros desastres naturais podem acontecer, por isso,
é necessário reconstruir o ambiente.
3. Gente: muita gente acha que é hacker e gosta
de invadir e-mails, empresas, mas só conseguem
porque as portas estão abertas para isso acontecer.
Políticas de segurança são primordiais em uma em-
presa, assim como o treinamento dos funcionários.
4. Investimento em estrutura: máquinas velhas, falta
de firewall, antivírus, data center local, falta de atuali-
zações, licenciamento vencido, rede elétrica precária,
rede física em frangalhos etc., tudo isso contribui
para que existam brechas vulneráveis.

46
5. Investimento em sistemas: atualizações de sis-
temas de acordo com a política da empresa e a le-
gislação vigente.
6. Dispositivos externos: voltamos à política de se-
gurança, HD externo, pen drives etc., têm que ter
local e política dentro da empresa para ser usados,
tudo isso respeitando acesso, hierarquia e proteção
de dados.
7. Softwares de comunicação: Skype, WhatsApp,
Messenger do Facebook, acessos fora da rede, sem
notificação também tem que se enquadrar nas polí-
ticas de segurança da empresa.
8. Alinhamento na comunicação da empresa: uma
política de segurança da informação só funciona
quando é disseminada por toda a empresa.

Lei de proteção de dados e Qualidade de


software

A Lei Geral de Proteção de Dados entrou em vigor


em setembro de 2020. Atualmente, as empresas de
software têm se movimentado para capacitar os
especialistas em desenvolvimento de acordo com
a legislação, com isso, podem atender a todos os
requisitos, inclusive aos requisitos de segurança.

A lei tem regras mais rigorosas quanto ao consenti-


mento explícito para a coleta de dados dos usuários
e o uso desses dados. Há toda uma rotina a ser cum-
prida, que deve aparecer aos usuários uma opção de
visualizar seus dados, corrigir e excluir esses dados.

47
Por outro lado, é preciso que os usuários entendam
quais são os riscos que correm por conta da priva-
cidade dos seus dados. Os princípios que norteiam
a lei são os seguintes:

● Qualidade: com base nos princípios das normas


de desenvolvimento no que tange à qualidade das
informações, a lei chama a atenção para a segurança
digital. As empresas precisam focar nesse item e
adequar os softwares a essa nova realidade.

● Consentimento: há necessidade de que os softwa-


res deixem claro para o usuário que eles precisam
do consentimento dos usuários para o uso dos seus
dados, isto é, qual a finalidade desse uso.

● Finalidade: empresas têm de justificar por que


precisam dos dados dos usuários. A transparência e
a responsabilidade devem ser fatores que explícitos
aos donos da informação. Cada fase tem que ser
entendida pelo usuário: a coleta, o armazenamento
e o compartilhamento de seus dados precisam estar
alinhados com a informação declarada.

● Necessidade: é preciso ficar claro o tempo de uso


dos dados e, quando não tiverem mais utilidade,
devem ser descartados de suas bases. Esse descar-
te de dados precisa ser justificado, pois se houver
exposição ou vazamento ilegal a empresa vai ser
penalizada. Isso garante que as informações sejam
justificadas quanto ao seu uso.

● Integridade: dados precisam ser verdadeiros; com


isso, a garantia de transparência das informações

48
precisa ser correta e autorizada para uso. Dados falsos
levam a fraudes, um cenário que deve ser evitado.

● Confidencialidade: controle e gerência dos dados


são fundamentais para que possam ser usados pelas
empresas.

● Disponibilidade: dados têm de permanecer em am-


biente seguro, ou seja, precisam estar disponíveis para
acesso a qualquer hora. Políticas de segurança como
backup, contingência e recuperação de informação
são premissas básicas para que os dados possam
ser usados e disponibilizados. O usuário deve ter a
liberdade para acessá-los a qualquer instante.

● Autenticidade: autenticidade desses dados tem


que ser garantida. É necessário que seja possível
validar a identificação do usuário com os dados
coletados.

● Dados sensíveis: são dados referentes a dados de


condição pessoal, por exemplo: a orientação sexual,
a saúde, proteção de fraudes, estudos ou pesquisas
cientificas, religião etc. A lei prevê a diferença entre
dados pessoais e dados sensíveis. Os pessoais são
dados de identificação, ao passo que os dados sen-
síveis estão sujeitos à análise tanto quanto ao que
se refere aos atos como discriminação pessoal.

● Abrangência: a lei serve para empresas, terceiros e


parceiros, todos devem ser enquadrados nos novos
parâmetros. A norma é válida tanto para empresas
nacionais quanto para as internacionais, que trami-
tem com dados de pessoas brasileiras.

49
● Comunicação: há uma mudança na comunicação
entre empresa e cliente. No que se refere à transpa-
rência, caso a empresa sofra algum crime virtual ou
ataque, ela deve comunicar ao usuário que cedeu os
dados a ela. A empresa tem que comunicar os órgãos
fiscalizadores, informando quais são as medidas
adotadas por parte da empresa.

REFLITA
O que você precisa saber sobre a lei de proteção
de dados?
A lei de proteção de dados visa a diminuir ou aca-
bar com os problemas de segurança. Devido aos
avanços da internet e da tecnologia, muitos da-
dos são manipulados sem o consentimento das
pessoas. A pertinência da lei mostra-se em casos
como o da Netshoes, empresa que vazou dados
pessoais de milhares de clientes e só informou as
vítimas semanas ou meses depois que o incidente
aconteceu. Entenda o caso acessando: https://
introduceti.com.br/blog/seguranca-os-maiores-
-vazamentos-de-dados-em-2018/
Após estudar e discutir esse caso da Netshoes,
você tem ideia o que as empresas fazem com to-
dos os dados que você coloca na internet? Reflita.

50
CONSIDERAÇÕES FINAIS

A Engenharia de Software tem um papel muito im-


portante no interior do desenvolvimento de software,
por regulamentar, propor que softwares sejam trata-
dos como projetos e que os resultados dos projetos
fossem mensurados e agregassem valor ao cliente.

Toda metodologia de Engenharia de Software é


pautada em processos. E o cliente passa de ator
coadjuvante a parceiro de desenvolvimento desses
softwares. Assim, muitas metodologias foram cria-
das e temos, atualmente, até uma certificação em
maturidade de desenvolvimento de software (CMMI),
bem como uma metodologia brasileira em qualidade
de software. A tecnologia evoluiu; com ela, a segu-
rança e a praticidade de desenvolvimento igualmente
evoluíram.

Com a Lei de Proteção de Dados, os softwares, alia-


dos aos conceitos de qualidade, têm mais essa evo-
lução pela frente. Portanto, a qualidade de software
tem um papel fundamental no desenvolvimento de
sistemas.

51
SÍNTESE

QUALIDADE DE
SOFTWARE
HISTÓRIA E FUNDAMENTOS
DA QUALIDADE DE SOFTWARE
Neste módulo, estudamos os conceitos de Engenharia de Software, Qualidade de Software,
Normas e Metodologias e Segurança de Software. Com isso, entendemos como chegamos
às metodologias que praticamos atualmente, bem como o quanto a Engenharia de Software
colaborou para isso.
Para isso, apresentamos e discutimos sobre os seguintes tópicos:

ENGENHARIA DE SOFTWARE – CULTURA E ÉTICA:

• Engenharia de Software.
• Principais conceitos de Engenharia de Software.
• Projetos em Engenharia de Software.
• Gerência/gestão de projetos.

MODELOS E CARACTERÍSTICAS DE QUALIDADE:

• O que é qualidade?
• Modelos e normas de qualidade.
• Aplicação da qualidade em softwares.

MELHORIA DA QUALIDADE DE SOFTWARE:

• Otimização nos processos de criação de software.


• O impacto da melhoria na entrega dos softwares.

SEGURANÇA DE SOFTWARE:

• Lei de Proteção de Dados e Qualidade de Software.


Referências Bibliográficas
& Consultadas
ABNT. ASSOCIAÇÃO BRASILEIRA DE NORMAS
TÉCNICAS. Disponível em: http://www.abnt.org.br.
Acesso em: 22 out. 2019.

BRAGA, P. H. C. (Org.) Testes de Software.


São Paulo: Pearson Education do Brasil, 2016
[Biblioteca Virtual].

CMMI INSTITUITE Disponível em https://cmmiinsti-


tute.com/. Acesso em: 22 out. 2019.

ETHOS. Disponível em www.ethos.org.br acesso


em 09/10/2019

GALLOTTI, G. M. A. (Org.). Qualidade de Software.


São Paulo: Pearson Education do Brasil, 2016
[Biblioteca Virtual].

GOTTERBARN, D. How the New Software


Engineering Code of Ethics Affects You. IEEE
Software Engineering, v. 16, n. 6, nov.-dez./1999. p.
58-64. DOI: 10.1109/52.805474.

GOTTERBARN, D.; MILLER, K. ROGERSON, S.


Computer society and ACM approve softwa-
re engineering code of ethics. Computer, v.
32, n. 10, out./1999. p. 84-88. DOI: 10.1109/
MC.1999.796142.

GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da


Informação: qualidade de produto de software.
Brasília: MCT/Sepin, 2009.

GUIA PMBOK. Um Guia do Conhecimento em


Gerenciamento de Projetos. 5. ed. São Paulo:
Project Management Institute (PMI)/Global
Standard, 2012.

PAULA FILHO, W. P. Engenharia de Software:


fundamentos, métodos e padrões. 3. ed. Rio de
Janeiro: LTC, 2009 [Minha Biblioteca].

PFLEEGER, S. L. Engenharia de Software: teoria


e prática. 2. ed. São Paulo: Prentice Hall, 2004
[Biblioteca Virtual].

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de


Software: uma abordagem profissional. 8. ed.
Porto Alegre: AMGH, 2016 [Minha Biblioteca].

SANTOS, R. Metodologias Ágeis para desenvol-


vimento de software. 2013. Disponível em: http://
www.blogti.microcampsp.com.br/metodologias-
-ageis-paradesenvolvimento-de-software-parte-i/.
Acesso em: 09 out. 2019
SCHACH, S. R. Engenharia de Software: os para-
digmas clássico e orientado a objetos. 7. ed. Porto
Alegre: AMGH, 2010 [Minha Biblioteca].

SOFTEX. ASSOCIAÇÃO PARA PROMOÇÃO


DA EXCELÊNCIA DO SOFTWARE BRASILEIRO.
Disponível em: http://softex.br/mpsbr/
modelos/#mpssw. Acesso em: 17 out. 2019.

SOLTANI, E.; LAI, P.; JAVADEEN, S.; GHOLIPOUR,


T. A review of theory and practice of managing
TQM: an integrative framework. Total Quality
Management & Business Excellence, v. 19, n. 5,
2008. p. 461-482.

SOMMERVILLE, I. Engenharia de software. 10.


ed. São Paulo: Pearson Education do Brasil, 2018
[Biblioteca Virtual].

WINDER, R. ROBERTS, G. Desenvolvendo Software


em Java. 3. ed. Rio de Janeiro: LTC, 2009 [Minha
Biblioteca].

Você também pode gostar