E1_ENSO

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE
Roque Maitino Neto
E-book 1
Neste E-Book:
INTRODUÇÃO ����������������������������������������������������������� 3
ENGENHARIA DE SOFTWARE ����������������������������� 5
Crise do Software e Produto de Software �������������������������������6
Conceito de Engenharia de Software ���������������������������������������7
Processos, fases e atividades ��������������������������������������������������9
Modelo em Cascata ����������������������������������������������������������������12
CONSIDERAÇÕES FINAIS �����������������������������������34
REFERÊNCIAS BIBLIOGRÁFICAS & 
CONSULTADAS �������������������������������������������������������36
2
INTRODUÇÃO
Para o bom entendimento da importância do que será 
abordado nesta disciplina de Engenharia de Software, 
convidamos você a uma reflexão: imagine um mundo 
em que não existem modelos de procedimentos, 
nem padrões a serem seguidos e não há sequer uma 
indicação de boas práticas para a construção de 
um artefato qualquer� Imagine também que esse 
“artefato qualquer” possui características únicas 
de construção e que há poucas pessoas no mundo 
capazes de criá-lo� Para dizer o mínimo, estaríamos 
diante de um cenário desafiador, você não acha?
Pois essa era exatamente a realidade que caracteri-
zava os primórdios do desenvolvimento de software 
e que justificou a criação de metodologias e mode-
los que, uma vez organizados e estruturados, deram 
início à área do conhecimento que hoje chamamos 
Engenharia de Software e que, direta ou indiretamen-
te, mudou os rumos da Computação. A importân-
cia e a abrangência desta disciplina vêm crescendo 
continuamente, mas não poderíamos abordar seus 
aspectos mais avançados sem antes conhecermos 
seus elementos fundamentais�
Por isso, nesta seção estudaremos os conceitos 
básicos da Engenharia de Software, os principais 
métodos de desenvolvimento de sistemas e as boas 
práticas que vêm norteando profissionais há vários 
anos. Ao final desta etapa, você será capaz de en-
tender as iniciativas mais importantes para a padro-
3
nização da construção deste produto tão importante 
em nosso cotidiano e que vem mudando a feição do 
mundo muito rapidamente: o software. Bom estudo 
e sigamos adiante!
4
ENGENHARIA DE 
SOFTWARE
Uma das providências mais eficientes a serem to-
madas quando desejamos compreender um assunto 
em nossa primeira experiência com ele é a de des-
vendar os termos que o identificam. A expressão 
“Engenharia de Software” é composta por dois ter-
mos que merecem ser entendidos separadamen-
te, mas que farão todo sentido quando colocados 
juntos� Conhecemos Engenharia como a ciência 
que, por meio da aplicação de recursos tecnológi-
cos, é capaz de criar coisas das quais precisamos� 
Brockman (2013) afirma que o objetivo principal da 
Engenharia é aplicar a tecnologia, em combinação 
com fenômenos naturais, para obter as coisas que 
desejamos ou de que necessitamos�
A definição do termo “Software” é encontrada em di-
versos formatos na literatura, mas nossa opção será 
por uma definição simples, dada por um expoente na 
área. De acordo com Sommerville (2018), um softwa-
re é um programa de computador e a documentação 
associada a ele� Com programas de computador é 
provável que você já tenha bastante familiaridade, 
mas uma das novidades a serem introduzidas por 
esta disciplina está relacionada à documentação 
relacionada ao software, incluindo a especificação 
de requisitos, o projeto e os casos de teste, entre 
outros documentos�
5
Se a Engenharia é um ramo da atividade humana 
bastante antigo e em desenvolvimento, a criação 
de software conta com apenas algumas décadas 
de idade. No entanto, fica claro que a iniciativa de 
juntar elementos da Engenharia para a criação de 
software tenha sido uma boa ideia em tempos em 
que não havia disciplina metodológica para a criação 
de produtos de software nem a garantia de que os 
projetos de desenvolvimento seriam bem-sucedidos� 
Essas considerações, aliás, nos levam a mais duas 
definições importantes no contexto.
Crise do Software e Produto de Software
A primeira definição está relacionada à mencionada 
“disciplina metodológica” ou, mais especificamente, 
à falta dela. Na década de 1960 – época que remete 
aos primeiros momentos do desenvolvimento de 
software –, alguns observadores criaram a expressão 
Crise do Software, a fim de explicitar o momento 
delicado que a atividade atravessava� Imaginamos 
uma crise como um momento em que a incerteza 
impera ou em que há a verificação de declínio de um 
determinado estado de coisas�
A Crise do Software, portanto, foi o período em que 
a atividade de criação de sistemas de computador 
mostrou-se incapaz de atender à crescente demanda 
por produção de software. Na falta de padrões e mo-
delos eficientes de desenvolvimento, as organizações 
acabavam entregando produtos cujo funcionamento 
não atendia às expectativas e que eram construídos 
6
por meio de processos falhos, quando eram adota-
dos. Como elemento final para esse cenário caótico, 
a imprecisão nas estimativas de prazo e de custo 
minava a confiança das equipes e, sobretudo, dos 
seus clientes�
Outro conceito que vale menção é o de Produto de 
Software. A palavra produto, usada na maioria dos 
contextos, nos remete a algo comercialmente viável 
e desenvolvido por meios profissionais. Embora exis-
ta a possibilidade de se criar software como hobby 
ou para gerenciar dados pessoais, a utilização da 
Engenharia de Software é especialmente recomenda-
da para construção de produtos de software voltados 
a fins comerciais. Conforme destaca Sommerville 
(2018), a Engenharia de Software se destina a apoiar 
o desenvolvimento de software profissional, ao in-
vés das iniciativas individuais� Em havendo sucesso 
nessa empreitada, o resultado será, portanto, um 
produto de software�
Conceito de Engenharia 
de Software
Se a Crise do Software revelou um cenário consi-
deravelmente adverso para o desenvolvimento de 
produtos de software de qualidade, ela também ins-
pirou iniciativas que tiveram como objetivo a rever-
são desse quadro e a consequente viabilização da 
atividade de criação de sistemas. A mais importante 
dessas iniciativas foi a padronização de processos 
7
e a criação de metodologias, ponto de partida para 
o nascimento da Engenharia de Software�
Foram termos com processo, métodos e qualida-
de que fundamentaram os conceitos de Engenharia 
de Software criados pelos mais importantes auto-
res da área. De acordo com Pressman e Maxim, 
a Engenharia de Software abrange um processo, 
um conjunto de métodos (práticas) e um leque de 
ferramentas que possibilitam aos profissionais 
desenvolverem softwares de altíssima qualidade� 
(PRESSMAN; MAXIM, 2016, p. 14)
De forma bastante simples e atento ao caráter pro-
cessual da Engenharia de Software, Sommerville 
(2018) a define como uma disciplina da Engenharia 
que se preocupa com os aspectos da produção de 
software, desde sua concepção inicial até sua ope-
ração e manutenção. O autor destaca ainda que as 
atividades fundamentais da Engenharia de Software 
incluem especificação, desenvolvimento, validação 
e evolução do software.
Não por acaso, essas atividades fundamentais estão 
refletidas e detalhadas nas metodologias criadas 
para produção de software e embasam, sobretudo, 
o método tradicional de desenvolvimento, do qual 
trataremos na sequência. Antes, porém, convém 
definirmos alguns termos que darão sentido à exis-
tência das metodologias e justificarão os esforços 
empreendidos em sua estruturação.
8
Processos, fases e atividades
Em sua essência, o desenvolvimento de um software 
deve ser enfrentado como um processo e não um 
apanhado de iniciativas isoladas� Um processo bem 
estruturado tende a prover previsibilidade no resulta-
do e racionalidade na aplicação dos recursos dispo-
níveis, fatos que aumentam a segurança no desen-
volvimento. No contexto da Engenharia de Software, 
um processo corresponde a passos ordenados que 
buscama entrega de um software como resultado, e 
que levam em consideração os recursos disponíveis, 
bem como as entradas e saídas esperadas�
FIQUE ATENTO
O processo de software é a maneira pela qual 
produzimos software� Ele abrange a metodologia 
– com seu modelo de ciclo de vida – e técnicas 
subjacentes, além das ferramentas utilizadas e, 
acima de tudo, os indivíduos que estão criando o 
software (SCHACH, 2009)
Outro termo bastante comum nesse contexto é pro-
jeto, que deve ser distinguido de processo. O PMBOK, 
conhecido como a principal publicação mundial em 
gerenciamento de projetos, conceitua projeto como 
um esforço temporário empreendido para criar um 
produto, serviço ou resultado único (PMI, 2017, p. 4). 
Um processo, por sua vez, refere-se à definição de 
como um projeto deve ser conduzido. Na visão de 
9
Wazlawick (2013), conduzir o desenvolvimento de 
um software como um processo reduz o tempo de 
adaptação da equipe aos procedimentos e contribui 
para a criação de produtos mais padronizados.
Para que se atinja um melhor domínio intelectual de 
um processo, ele foi dividido em fases� Uma fase 
agrupa atividades que guardam afinidades entre si 
e que possuem objetivos comuns a serem atingi-
dos. Nesse contexto, as atividades têm a finalidade 
de criar artefatos e caracterizam-se por possuírem 
entradas, saídas, recursos e atores bem definidos. 
Podemos considerar que um artefato seja um do-
cumento, a descrição de um fluxo ou um diagrama, 
entre outros elementos�
Em relação a um processo de software, há ainda 
que se destacar um aspecto importante e que o 
caracteriza: o fluxo dos processos. De acordo com 
Pressman e Maxim (2016), esse fluxo descreve como 
são organizadas as ações e tarefas que ocorrem no 
âmbito de cada atividade, em relação à sequência 
e ao tempo. Os processos podem seguir um fluxo 
paralelo, evolucionário, interativo e linear, ainda de 
acordo com os mencionados autores� Por ora, nos-
so interesse recai sobre o fluxo de processo linear, 
representado na figura 1.
10
Planejamento
Comunicação
Modelagem
Construção Entrega
Figura 1: Fluxo de processo linear. Fonte: Pressman e 
Maxim (2016, p. 33)
Como a própria ilustração e o nome sugerem, um fluxo 
de processo linear executa, em sequência, cada uma 
das cinco atividades tomadas como exemplo. Bem, se 
um processo se divide em fases e cada fase é cumpri-
da por meio da execução de tarefas sistematicamen-
te agrupadas, então estamos perto de uma solução 
capaz de transformar a construção de um software 
em uma atividade planejada, previsível e segura, não 
é mesmo? Infelizmente as experiências passadas 
não nos autorizam a responder com um “sim” a essa 
questão, embora a utilização de uma metodologia 
seja absolutamente indispensável nesse contexto.
A presunção de que o cumprimento de etapas dis-
postas linearmente e executadas por gente com es-
pecialização nas respectivas tarefas resultaria – em 
qualquer caso e sob quaisquer circunstâncias – em 
um produto de software de qualidade esteve entre as 
crenças mais comuns dos engenheiros de softwa-
re do século 20. Dessa lógica nasceu o Modelo em 
Cascata, principal método da sistemática tradicional 
de desenvolvimento de software e que será abordado 
na sequência�
11
Modelo em Cascata
Foi com base em uma linha de produção que o mo-
delo em cascata de desenvolvimento foi criado� 
Embora saibamos hoje que o meio utilizado para se 
criar um bem de consumo tradicional (um carro, por 
exemplo) não seja completamente adequado para a 
produção de um software, esse modelo predominou 
durante anos e ainda é base para procedimentos 
que as organizações de software utilizam. Rezende 
(2005) nos ensina que o ciclo de vida de um software 
inclui as seguintes fases: concepção, construção, 
implantação, implementações, maturidade, declínio, 
manutenção e descontinuidade. Essa divisão de fa-
ses baseia-se no Modelo em Cascata, que divide o 
processo de software conforme ilustrado na figura 2.
Comunicação
Planejamento
Modelagem
Construção
Entrega
Figura 2: Representação das fases do Modelo em Cascata. 
Fonte: adaptado de Pressman e Maxim (2016, p. 42)
A primeira fase, identificada como Comunicação, 
aborda o início do projeto e o levantamento de requi-
sitos. Depois, durante o Planejamento, são feitas as 
12
estimativas do projeto, o cronograma e o acompa-
nhamento desses artefatos. A Modelagem é a fase 
que inclui a elaboração da análise e do projeto do 
software. A fase de Construção, por sua vez, prevê 
a codificação do produto e a aplicação dos testes e, 
por fim, a Entrega inclui os procedimentos de entrega 
do produto, as atividades de suporte e os registros 
de feedback do cliente.
Antes de prosseguirmos, vale o registro de que os no-
mes das fases do Modelo em Cascata vêm sofrendo 
alterações e que, portanto, podem ser encontrados 
de forma diversa da aqui representada� É comum, em 
obras mais antigas, que as fases sejam identificadas 
como Requisitos, Projeto, Implementação, Teste e 
Manutenção. Nesse sentido, a definição dada para o 
Modelo em Cascata por Pressman e Maxim (2016) 
é a de que se trata de um procedimento que sugere 
uma abordagem sequencial para o desenvolvimento 
de software, começando com a especificação de re-
quisitos do cliente, avançando pelas fases de planeja-
mento, modelagem, construção e disponibilização, e 
culminando no suporte contínuo ao produto concluído�
A abordagem ao Modelo em Cascata estaria seria-
mente comprometida se não fosse oferecida expli-
cação para cada fase, por resumida que seja. Na 
sequência, trataremos das fases do modelo, consi-
derando as nomenclaturas tradicionais�
Requisitos: não por acaso, a abordagem dos requi-
sitos de um produto de software encontra-se na 
fase inaugural do modelo. Aqui são realizadas as 
13
atividades de elicitação (ou descoberta), análise, 
especificação e validação dos requisitos, entendidos 
genericamente como as condições necessárias para 
que o software cumpra seus objetivos� Em caráter 
mais específico, um requisito de software pode ser 
traduzido como suas características, suas funciona-
lidades, suas restrições e as demais condições para 
que ele se transforme em um produto perfeitamente 
adequado ao seu propósito�
O entendimento de que os requisitos levantados no 
início do processo permanecerão inalterados durante 
todo o ciclo de construção do software conduziu mui-
tos projetos ao fracasso� Os requisitos certamente 
mudarão com o tempo, seja em sua natureza, grau 
de importância ou prioridade de desenvolvimento, e 
o Engenheiro de Software deve estar preparado para 
essa realidade�
Outro aspecto a ser considerado nessa fase está 
relacionado à qualidade de execução das tarefas de 
requisitos. A criação de um projeto de software – eta-
pa posterior a esta – ficará seriamente comprometida 
se a abordagem dos requisitos for feita de maneira 
inadequada� Imagine que o cliente solicite à equipe 
de requisitos uma certa funcionalidade em seu sis-
tema e que, mediante a compreensão falha dessa 
funcionalidade, a equipe informe aos projetistas algo 
diferente daquilo desejado pelo cliente� Infelizmente 
essa situação é bastante comum e vem colocando 
projetos em risco há anos�
14
Via de regra, o artefato produzido na fase de requi-
sitos é um documento chamado Especificação de 
Requisitos de Software ou Software Requirements 
Specification (SRS). Idealmente, esse documento 
deve conter a descrição das funcionalidades e das 
restrições, além das necessidades de armazena-
mento, requisitos mínimos de hardware e tudo o que 
caracterizar o produto. Um modelo viável de SRS 
pode conter os seguintes tópicos, segundo Pressman 
e Maxim (2016, p. 136):
1. Introdução
 1�1� Finalidade
 1�2� Convenções do documento
 1.3. Público-alvo e sugestões de leitura
 1.4. Escopo do projeto
 1.5. Referências
2. Descrição geral
 2�1� Perspectiva do produto
 2�2� Características do produto
 2.3. Classes e características do usuário
 2.4. Ambiente operacional
 2.5. Restriçõesde projeto e de implementação
 2.6. Documentação para usuários
 2.7. Hipóteses e dependências
3. Características do sistema
4. Requisitos de interfaces externas
 4.1. Interfaces de usuário
 4.2. Interfaces de hardware
15
 4.3. Interfaces de software
 4.4. Interfaces de comunicação
5. Outros requisitos não funcionais
 5.1. Requisitos de desempenho
 5.2. Requisitos de segurança (privacidade)
 5.3. Requisitos de segurança (integridade)
 5.4. Atributos de qualidade de software
6. Outros requisitos
Fica claro que, quanto mais completo e detalhado 
for esse documento, menos dúvidas restarão para 
as fases seguintes do projeto. Antes de iniciarmos 
a descrição da próxima etapa, vale o registro de que, 
quando identifica uma etapa do Modelo em Cascata, 
o termo “Projeto” assume o significado de desenho, 
esboço ou esquema� 
Projeto: depois de eliciados (ou esclarecidos), clas-
sificados, documentados e validados os requisitos, 
o ciclo de produção se encaminha para o desenho 
do produto� É comum o entendimento de que os re-
quisitos refletem o que o sistema deverá executar, 
enquanto o projeto deverá refletir como as funções 
serão executadas. Um dos objetivos a serem alcan-
çados na etapa de projeto é a obtenção de uma ver-
são refinada dos requisitos, em uma representação 
mais apta a ser codificada. O caminho para essa 
versão refinada dos requisitos passa também pela 
decomposição do produto em módulos, entendidos 
16
como blocos de código que representam funções 
do software�
É por meio do projeto que os Engenheiros de Software 
têm a possibilidade de modelar o sistema a ser cons-
truído e, em consequência, realizar avaliações prévias 
sobre sua qualidade, antes mesmo de ser codificado. 
A etapa de projeto é tão rica que é possível que se 
gere várias representações do software� Conforme 
nos ensina Pressman e Maxim (2016), a arquitetura 
do sistema deve ser representada como peça ini-
cial do projeto. Depois, são modeladas as interfaces 
do sistema, cuja função é a de conectá-lo aos seus 
usuários e a outros sistemas� Por último, os compo-
nentes de software usados para construir o sistema 
são projetados.
Já Schach (2009) defende que a fase de Projeto 
clássica é composta por três atividades: projeto de 
arquitetura, projeto detalhado e testes do projeto� É 
durante o projeto de arquitetura que uma composição 
modular do produto é criada, representada por uma 
lista de módulos e uma descrição das conexões entre 
eles. Antes de prosseguirmos com um exemplo, vale 
registrar que a arquitetura de um software se refere 
à sua organização geral e aos modos pelos quais ele 
disponibiliza integridade conceitual para o sistema 
(PRESSMAN; MAXIM, 2016). A figura 3 ilustra um 
exemplo de parte da arquitetura de um sistema, com 
módulos dispostos hierarquicamente�
Já o projeto detalhado, também conhecido como 
projeto modular ou projeto físico, é o tipo de repre-
17
sentação em que o módulo é detalhado por meio 
de algoritmos e da escolha das respectivas estru-
turas de dados� Em outras palavras, cada módulo 
representado por um retângulo na figura 3 terá sua 
função descrita por meio de algoritmos, incluindo as 
variáveis e demais estruturas de dados que viabili-
zam sua existência. Tanto no projeto de arquitetura 
como no projeto detalhado, as interconexões entre 
os módulos não são contempladas.
ERP
Estoque e 
Custos
Movimentações
Fiscais
Movimentações
Internas
Saldo
Inicial
Saldo
Atual
Cadastros de
Produtos
Grupos de
Produtos
Cadastros de
Fornecedores
Saldos MovimentaçõesCadastros
Figura 3: Representação hierárquica de parte da arquitetura 
de um sistema� Fonte: Elaborado pelo autor
A terceira atividade, identificada como testes do pro-
jeto, efetiva-se com a aplicação de validações nas 
várias versões de um projeto, não necessariamente 
18
em sua versão final. Tais validações têm a função de 
evitar que erros nesta fase se propaguem para fases 
seguintes, comprometendo todo o desenvolvimento�
Antes de terminarmos a abordagem de projeto de 
software, vale desenvolvermos o que representa abs-
tração nesse contexto. Quando considerarmos o 
projeto como uma solução modular para o problema 
(ou seja, baseada em módulos do sistema), temos 
a possibilidade de descrever os módulos em vários 
níveis de abstração. Um módulo identificado como 
“Função de Desenho” certamente está em um nível 
de abstração bastante alto e essa sua identificação 
não é capaz, por exemplo, de transmitir detalhes pro-
cedimentais para aquele que deverá ter a missão de 
codificar o sistema.
Se considerarmos a necessidade de baixar o nível de 
abstração, algum detalhamento deveria ser forneci-
do, por exemplo, “a função de desenho do software 
gráfico deverá possibilitar ao usuário a construção 
de linhas retas e de curvas e os desenhos produzidos 
deverão ser gravados em uma pasta própria para 
desenhos”. Embora esse nível de abstração forneça 
elementos descritivos mais consistentes, ele ainda 
carece de uma representação mais próxima daquela 
regularmente entendida pelo responsável pela imple-
mentação, que é o próximo passo do processo. Por 
isso, a funcionalidade pode ser ainda mais detalhada 
e formatada de maneira mais apropriada:
19
inicio funcionalidade_desenho
  interacao_com_usuario,
  criacao_de_desenhos,
  exibicao_de_graficos,
  gerenciamento_arquivos_desenho,
fim funcionalidade_desenho.
A depender da política adotada por cada organização, 
a criação de níveis de abstração mais baixos pode 
ser necessária para composição do projeto, de modo 
que a função de cada módulo fique com alto nível de 
detalhamento e, em consequência disso, o trabalho 
do desenvolvedor seja facilitado�
Implementação: posicionada como etapa imediata-
mente seguinte à de projeto, a implementação tem 
como objetivo transformar os artefatos obtidos na 
etapa de projeto em código executável, por meio 
da utilização de uma linguagem de programação. 
Implementação, então, é o processo de converter 
o projeto detalhado em código (SCHACH, 2009). 
Considerada a complexidade dessa atividade, a co-
dificação é usualmente feita por equipes, com atu-
ações simultâneas em partes distintas do sistema� 
Como estratégia de implementação, uma equipe 
pode particionar as tarefas, de modo que cada de-
senvolvedor assuma um módulo do sistema�
Nos primórdios do desenvolvimento de software para 
fins comerciais, escolher uma linguagem de progra-
mação para a codificação do sistema não era a mais 
difíceis das tarefas. Afinal, a variedade de linguagens 
20
era reduzida e a escolha recairia inevitavelmente sobre 
aquela que apresentasse facilidades para desenvol-
vimentos específicos. Assim, um sistema com incli-
nação científica usaria uma certa linguagem; um pro-
grama de controle empresarial usaria outra linguagem 
e assim por diante� Um erro nessa escolha poderia 
comprometer seriamente o projeto�
Em nossos dias, no entanto, o cenário é bem dife-
rente� Com os recursos atuais, as escolhas das lin-
guagens passam por outros critérios, considerando 
que, tecnicamente, a maioria irá suprir amplamente 
as necessidades dos desenvolvedores� Salvo pela 
existência de detalhes muito específicos relaciona-
dos a plataformas, tanto o Java quanto as linguagens 
oferecidas pelo .NET, por exemplo, estarão aptas a 
dar vida à grande maioria dos projetos�
Podemos considerar, então, que critérios mais sub-
jetivos possam ser aplicados na escolha de uma 
plataforma de desenvolvimento (incluída aqui a lin-
guagem de programação). Um desses critérios é a 
familiaridade da equipe com os recursos de desen-
volvimento disponíveis no mercado� Imaginemos o 
seguinte cenário: ao propor o sistema, o cliente não 
fez qualquer restrição à linguagem de programa-
ção que deveria ser utilizada, deixando essa escolha 
sob responsabilidade dos desenvolvedores. Em não 
havendo restrição técnica, é certo que as equipes 
escolherão a plataforma de desenvolvimento com 
a qual tenham mais afinidade.
21
A familiaridade com a linguagem de programaçãopor parte dos desenvolvedores pode ser, inclusive, 
vinculada ao seu grau de popularidade entre desen-
volvedores pelo mundo. Eastwood (2020) oferece 
as dez linguagens mais populares, mais a principal 
característica de cada uma delas� O quadro 1 sinte-
tiza os dados das cinco primeiras, com o objetivo de 
ajudá-lo a formar base para suas escolhas�
Posição Linguagem 
de 
Programação
Principal característica
1 Phyton
Python é considerada uma linguagem de 
programação fácil de aprender, devido 
à sua sintaxe simples. Ela conta com 
vasta biblioteca de padrões e facilidade 
de integração com outras linguagens de 
programação populares, como C e C ++
2 JavaScript
JavaScript é a linguagem de programa-
ção mais popular para construir sites 
interativos. Quando combinado com o 
Node�js, os programadores podem usar 
JavaScript para produzir conteúdo da 
web no servidor antes que uma página 
seja enviada ao navegador, que pode ser 
usado para criar jogos e aplicativos de 
comunicação que são executados direta-
mente no navegador�
3 Java
Java é a linguagem de programação mais 
comumente associada ao desenvolvi-
mento de aplicativos cliente-servidor, 
usados por grandes empresas em todo o 
mundo� O Java foi projetado para ser uma 
linguagem de programação fracamente 
acoplada, o que significa que um aplica-
tivo escrito em Java pode ser executado 
em qualquer plataforma que suporte 
Java� Como resultado, o Java é descri-
to como a linguagem de programação 
“escreva uma vez, execute em qualquer 
lugar”�
22
4 C##
A Microsoft desenvolveu o C# (lê-se C 
Sharp) como uma variante mais rápida e 
segura da linguagem C� Ele é totalmente 
integrado com a plataforma de software 
.NET da Microsoft, que oferece supor-
te ao desenvolvimento de aplicativos 
para Windows, plug-ins de navegador e 
dispositivos móveis� O C# oferece bases 
de código compartilhadas, uma grande 
biblioteca de código e boa variedade de 
tipos de dados�
5 C
Junto com Python e Java, a linguagem 
C constitui uma boa base para aprender 
a programar� Como uma das primeiras 
linguagens de programação já desenvol-
vidas, o C serviu como base para escrever 
linguagens mais modernas, como Python, 
Ruby e PHP. Também é uma linguagem 
fácil de depurar, testar e manter�
Tabela 1: As cinco linguagens de programação mais popu-
lares� Fonte: adaptado de Eastwood (2020)
Outro elemento importante da etapa de implementa-
ção está relacionado às boas práticas que devem ser 
aplicadas durante seu curso, independentemente da 
linguagem utilizada. De acordo com Schach (2009), 
a primeira recomendação trata do uso de nomes de 
variáveis significativos e padronizados. O desenvol-
vedor deve considerar que seus pares um dia deverão 
aplicar manutenção no módulo ou trecho que ele 
desenvolveu e que identificadores coerentes com 
suas funcionalidades facilitarão o trabalho alheio.
A segunda recomendação, ainda na visão de Schach 
(2009), diz respeito à documentação do sistema. O 
entendimento sobre as funções e a quantidade de 
documentação necessária no código vem mudando 
23
nos últimos anos, mas a importância desse recur-
so ainda permanece inalterada, pois se aplica aqui 
também a lógica da necessidade de manutenção no 
código. Com a intenção de padronizar a documenta-
ção voltada ao código, a Sun Microsystems criou o 
Javadoc, um gerador de documentação de classes 
e demais elementos do Java�
SAIBA MAIS
Um vídeo bastante interessante sobre a utili-
dade do Javadoc, chamado O que é JavaDoc e 
para que serve, do professor Jean Vargas, pode 
ser acessado em https://www.youtube.com/
watch?v=QCOiKGyd0p8�
A última recomendação está relacionada à disposi-
ção de escrita do código e foi colocada pelo autor em 
um contexto chamado layout do código para maior 
legibilidade. Segundo ele, a endentação talvez seja 
a técnica mais importante para melhorar a legibili-
dade do código. Apenas para registro, o sinônimo 
do termo “endentar” é encaixar. Outro recurso bem 
útil na facilitação da leitura do código é a utilização 
de linhas em branco, usadas principalmente para 
subdividir blocos de código�
Passamos agora para a abordagem da próxima etapa, 
que compreende as atividades de teste do software�
Testes: Em sua definição mais difundida, testar signi-
fica executar um programa com o objetivo de revelar 
24
a presença de defeitos ou para aumentar a confiança 
nesse programa, caso o objetivo principal não possa 
ser cumprido� Idealmente, a etapa de teste deveria 
ser aplicada de forma diluída por todas as outras, a 
fim de validar os artefatos produzidos pelo ciclo de 
vida até aqui� No entanto, nossa abordagem estará 
restrita ao teste aplicado no código de um progra-
ma já pronto ou, nos casos que destacaremos, em 
unidades desse programa�
Por serem constituídos por várias fases, os testes 
são desenvolvidos em uma sequência de ações e tal 
sequência é executada com o objetivo de encontrar 
problemas no software, o que aumenta a percepção 
de qualidade geral do software, garantindo que o 
usuário final tenha um produto que atenda às suas 
necessidades (PINHEIRO, 2015). O objetivo de um 
teste, portanto, é o de encontrar inconsistências no 
produto ou em uma parte dele. Antes de tratarmos 
especificamente do processo de teste, será neces-
sário abordarmos alguns elementos dos testes, co-
meçando por alguns dos seus tipos�
Teste de unidade: o primeiro tipo a ser desenvolvi-
do é o teste de unidade� Para entendê-lo, devemos 
imaginar o programa como um conjunto de partes, 
que formam o produto completo quando integradas� 
Assim, o teste de unidade é aquele aplicado em uma 
classe, funcionalidade ou módulo, com a finalidade 
de encontrar e eliminar defeitos naquele contexto. 
De acordo com Pressman e Maxim (2016), o teste de 
unidade concentra a verificação na menor unidade 
do projeto de software�
25
Para a realização dos testes de unidade, o testador 
implementa um trecho de código que substituirá as 
entradas necessárias para o funcionamento da uni-
dade em teste� Este trecho de código é conhecido 
como stub e, segundo Pinheiro (2015), ele simula 
resultados que são retornados por um determinado 
componente do qual o software depende�
Teste de integração: trata-se de um tipo de teste 
executado para garantir que vários componentes do 
sistema funcionam corretamente juntos. Eles são 
executados quando as unidades já tiverem passado 
pelos testes de forma isolada e precisam ser integra-
das para gerar uma nova versão do software.
Caso os componentes (módulos ou classes, por 
exemplo) que estão sendo testados ainda precisem 
de comunicação com outros componentes ou clas-
ses que ainda não foram implementadas, novamente 
os stubs serão necessários. O problema com um 
stub é que se investe tempo para desenvolver uma 
função que não será efetivamente entregue. Além 
disso, nem sempre é possível saber se a simulação 
produzida pelo stub será suficientemente adequada 
para os testes (WAZLAWICK, 2013).
Teste de sistema: mesmo depois de testada cada 
unidade isoladamente, e a comunicação entre as 
unidades, é necessário ainda testar o funcionamento 
do sistema de modo global, adotando o ponto de 
vista de quem usará o sistema� O objetivo do teste 
de sistema é o de apurar se o programa é capaz de 
26
executar processos completos, como se estivesse 
em uso pleno�
Teste de usuário: aplicado o teste de sistema, o 
produto final deve ser aceito pelo usuário. Como o 
nome sugere, esse teste é executado pelo usuário e 
não pela equipe de testadores ou desenvolvedores. 
Em relação ao planejamento e à execução, o teste 
de usuário se equipara ao teste de sistema, com a 
diferença de que ele será executado pelo usuário. Se 
considerarmos que o teste de sistema ainda é parte 
da verificação do produto, o teste de aceitação serve 
para sua validação.
Na visão de Pressman e Maxim (2016), esses tipos 
de testes fazem parte da estratégia de testes ado-
tada pela equipe� De forma interessante, os autores 
relacionam os testes com etapas do ciclo de vida dosoftware, conforme ilustrado na figura 4.
27
Teste de sistema
Teste de validação
Teste d
e integração
Teste de
unidade
Código
Requisitos
Engenharia
de sistemas
Projeto
Figura 4: Estratégia de teste� Fonte: Pressman e Maxim 
(2016, p. 470)
O teste de unidade começa no centro da espiral e 
relaciona-se com as unidades construídas no código-
-fonte. Em seu caminho rumo ao exterior da espiral, 
o processo segue para o teste de integração, que se 
concentra no projeto e na arquitetura do software� 
Em seguida, vem o teste de validação, que baseia 
seus processos nos requisitos do sistema. Por fim, 
chega-se ao teste de sistema, no qual o software e 
todos os seus elementos são testados globalmente.
Outro elemento importante no domínio dos tes-
tes e que vale nossa atenção é o caso de teste� 
Conceitualmente, um caso de teste é o par formado 
por uma entrada no programa e a correspondente 
saída esperada, planejada de acordo com os requi-
sitos do sistema� Um dado de entrada corresponde 
a uma condição necessária para uma execução do 
28
programa. A saída esperada é o resultado de uma 
execução do programa ou unidade determinada.
Como exemplo de casos de teste, vamos assumir que 
um programa que realiza a validação de datas inseri-
das pelo usuário esteja sendo testado� Poderíamos 
ter (01/01/2023; “data válida”) como um par viável 
para caso de teste e, ao receber a data 01/01/2023 
como entrada, o programa de validação de data de-
veria retornar “data válida”. A utilização de um bom 
conjunto de casos de teste será fundamental para 
o sucesso da atividade e, nesse sentido, o testador 
não poderia imaginar um conjunto que contivesse 
apenas datas válidas como entradas�
Com base na disponibilidade do código-fonte ao tes-
tador, na disponibilidade de ferramentas de teste e 
na natureza do sistema a ser testado, será possível à 
equipe adotar determinada técnica de teste� Embora 
existam em maior número, trataremos aqui das duas 
principais técnicas: a funcional e a estrutural.
Teste Funcional: tida como a mais simples e mais 
fácil de ser aplicada, essa técnica baseia-se nas 
especificações do software para derivar os requi-
sitos de teste� O teste é realizado diretamente nas 
funções do programa, o que lhe rendeu o nome de 
teste funcional. Não é seu objetivo verificar como 
ocorrem internamente os processamentos, mas se 
o algoritmo inserido produz os resultados esperados 
(BARTIÉ, 2002). Por se basear nas funcionalidades, 
essa técnica não obriga o conhecimento de detalhes 
29
da implementação do programa nem o código-fonte 
é necessário para que ela se efetive�
Embora seja de aplicação simples (conforme já 
mencionado), essa técnica apresenta uma desvan-
tagem, representada pela incerteza de que todas as 
partes essenciais do programa foram executadas 
ao se executar suas funções, mesmo com um bom 
conjunto de casos de teste. Uma representação da 
técnica funcional é dada pela figura 5. Nela é pos-
sível observar que os casos de teste são inseridos 
no teste e os resultados são apurados, sem que a 
estrutura interna do programa seja conhecida� Desse 
fato nasceu o outro nome desta técnica, conhecida 
também como “caixa preta”.
ResultadosCasosde teste
Figura 5: Visão de teste de caixa preta. Fonte: Bartié (2002, 
p. 105)
Teste Estrutural: os testes estruturais (ou de caixa bran-
ca) baseiam-se na arquitetura interna do programa. 
Com o código-fonte, o testador submete o programa 
a uma ferramenta automatizada de teste, que permite 
a observação dos trechos do programa executados 
pelos casos de teste. Apesar de ser mais eficiente em 
encontrar defeitos na maioria dos casos, sua aplicação 
é mais complexa e requer mais recursos.
30
Feitas essas considerações, fechamos a abordagem 
da etapa de testes com a menção às suas etapas. 
Embora possa variar entre metodologias, o processo 
de teste é usualmente dividido em quatro etapas:
1. Planejamento: nessa etapa, algumas decisões 
devem ser tomadas como meio de fundamentar o 
restante do processo de teste. Deve ser definido, por 
exemplo, quem executa os testes, qual o período 
disponível para isso, com quais recursos os testes 
serão feitos e quais as técnicas a serem utilizadas. 
Em relação aos responsáveis pela execução dos tes-
tes, vale um registro: embora os desenvolvedores do 
programa sejam as pessoas que, na teoria, melhor 
o conhecem, eles terão interesse em provar que o 
produto que desenvolveram é livre de erros, o que 
pode comprometer o procedimento� 
2. Projeto de casos de teste: nessa etapa devem ser 
definidos os casos de teste que serão utilizados nos 
testes� Nunca é demais repetir que, quanto melhor os 
casos de teste, mais chances o procedimento terá 
de revelar defeitos no código�
3. Execução do teste: nessa etapa, aplica-se o teste 
definido na fase de planejamento, com os casos de 
teste definidos na etapa anterior a esta.
4. Análise dos resultados: nessa etapa final verifica-
-se se os testes retornaram resultados satisfatórios 
ou se precisam ser refeitos, com outros casos de 
teste ou outra técnica�
31
Manutenção: Depois de trilhar todo o caminho que 
começou no planejamento e terminou com a sua 
entrega, esperamos que nosso produto de software 
esteja apto a ser utilizado sem contratempos pelo 
cliente. Afinal, sabemos que ele foi construído com 
base em uma metodologia bem estruturada e que 
acabou de passar por testes e correções feitas an-
tes da entrega. Além disso, os desenvolvedores que 
trabalharam nesse projeto são tidos como tecnica-
mente muito bons e seus programas são sempre 
de alta qualidade� Considerando esse cenário, nem 
seria o caso de nos preocuparmos com a etapa de 
manutenção, não é mesmo? A resposta, em todas 
as circunstâncias, será não.
Embora os requisitos do usuário estejam expressos 
no programa através de suas funcionalidades, é natu-
ral que esse programa sofra alterações e passe por 
evolução, já que os requisitos podem ser modificados 
depois da entrega. Além disso, quando colocado em 
operação diária, é comum que o programa manifeste 
erros não detectados pela equipe de teste, o que de-
verá implicar em retrabalho para os desenvolvedores� 
A manutenção é, portanto, parte importante do ciclo 
de vida do software e deve receber a mesma atenção 
e contar com os mesmos recursos oferecidos nas 
outras fases�
A manutenção de software é definida como o tra-
balho aplicado em modificações em um produto de 
software após sua entrega ao cliente, com o propó-
sito de corrigir inconsistências, aprimorar seu de-
sempenho e/ou adaptar o produto a um ambiente 
32
diferente daquele para qual ele foi concebido. Não 
podemos, portanto, relacionar manutenção apenas 
a correções no programa� Ela representa, inclusive, 
a oportunidade de fazer o produto evoluir, sem que 
suas principais características sejam afetadas� Uma 
boa manutenção terá impacto positivo na utilidade do 
produto e, em consequência, na satisfação do cliente.
Não por acaso, “manutenção de software” vem dan-
do lugar a “evolução de software”, expressão mais 
adequada se considerarmos que as atividades de 
modificação de um produto operacional não visam 
a mantê-lo em seu estágio atual, mas fazê-lo evoluir 
de forma a adaptar-se a novos requisitos ou ainda 
corrigir defeitos (WAZLAWICK, 2013). Apesar da sua 
importância no contexto, a evolução do software 
sempre demandará esforços e investimento finan-
ceiro e de mão de obra, e essa realidade deverá ser 
levada ao cliente antes de a evolução ser efetivada.
33
CONSIDERAÇÕES FINAIS
Esse foi o conteúdo que queríamos compartilhar 
e, por meio dele, esperamos ter transmitido a você 
a importância da familiaridade com os elementos 
básicos da Engenharia de Software. Abrimos este 
capítulo tratando do fenômeno conhecido como Crise 
do Software justamente para estabelecermos o que 
não desejamos mais em nossos processos de de-
senvolvimento e para entendermos quais problemas 
a aplicação desta disciplina deve endereçar.
Depois de conceituarmos Engenhariade Software, 
buscamos entender como ela se utiliza do conceito 
de processos para estruturar suas metodologias e, 
dessa forma, oferecer aos profissionais do desen-
volvimento um meio seguro e – em certa medida 
– previsível para construir seus produtos. Na se-
quência, tratamos de todo o ciclo de vida clássico 
(ou Modelo em Cascata), detalhando suas etapas e 
contextualizando-as como passos necessários para 
a obtenção de um produto de qualidade. Apesar de 
seus conceitos e práticas estarem passando por 
atualizações, sabemos que o Modelo em Cascata 
serve como fundamento processual para a maioria 
das metodologias mais modernas�
Mas, será que a Engenharia de Software se faz ape-
nas com os elementos que estudamos aqui? Será que 
apenas as metodologias tradicionais são capazes de 
atender nossa demanda por desenvolvimentos ágeis 
e de elevada qualidade? Ao contrário do que essas 
34
questões podem nos fazer supor, a Engenharia de 
Software tem muito mais a oferecer à comunidade de 
desenvolvedores e a pessoas ligadas à Computação, 
e sua constante evolução tem contribuído para que 
sua relevância cresça sempre�
35
Referências Bibliográficas 
& Consultadas
BARTIÉ, A. Garantia da qualidade de software: as 
melhores práticas de engenharia de software apli-
cadas à sua empresa. Rio de Janeiro: Elsevier, 2002.
BROCKMAN, J. B. Introdução à engenharia: modelagem 
e solução de problemas. Rio de Janeiro: LTC, 2013.
COHN, M. Desenvolvimento de software com scrum: 
aplicando métodos ágeis com sucesso. Porto Alegre: 
Bookman, 2011. [Minha Biblioteca]
EASTWOOD, B. The 10 most popular programming 
languages to learn in 2020. Disponível em: https://
www.northeastern.edu/graduate/blog/most-popular-
-programming-languages. Acesso em: 21 out. 2020.
PAULA FILHO, W. P. Engenharia de software: funda-
mentos, 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]
PINHEIRO, Á. F. Fundamentos de engenharia de 
software: qualidade com testes e gerência. 1. ed. 
Volume VI. Recife: Publicação independente, 2015. 
PMI� Guia PMBOK: um guia de conhecimento em 
gerenciamento de projetos. 6. ed. Pensilvânia: Project 
Management Institute, 2017.
PRESSMAN, R.; MAXIM, B. Engenharia de software: 
uma abordagem profissional. 8. ed. Porto Alegre: 
AMGH, 2016. [Minha Biblioteca]
REZENDE, D. A. Engenharia de software e sistemas 
de informação. 3. ed. Rio de Janeiro: Brasport, 2005.
SBROCCO, J. H. T. C.; MACEDO, P. C. Metodologias 
ágeis: engenharia de software sob medida. São 
Paulo: Érica, 2012. [Minha Biblioteca]
SCHACH, S. R. Engenharia de Software: os paradig-
mas clássico e orientados a objetos� 7� ed� Porto 
Alegre: AMGH, 2009.
SOMMERVILLE, I. Engenharia de software. 10. 
ed. São Paulo: Pearson Education do Brasil, 2018. 
[Biblioteca Virtual]
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requi-
sitos: software orientado ao negócio. Rio de Janeiro: 
Brasport, 2016. [Biblioteca Virtual]
WAZLAWICK, R. S. Engenharia de software: conceitos 
e práticas. Rio de Janeiro: Elsevier, 2013.
	Introdução
	Engenharia de Software
	Crise do Software e Produto de Software
	Conceito de Engenharia de Software
	Processos, fases e atividades
	Modelo em Cascata
	Considerações finais
	Referências Bibliográficas & Consultadas