E-book 3 - Paradígmas de Linguagens de Programação

Prévia do material em texto

PARADIGMAS DE 
LINGUAGENS DE 
PROGRAMAÇÃO
E-book 3
Bruno Zolotareff dos Santos
Neste E-Book:
INTRODUÇÃO ����������������������������������������������4
ENGENHARIA DE SOFTWARE 
DISTRIBUÍDO ����������������������������������������������� 5
REMOTE METHOD INVOCATION ����������10
SERVIDOR WEB �����������������������������������������13
ENTENDENDO A ARQUITETURA DO 
TOMCAT ��������������������������������������������������������15
ENGENHARIA DE SOFTWARE 
ORIENTADO A SERVIÇOS �����������������������17
WEB SERVICES ������������������������������������������18
ENGENHARIA DE SOFTWARE: 
DESENVOLVIMENTO 
PROFISSIONAL E ÉTICA ������������������������� 22
PROFISSIONAL DE ENGENHARIA 
DE SOFTWARE ������������������������������������������ 25
PRINCIPAIS ÁREAS DA 
ENGENHARIA DE SOFTWARE: 
GERENCIAMENTO DE 
CONFIGURAÇÃO DE SOFTWARE ��������28
FERRAMENTAS E MÉTODOS ����������������29
Projeto e desenho (Design): ��������������������������������� 30
2
QUALIDADE DE SOFTWARE ������������������31
TESTE DE SOFTWARE ���������������������������� 33
NORMAS ISO COM FOCO NA 
QUALIDADE DE SOFTWARE ����������������� 35
NBR ISO/IEC 9126-1 QUALIDADE DO 
PRODUTO DE SOFTWARE ���������������������37
NBR ISO/IEC 15504 PROCESSOS 
DE SOFTWARE EM NÍVEIS DE 
MATURIDADE - QUALIDADE �����������������41
ÉTICA NA ENGENHARIA DE 
SOFTWARE �������������������������������������������������46
NBR/ISO 20000 GESTÃO 
DE SERVIÇOS NA ÁREA DE 
TECNOLOGIA DA INFORMAÇÃO ���������49
METODOLOGIAS TRADICIONAIS DE 
DESENVOLVIMENTO DE SOFTWARE �51
MODELO CASCATA ���������������������������������� 52
MODELO INCREMENTAL ������������������������54
METODOLOGIA EM PROTOTIPAÇÃO �55
RAPID APPLICATION 
DEVELOPMENT �����������������������������������������57
MODELO ESPIRAL ������������������������������������59
CONSIDERAÇÕES FINAIS ����������������������61
SÍNTESE �������������������������������������������������������62
3
INTRODUÇÃO
Os sistemas distribuídos são utilizados praticamente 
em todos os lugares, de aparelhos celulares a televi-
sores� Utilizam a arquitetura cliente-servidor, em que 
se fornece o serviço em uma rede de computadores, 
em geral via web�
Neste módulo, entenderemos os princípios do uso 
dos sistemas distribuídos, assim como estabelece-
remos uma breve relação da profissão do engenhei-
ro de software e a ética envolvida na função� Além 
disso, estudaremos como a engenharia de softwa-
re está ligada ao processo de desenvolvimento e 
conheceremos alguns dos modelos utilizados no 
desenvolvimento�
4
ENGENHARIA DE 
SOFTWARE DISTRIBUÍDO
Quando ouvimos falar de sistemas distribuídos, 
muitos não imaginam o conceito por trás desse 
nome ou quanto de engenharia há nessa arqui-
tetura� Para se ter um breve entendimento sobre 
o assunto, a definição mais simples seria: é um 
software que não funciona apenas em uma máqui-
na local, o sistema funciona em uma arquitetura 
cliente-servidor�
Por arquitetura cliente-servidor, entende-se que 
um computador que possui um software instalado 
pode disponibilizar acesso aos seus recursos em 
uma rede de computadores, contendo um ou mais 
dispositivos�
Bem, se você pensou em uma disciplina que en-
volva redes de computadores, acertou� A comu-
nicação dos sistemas distribuídos funciona em 
uma rede de computadores que trocam informa-
ções utilizando diversos protocolos da Web� Para 
aqueles que estão acostumados com sistemas 
desenvolvidos para desktop, tanto o acesso ao 
servidor quanto a disponibilidade dos serviços são 
feitos por recursos conhecidos como sockets, isso 
mesmo, você pode utilizar socket server ou socket 
cliente�
Segundo a Oracle, a definição de socket é um ponto 
de comunicação entre duas máquinas� Portanto, 
para que ocorra essa comunicação, há um servidor 
e um cliente, processo que acontece através de 
uma conexão realizada pelo socket�
5
O socket não pertence à tecnologia da Oracle, que 
é o Java� Muita calma nesta hora, pois a progra-
mação por sockets pode ser feita por qualquer 
linguagem que suporta esse tipo de arquitetura, 
tais quais C/C++, C#, Java, Visual Basic e Python�
Embora seja um tipo de programação complexo, 
não é o único meio de fazer esse tipo de comu-
nicação, assim, há outros meios, como utilizar o 
Remote Method Invocation (RMI)� Para uma sim-
ples aplicação, entretanto, o uso de socket pode 
ser mais indicado por ser simples�
Na Tabela 1, para efeito de estudo, temos duas 
classes em Java utilizando socket server e socket 
cliente� Observe que, no código a seguir, se con-
figura a porta em que se espera a comunicação 
classe server (Tabela 1) e classe cliente (Tabela 2):
6
Socket Server em Java
public class SocketServerExample {
 
 private static ServerSocket server;
 //socket server port em que vai ouvir
 private static int port = 9876;
 
 public static void main(String args[]) throws IOException, 
ClassNotFoundException{
 // criar o objeto do servidor de soquete
 server = new ServerSocket(port);
 
 while(true){
 System�out�println("Waiting for the client request");
 // criando soquete e aguardando conexão do cliente
 Socket socket = server�accept();
 // leia a partir do soquete para ObjectInputStream object
 ObjectInputStream ois = new ObjectInputStream(socket�
getInputStream());
 //converte ObjectInputStream object to String
 String message = (String) ois�readObject();
 System�out�println("Message Received: " + message);
 //cria objeto ObjectOutputStream 
 ObjectOutputStream oos = new ObjectOutputStream(socket�
getOutputStream());
 // escrever objeto no soquete
 oos�writeObject("Hi Client "+message);
 // fechar recursos 
 ois�close();
 oos�close();
 socket�close();
 // encerrar o servidor se o cliente enviar uma solicitação de saída
 if(message�equalsIgnoreCase("exit")) break;
 }
 System�out�println("Desligando Socket server!!");
 //fecha o objeto ServerSocket 
 server�close();
 } }
Tabela 1: Socket server em Java. Fonte: Elaborada pelo autor (2019).
Na Tabela 2, pode-se observar o código que busca-
rá o endereço onde está a classe servidora:
7
Socket Client em Java
public class SocketServerExample {
 private static ServerSocket server;
 //socket server port em que vai ouvir
 private static int port = 9876;
 public static void main(String args[]) throws IOException, 
ClassNotFoundException{
 // criar o objeto do servidor de soquete
 server = new ServerSocket(port);
 while(true){
 System�out�println("Waiting for the client request");
 // criando soquete e aguardando conexão do cliente
 Socket socket = server�accept();
 // leia a partir do soquete para ObjectInputStream object
 ObjectInputStream ois = new ObjectInputStream(socket�
getInputStream());
 //converte ObjectInputStream object to String
 String message = (String) ois�readObject();
 System�out�println("Message Received: " + message);
 //cria objeto ObjectOutputStream 
 ObjectOutputStream oos = new ObjectOutputStream(socket�
getOutputStream());
 // escrever objeto no soquete
 oos�writeObject("Hi Client "+message);
 // fechar recursos 
 ois�close();
 oos�close();
 socket�close();
 // encerrar o servidor se o cliente enviar uma solicitação de saída
 if(message�equalsIgnoreCase("exit")) break;
 }
 System�out�println("Desligando Socket server!!");
 //fecha o objeto ServerSocket 
 server�close();
 } }
Tabela 2: Socket client em Java. Fonte: Elaborada pelo autor (2019).
8
Em ambas classes de sockets, temos um exemplo de 
comunicação entre a classe server e a classe cliente� 
A classe cliente disponibiliza um canal paracomu-
nicação com uma porta definida; a classe cliente 
busca o número da porta para acontecer a ligação 
das classes�
Esse foi um simples exemplo� Caso queira se apro-
fundar em sockets, isso será ótimo para a sua for-
mação, pois quanto mais conhecimento e prática 
tiver melhor será sua experiência com programação 
distribuída� Para isso, você pode consultar e estudar 
as especificações, os exemplos e as explicações com 
mais detalhes no site da Oracle ou da Microsoft� O 
importante é conhecer esse tipo de arquitetura�
SAIBA MAIS
Saiba mais sobre a comunicação de sockets por 
meio dos seguintes endereços:
Java Sockets: https://docs.oracle.com/javase/tutorial/
networking/sockets/. 
C#: https://docs.microsoft.com/pt-br/dotnet/api/system.net.so-
ckets.socket?view=netframework-4.8/. 
9
https://docs.oracle.com/javase/tutorial/networking/sockets/
https://docs.oracle.com/javase/tutorial/networking/sockets/
https://docs.microsoft.com/pt-br/dotnet/api/system.net.sockets.socket?view=netframework-4.8/
https://docs.microsoft.com/pt-br/dotnet/api/system.net.sockets.socket?view=netframework-4.8/
REMOTE METHOD 
INVOCATION
O Remote Method Invocation (RMI) é uma tecnolo-
gia suportada pelo Java e utilizada em aplicações 
distribuídas, que normalmente apresentam muitas 
falhas pelo fato de se envolverem plataformas di-
ferentes, como Unix, Linux e Windows� O RMI evita 
muito desses problemas comparados com outras 
soluções, como a que estudamos de sockets�
A arquitetura de RMI possui um conjunto de inter-
faces de uso comum na programação orientada a 
objetos� O RMI permite que o cliente adquira uma 
interface em Java, para que todo o processo ocorra 
em um Java Virtual Machine (JVM), assegurando a 
comunicação recorrente de protocolos como TCP/
IP (SARMENTO, 2003)�
O RMI utiliza a arquitetura cliente-servidor que, em 
seu processo de alto nível, disponibiliza as interfaces 
em Java, evitando com isso a maioria dos problemas 
de compatibilidade de plataformas por funcionar tudo 
na JVM. Pode-se verificar o processo na Figura 1:
10
Cliente Servidor
INTERFACE
Proxy
INTERFACE
Impl.
RMI
JVM 1 JVM 2
RMI
Figura 1: Remote Method Invocation. Fonte: Sarmento (2003).
Para entender melhor, vamos verificar as três cama-
das do RMI que o programador deve conhecer, as 
quais são correspondentes ao processo de comu-
nicação utilizando TCP/IP:
 ● Camada Stubs e Skeleton: utilizados na aplicação 
do cliente, os Stubs funcionam como classes tem-
porárias de Proxies de modo remoto, que recebe 
os parâmetros dos métodos disponibilizados pelo 
objeto remoto, que envia para o servidor que será 
interpretado por uma classe Skeleton, a qual exe-
cuta as chamadas do objeto remoto e pode receber 
os valores dos métodos remotos e reenviar para os 
Stubs dos clientes�
 ● Camada de Referências Remotas: processo em 
que o RMI funciona como uma ligação unicast, na 
qual cada Stub possui seu Skeleton para comuni-
cação� Não é suportado pelo multcast, em que um 
proxy poderia requisitar várias instâncias de objetos 
remotos�
11
 ● Camada de transporte: camada que se refere à 
comunicação entre várias JVM, utilizando TCP/IP 
que gera uma pilha onde o RMI utiliza um protoco-
lo conhecido como Java Remote Method Protocol 
(JRMP), que ajuda nas ligações múltiplas do TCP/IP�
12
SERVIDOR WEB
Considera-se a tecnologia web de grande importân-
cia por utilizar protocolos de rede como Hypertext 
Transfer Protocol (HTTP), dentre outros� O funcio-
namento de aplicações web cresce com o uso de 
dispositivos móveis, como tabletes e smartphones 
com acesso à Internet�
As aplicações Web utilizam a arquitetura cliente-
-servidor que engloba um conjunto de tecnologias 
desenvolvidas sob padrões definidos por institui-
ções como o Instituto de Engenheiros Eletricistas 
e Eletrônicos (IEEE)�
SAIBA MAIS
IEEE é a maior organização profissional dedica-
da ao avanço tecnológico e é responsável por 
diversos padrões� Saiba mais sobre ela consul-
tando: http://www.ieee.org.br/� 
Os servidores mais utilizados são Apache e Internet 
Information Services (IIS) (LINHARES; OGAWA; 
PIMENTEL; SOUZA, 2014)� Há diversos outros ser-
vidores Web com tecnologias diferentes� Para você 
entender o funcionamento do ciclo de vida de um 
Servlet, é preciso saber como funciona um Web 
13
http://www.ieee.org.br/
Container e, para tanto, estudaremos o servidor 
Web Apache TOMCAT, assim como explorar as 
suas funcionalidades�
A Apache Software Foundation (ASF) é a empresa 
responsável por manter o servidor TOMCAT; trata-
-se de uma organização sem fins lucrativos que 
disponibiliza gratuitamente no seu website oficial 
toda a documentação e os assuntos relevantes a 
essa tecnologia (TOMCAT, 2016)�
14
ENTENDENDO A 
ARQUITETURA DO 
TOMCAT
A arquitetura básica do Apache TOMCAT é o pro-
cessamento em seu container das especificações 
JavaServer Pages e Servlets e funciona com a versão 
do Java de acordo com a versão do TOMCAT�
Uma arquitetura Web baseia-se em uma aplicação 
cliente-servidor, na qual há requisições e respostas 
do servidor (request/response), conforme ilustrado 
na Figura 2:
HTTP (HTML)
RESPONSE 
(resposta)
REQUEST
(requisita)
HTTP
Servidor WebComputador
Figura 2: Processamento servidor TOMCAT. Fonte: Elaborado pelo 
autor (2019).
Podcast 1 
15
https://famonline.instructure.com/files/142265/download?download_frd=1
As páginas no browser do computador enviam ou 
requisitam informações que são processadas pelo re-
cipiente do servidor Web� Nesse processo, utilizam-se 
o Servlet, que é conhecido como um “servidorzinho”, 
e a página HTML ou JSP�
Os códigos dentro dessas páginas utilizam em sua 
ação os Servlets criados no projeto, posto que as 
páginas podem estar tanto em HTML quanto em JSP� 
Observe, entretanto, que páginas HTML não proces-
sam códigos em Java diretamente em sua página 
como scriptlets (códigos em Java), mas chamam o 
Servlets no escopo dos formulários�
SAIBA MAIS
A Apache é uma das maiores empresas com diver-
sos produtos para download e uso gratuito� Você 
pode baixar o servidor TOMCAT gratuitamente em: 
https://tomcat.apache.org/download-80.cgi� 
16
https://tomcat.apache.org/download-80.cgi
ENGENHARIA DE 
SOFTWARE ORIENTADO 
A SERVIÇOS
A engenharia de software orientado a serviço é 
uma tecnologia conhecida como Service-Oriented 
Architecture, mais comumente SOA� Trata-se de um 
estilo de arquitetura cliente-servidor baseado sobre-
tudo em Web Services que disponibilizam interfaces 
conhecidas como contratos na programação�
Nesse tipo de arquitetura, devemos entender que os 
serviços de software dependem de um baixo aco-
plamento de unidades de funcionalidades, uma vez 
que os serviços são consumidos como aplicações 
isoladas, podendo trocar informações entre duas 
unidades diferentes, ou seja, plataformas distintas�
Para o SOA, os serviços dependem de dados agre-
gados aos metadados� No processo de desenvol-
vimento, a linguagem mais utilizada é o XML, parte 
de outras tecnologias que a englobam� Por exemplo, 
o SOA utiliza Web Services Description Language 
(WSDL) para a descrição dos serviços SOAP, WADL 
e REST, que são outras tecnologias utilizadas na 
arquitetura� É preciso lembrar que todo processo se 
realiza por metadados que devem seguir um design 
específico para o sistema poder entender.
17
WEB SERVICES
O SOA utiliza Web Services para disponibilizar os 
recursos que serão consumidos por outro software 
na rede� Para entender melhor esse conceito, lembre-
-se de que alguns sites, nos quais preenchemos o 
campo do CEP e, em seguida, os campos de rua, 
bairro e cidade são preenchidos automaticamente�
Os dados preenchidos automaticamente pertencem 
a uma companhia externa que disponibiliza seu Web 
Service, ou seja, um canal de comunicação de sua 
base de dados� Empresas, como os Correios, por 
exemplo, escolhem apenas alguns serviços úteis para 
serem consumidos em forma de Web Service� Sendo 
assim, várias companhias podem disponibilizar seus 
serviços por meio dessa tecnologia�
Avantagem de recorrer aos Web Services é a utili-
zação de protocolos disponibilizados para o uso na 
Web, que funciona independentemente da plataforma 
de quem disponibiliza o serviço, podendo ser Linux, 
Windows ou FreeBSD�
Imagine três empresas com software distribuídos 
diferentes� Você precisa acessar os dados das três 
para construir sua base de dados� Para essa sua 
aplicação, algumas regras de negócio foram esta-
belecidas para entrar no padrão dessa aplicação� 
Tenha em mente que o acesso é disponibilizado por 
Web Service, como na Figura 3�
18
Base de 
dados
Incluir Cliente
(Web Services)
Software 1
(Empresa 1)
Software 2
(Empresa 2)
Software 3
(Empresa 3)
Regras de 
negócio
Barramento de serviços
Figura 3: Web Service. Fonte: Guedes (2017).
O SOA funciona com base no Web Service, mas ob-
serve que há regras envolvidas, além da segurança 
dos dados e interoperabilidade� O uso apenas do 
Web Service não quer dizer que se está utilizando 
uma arquitetura SOA� A composição do Web Service 
pode ser feita com ferramentas que implementam 
Business Process Execution Language (BPEL), 
Business Process Management Notation (BPMN), 
porém, é possível utilizar outras tecnologias�
Lembrando que se identifica o serviço por uma 
Uniform Resource Identifier (URI) e a comunicação 
entre os Web Services é realizada via protocolos, 
como o Simple Object Access Protocol (SOAP)�
19
A comunicação do SOAP, WSDL, REST, entre outros, 
é realizada com a linguagem XML, tanto para o pres-
tador de serviço quanto para o consumidor que so-
licita� O SOA é baseado na ideia de composição de 
serviços, sendo que a aplicação de negócio envolve 
uma empresa parceira, devendo ser considerada a 
reutilização de um provedor externo�
A composição de serviços é utilizada para a inte-
gração dos processos de negócios distintos com 
objetivo de oferecer um processo integrado com 
funcionalidades externas cujo nível de complexibi-
lidade é alto� Assim, o processo de construção de 
uma aplicação (serviço composto) envolve:
 ● Workflow.
 ● Novos serviços�
 ● Seleção de serviços�
 ● Refatoração do workflow.
 ● Programação de workflow.
 ● Testes dos serviços�
Para entendermos melhor o processo de composi-
ção, vamos observar a Figura 4, na qual a comuni-
cação é gerenciada por um sistema de coordenação 
central que, na requisição, recebe e responde para 
invocar o Web Service recorrente�
20
Orquestração
Receber
invocar
invocar
invocar
Responder
Coordenador 
Central
Requerente 
do Serviço
Web 
Service
Web 
Service
Web 
Service
Figura 4: Orquestração. Fonte: Adaptada de Masiero (s. d.).
21
ENGENHARIA 
DE SOFTWARE: 
DESENVOLVIMENTO 
PROFISSIONAL E ÉTICA
A Engenharia de Software é uma área do conheci-
mento que nasceu em decorrência das dificuldades 
nos processos envolvidos� Com o decorrer do tempo, 
as metodologias, normas, técnicas e boas práticas de 
projetos foram adotadas por empresas e instituições 
governamentais como meio de garantir a qualidade�
A Engenharia de Software engloba muitas coisas, 
no entanto, a maioria dos modelos visa ao melhora-
mento contínuo baseado no Plan, Do, Control e Act 
(PDCA)� Um dos principais pontos é a qualidade do 
software, a qual envolve fatores em conformidade 
com o projeto�
A produção de software pode ou não recorrer à 
engenharia de modo a melhorar o processo e ter 
qualidade� Algumas empresas preferem apenas pro-
duzir sem pensar muito na qualidade; dessa forma, 
no decorrer do projeto, os erros são arrumados por 
demanda, sendo um risco muito alto para o projeto 
nem mesmo chegar ao fim.
Um dos modelos mais utilizados na Engenharia de 
Software é o Capability Maturity Model Integration 
(CMMI), com cinco níveis de maturidade que a empre-
sa deve seguir para apresentar a qualidade esperada 
22
no processo de desenvolvimento, isto é, garantia 
antes e depois da entrega�
Empresas que utilizam o CMMI têm uma credibili-
dade melhor no mercado, elevando seus produtos a 
outro nível, ou seja, com uma qualidade assegurada 
aos seus clientes� Isso porque o CMMI é um modelo 
norte-americano e, para concorrer com esse modelo, 
os europeus desenvolveram a ISO/IEC 15504, que é 
bastante semelhante ao CMMI�
No entanto, esses modelos não são muito aplica-
dos no Brasil, deixando pouca credibilidade para as 
empresas� O custo inicial é considerado alto, porém, 
no final, o software sai com menos defeitos e com o 
custo dentro do planejado�
No Brasil, há ISO/IEC 9000-3 que é referente à qua-
lidade de software, mas é pouco usada também� 
Um modelo puramente brasileiro foi construído par 
atender às realidades do mercado� Esse modelo é o 
MPS�BR, baseado principalmente no CMMI�
As normas envolvem especialmente testes de sof-
tware, que se relacionam com a qualidade do softwa-
re, que é uma das áreas da Engenharia de Software� 
Assim, as metodologias são aplicadas junto com 
outras para se chegar à qualidade no processo de 
desenvolvimento�
Em um projeto de software, envolvem-se bastante 
técnicas, modelos e normas, dentre os quais pode-
mos citar PMBOK, BABOK, CMMI, ISO/IEC 9126, ISO/
IEC 12207, ISO/IEC 15504, ITIL e COBIT�
23
Há mais metodologias e modelos, tendo em vista que 
todos servem para auxiliar no processo de software� 
Perceba que não estamos falando de código, mas 
sim de conhecimento necessário para elaborar um 
projeto com os requisitos� É precisamente nesse pon-
to que um profissional conhecido como engenheiro 
de software entra�
24
PROFISSIONAL DE 
ENGENHARIA DE 
SOFTWARE
O mercado está passando por grandes mudanças, 
e o profissional de engenharia de software tem se 
adaptado a ele� Para algumas empresas, um pro-
fissional que atua com ferramentas de testes, ou 
desenvolvimento de software, já é considerado um 
engenheiro de software�
REFLITA:
Qual é a diferença entre um analista de sistema, 
um desenvolvedor e um engenheiro de software?
Deve-se entender que o nome é Engenharia, que 
não é a mesma coisa que o programador ou testa-
dor� Portanto, o conceito muitas vezes é distorcido� 
Vamos fazer uma comparação na área de engenha-
ria� Na construção civil, há um engenheiro civil, que 
estudou e sabe os cálculos corretos para projetar 
uma ponte ou sustentar um prédio; o pedreiro pode 
não saber, mesmo que seja o melhor� Em outras 
palavras, não se exige do pedreiro o conhecimento 
para tal obra� Agora imagine esse pedreiro sendo 
registrado como engenheiro civil só porque faz parte 
do processo�
25
O profissional de engenharia de software resolve 
problemas e conserta processos porque tem mui-
ta experiência em diversas áreas do conhecimento 
dentro da área da computação�
Na Alemanha, por exemplo, um profissional de 
engenharia de software iniciante tem experiência 
acima de seis anos, com certificações de arquite-
to nas principais tecnologias, como arquiteto Java 
e Microsoft, Banco de Dados, CISCO, PMBOK, ITIL, 
PRINCE2, COBIT, BPEL, BPMN, dentro outros�
Esses profissionais de alto nível são capazes de 
projetar novos produtos ou solucionar problemas 
em pouco tempo. Não são pagos para ficarem sen-
tados programando ou testando, apesar de já terem 
feitos isso por alguns anos, por isso, são bons no 
que fazem�
A cultura do Brasil em relação à engenharia de sof-
tware é um pouco deferente, pois se considera ape-
nas a programação� Você pode encontrar cursos 
superiores com esse nome: engenharia de software, 
que na verdade é praticamente uma grade toda de 
um curso de ciência da computação�
O questionamento que fica é: como ser um enge-
nheiro de software de alto nível? Simples� Com muita 
experiência em diversas áreas e certificações para 
comprovar que você realmente sabe o que está 
fazendo�
Na Alemanha, um salário de engenheiro de softwa-
re por ano pode chegar de R$150 mil a R$ 236 mil� 
26
Calma, não se anime tanto, isso é para um profissio-
nal com mais de dez anos de experiência no mercado 
e várias certificações (GALDINO, 2016).
No Brasil, um profissional de engenharia de software 
tem um salário quevaria de R$ 7 mil a R$ 15 mil por 
mês� Normalmente, exerce algumas atividades da 
área da engenharia e, sobretudo, testes e desenvol-
vimento (SALARIO, 2019)�
27
PRINCIPAIS ÁREAS DA 
ENGENHARIA DE SOFTWARE: 
GERENCIAMENTO DE 
CONFIGURAÇÃO DE 
SOFTWARE
Para a produção de software, é preciso ter um maior 
controle no processo de desenvolvimento, pois a 
complexibilidade dos projetos apresenta diversos 
requisitos que podem gerar inconsistências� Assim, 
a área de software, por envolver projetos com altos 
custos e aplicações, tem uma grande importância, 
tal qual na área militar ou de saúde, em que foram 
desenvolvidas normas para que os padrões fossem 
seguidos�
O ato de seguir essas normas nos projetos é conheci-
do como gerência de configuração de software e visa 
a garantir tanto a integridade quanto a consistência 
dos itens e controles dos requisitos (PRESSMAN; 
MAXIM, 2016)�
28
FERRAMENTAS E 
MÉTODOS
Pode-se descrever o processo de software como um 
conjunto de atividades, práticas, métodos e normas 
que servem como um guia em projetos de produção 
de software� O desenvolvimento de software implica 
muitos processos que são divididos em tarefas e 
subtarefas que permitem um melhor gerenciamento 
dos itens e da qualidade de software�
Metodologias e modelos de desenvolvimento são 
aplicados com o auxílio de ferramentas de processos 
de negócio� Algumas dessas ferramentas são conhe-
cidas como Computer-Aided Software Engineering 
(Case), ou Engenharia de Software Assistida por 
Computador� Essas ferramentas ajudam no desenvol-
vimento de software e, principalmente, na abstração 
dos processos de negócios�
Algumas ferramentas Case utilizadas na engenha-
ria de software são Business Process Execution 
Language (BPEL), ou Linguagem de Execução de 
Processos de Negócios e Business Process Model 
(BPM), ou Modelo de processo de negócios� São 
ferramentas utilizadas na elaboração e execução de 
processos de negócios de software�
O BPEL, por exemplo, é atribuído diretamente à auto-
matização e execução dos processos de negócios� 
Já o BPM implica uma abrangência maior na sua 
29
aplicação, que estuda como a tecnologia pode apoiar 
a análise, a execução e o controle dos processos de 
negócio no geral (SGANDERLA, 2013)�
Projeto e desenho (Design):
 ● Aplica-se a projetos de pesquisa sobre o desen-
volvimento de um produto e envolve planejamento, 
metodologia, cronograma e recursos�
 ● Desenho é uma tradução utilizada no sentido de 
Desenho Industrial (industrial design), conhecido 
como a elaboração de diagramas que descrevem 
os modelos do produto�
 ● Os tipos são: Design do modelo conceitual; Design 
da interface de usuário; Design da arquitetura de sof-
tware; e Design dos algoritmos e estruturas de dados�
30
QUALIDADE DE 
SOFTWARE
A qualidade de software é uma área de conhecimento 
da engenharia de software que tem como objetivo 
garantir a qualidade� O software possui muitos fa-
tores que o desenvolvimento deve considerar para 
assegurar a qualidade de acordo com os requisitos�
A qualidade do software é estabelecida nos acor-
dos e contratos de projetos, estando ligada à ética 
profissional das empresas, que muitas vezes têm 
certa reputação no mercado e reconhecimento in-
ternacional. A fim de que a qualidade de software 
seja estabelecida, as instituições utilizam métodos e 
modelos nos processos de desenvolvimento, dentre 
os quais se destacam:
Podcast 2 
 ● CMM – Capability Maturity Model é método de 
avaliação com 5 níveis de maturidade que indica 
diretrizes para melhoria�
 ● PSP – Personal Software Process são processos 
pessoais utilizados pelos desenvolvedores que tra-
balham verificando a qualidade dos módulos sob 
sua responsabilidade�
 ● ISO/IEC 15504 – Trata-se de um framework cujo 
foco são o planejamento, o gerenciamento, o moni-
toramento, o controle de aquisição, o fornecimen-
31
https://famonline.instructure.com/files/142266/download?download_frd=1
to, o desenvolvimento, a operação e o suporte de 
software�
 ● RUP – Rational Unified Process foi desenvolvido 
pela IBM e consistem em um Processo de engenharia 
de software que utiliza como base caso de usos em 
seus processos�
 ● Série ISO/IEC 14598 – Normas que estabelecem 
a qualidade do produto, com foco no processo de 
desenvolvedores�
32
TESTE DE SOFTWARE 
Os testes de software fazem parte do processo de 
qualidade e têm como principal objetivo revelar os 
problemas e as falhas nos projetos de software� Na 
Tabela 3, temos alguns dos testes mais conhecidos 
e sua respectiva descrição:
Tipo Descrição
Teste de unidade Testa um nível de componente ou 
classe, seu objetivo é um “pedaço do 
código”�
Teste de 
Integração
Garante que um ou mais componentes 
combinados (ou unidades) funcionam�
Teste 
Operacional
Garante que a aplicação pode rodar 
muito tempo sem falhar�
Teste
Positivo-negativo
Garante que a aplicação vai funcionar 
no “caminho feliz” de sua execução e 
no seu fluxo de exceção.
Teste de 
Regressão
Testa toda a aplicação novamente 
todas as vezes que algo for mudado�
Teste de
Caixa-preta
Testa todas as entradas e saídas 
desejadas� Não está preocupado com 
o código, pois cada saída indesejada é 
tida como um erro�
Teste
Caixa-branca
Tem por objetivo testar o código 
ou partes do código que não foram 
testadas�
Teste Funcional Testa funcionalidades, requerimen-
tos e regras de negócio presentes na 
documentação�
Teste de 
Interface
Testa a navegabilidade e os objeti-
vos da tela para melhorar a forma ao 
usuário�
33
Teste de 
Performance
Verifica se o tempo de resposta é o 
desejado para o momento de utiliza-
ção da aplicação�
Teste de Carga Verifica o funcionamento da aplicação 
com a utilização de uma grande quan-
tidade de usuários simultâneos�
Teste de 
Aceitação do 
usuário
Testa se a solução será bem vista pelo 
usuário� 
Teste de Volume Testa a quantidade de dados� 
Testes de Stress Testa a aplicação em situações 
inesperadas� 
Testes de 
Configuração
Testa se a aplicação funciona corre-
tamente em diferentes ambientes de 
hardware ou software�
Testes de 
Instalação
Testa se a instalação da aplicação foi 
OK�
Testes de 
Segurança
Testa a segurança da aplicação das 
mais diversas formas�
Tabela 3: Tipos de teste e breve descrição. Fonte: Portalgsti. 
34
https://www.portalgsti.com.br/testes-de-software/sobre/
NORMAS ISO COM FOCO 
NA QUALIDADE DE 
SOFTWARE
A norma ISO tem sua origem a partir da International 
Federation of the National Standardizing Associations 
(ISA) em 1926 e cessou suas atividades em 1942, 
em decorrência da Segunda Guerra Mundial (SILVA, 
2013)� Com o término da guerra, em 1945, e com a 
evolução industrial, um novo grupo foi organizado a 
fim de estabelecer normas capazes de unificar pa-
drões mundiais, facilitando assim a coordenação� A 
International Organization for Standardization (ISO) 
foi criada por 25 países-membro e o encontro reali-
zou-se em Londres�
 ● A ISO nasceu de normas militares (SILVA, 2013):
 ● Normas Militares Americanas - MIL STD� 
- Padronização�
 ● MIL-Q-9858 foi a primeira Norma de Especificações 
de Sistema da Qualidade�
 ● MIL-I-45205 São requisitos de um Sistema da 
Qualidade�
 ● AQAP (Allied Quality Assurance) OTAN - Garantia 
da Qualidade�
 ● DEF�STAN (Defense Standard) Reino Unido - 
Normas das Forças Armadas Sobre os Sistemas da 
Qualidade�
 ● BS-5750 (British Standard)�
35
A primeira norma ISO a ser criada foi a 9000:1987, 
que se baseou na antiga norma BS-5750 (British 
Standard)� No entanto, devido à globalização, ou-
tras normas de qualidade foram surgindo e sendo 
aperfeiçoadas�
A organização da ISO é uma instituição sem fins lu-
crativos localizada em Genebra, Suíça� No Brasil, a 
ISO é representada pela Agência Brasileira de Normas 
Técnicas (ABNT), instituição em que as normas são 
traduzidas e têm acrescentada a sigla NBR� Por 
exemplo: NBR ISO 9000�
Por conta da globalização e de um padrão interna-
cional exigente com a alta produção e qualidade 
de baixo custo,governos e companhias utilizam as 
normas ISO como uma especificação de garantia e 
qualidade�
Há diversas variações das normas ISO, desde presta-
ção de serviço, produção, qualidade, automobilística, 
software, dentre outras� A industrialização comercial 
e o avanço tecnológico forçaram as organizações 
militares e privadas a terem padrões de qualidade 
muito exigentes, principalmente em projetos críticos 
militares e da agência espacial americana, a Nasa 
(SASABE, 1995)�
A ISO não é uma metodologia ou capacitação de 
maturidade como são CMM/CMMI, SPICE, CoBit, ITIL, 
mas pode ser utilizada no processo e nos escopos 
dos projetos� As normas são utilizadas simultanea-
mente e interligadas para cobrir as necessidades do 
produto ou do serviço�
36
NBR ISO/IEC 9126-
1 QUALIDADE DO 
PRODUTO DE SOFTWARE
A norma ISO/IEC 9126-1 está direcionada à qualidade 
do produto de software e dividida em quatro partes: 
1. Modelo de qualidade�
2. Métricas internas�
3. Métricas externas� 
4. Métricas de qualidade de uso do software� 
De acordo com Campos (s. d.), a NBR ISO/IEC 9126-1 
descreve a qualidade do produto de software, bem 
como enfatiza sua utilização interna e externa e sub-
divisões de cada uma para sua utilização correta� 
Portanto, a norma específica às características de 
qualidade aplicada a todo tipo de software�
Essas características são aplicadas a programas 
de computador e dados contidos em firmware. Por 
exemplo, temos o uso do modelo de qualidade defi-
nido nesta parte da NBR ISO/IEC 9126 para:
 ● Validar a completitude de uma definição de 
requisitos�
 ● Identificar requisitos de software.
 ● Identificar objetivos de projeto de software.
 ● Identificar objetivos para teste de software.
37
 ● Identificar critérios para garantia de qualidade.
 ● Identificar critérios de aceitação para produtos de 
software�
A subdivisão de qualidade de software da NBR ISO/
IEC 9126 divide-se em seis principais aspectos: 
 ● Funcionalidade
 ● Confiabilidade
 ● Usabilidade
 ● Eficiência
 ● Manutenibilidade
 ● Portabilidade
Entretanto, muitas vezes a NBR ISO/IEC 9126 não é 
bem compreendida ou não aplicável (CAMPOS, s� d�)� 
Por um lado, a norma não diz como fazer, mas o que 
precisa ser feito� Por outro lado, a NBR ISO/IEC 9126 
deixa bem claro a integração com outras normas de 
qualidade, além de ilustrar como se integra a norma 
de gestão de qualidade de software (Figura 5):
38
Recursos
e
ambiente
Apoio à 
avaliação
Processo 
de 
avaliação
Métricas 
internas
14598-1
14598-2
14598-6
Métricas 
externas
14598-3
14598-4
14598-5 9126-3 9126-2
9126-1
9126-4
Processo 
de 
avaliação
Produto 
de 
software
Efeitos do 
produto de 
software
Métricas 
de 
qualidade 
em uso
Figura 5: Relação entre as NBR ISO/IEC 9126 e NBR ISO/IEC 14598.
Fonte: ABNT (2003).
Assim, trata-se de uma norma flexível a se utilizar 
conforme os requisitos do produto do software� O 
processo de melhoria contínua PDCA está, então, 
no ciclo de vida de processo de desenvolvimento 
do software�
A NBR ISO/IEC 9126, em suas Notas, sugere a utiliza-
ção ou cita as semelhanças de conceitos em diversas 
normas, como:
 ● ISO/IEC 15504 para avaliação de processo de 
software�
 ● ISO/IEC 12207 ao ciclo de vida de software�
 ● ISO/IEC 9001 a processos de garantia de qualidade�
 ● ISO/IEC 14598 para avaliação de software�
 ● IEC 60050-191 para dependabilidade�
 ● ISO 9241-10 adequação à tarefa�
39
 ● ISO/IEC 2382-14 confiabilidade.
Portanto, a NBR ISO/IEC 9126 mantém seu foco 
nas quatro fases de qualidade de seu ciclo de vida 
(Figura 6). Entende-se que os termos de definição 
de qualidade na norma descrevem a estrutura de um 
modelo flexível, tal qual demonstrado na própria nor-
ma� Ainda, a norma descreve a utilização de outras 
normas em cada um de seus subsistemas�
Qualidade do 
processo
Atributos de 
qualidade 
interna
depende de depende de depende de
influencia influencia influencia
Atributos de 
qualidade 
externa
Atributos 
de 
qualidade 
em uso
Contextos 
de uso
Medidas de 
processo
Medidas 
internas
Medidas 
externas
Medidas de 
qualidade 
em uso
processo produto de software
efeitos do 
produto de 
software
Figura 6: Qualidade no ciclo de vida. Fonte: ABNT (2003).
A NBR ISO/IEC 9126 mantém seu foco no ciclo de 
qualidade em seu processo e enfatiza a utilização 
de outras normas para integrar a qualidade interna, 
externa e a utilização do software�
40
NBR ISO/IEC 15504 
PROCESSOS DE 
SOFTWARE EM NÍVEIS 
DE MATURIDADE 
- QUALIDADE
Em 1993, houve a necessidade de atingir os níveis 
de maturidade propostos pelos modelos anteriores, 
desenvolveu-se a norma ISO 9001; segundo a ISO/
IEC 15504, realizou-se o projeto Software Process 
Improvement and Capability Etermination (Spice), 
que inicialmente era um relatório técnico criado pela 
ISO para dar início à construção da norma�
A ISO/IEC 15504 foi encomendada pelo Ministério 
da Defesa do Reino Unido em 1990, dada a neces-
sidade de requisitos para a avaliação de processo 
de software� Cita ainda a participação de um grupo 
formado pela ISO para trabalhar no projeto Spice, 
aprovado em 1993�
As primeiras versões da norma ISO/IEC 15504 foram 
criadas exclusivamente para o desenvolvimento de 
software com vistas a cobrir todos os processos 
relacionados à criação de software, dentre eles o 
projeto de gestão, o gerenciamento de configuração 
e a garantia de qualidade (IBPI, 2014)�
Assim, “[...] o padrão 15504 define uma estrutura para 
avaliação e melhoria de processos de engenharia de 
41
software, e prescreve práticas básicas que devem 
ser realizadas para que se atinjam certos níveis de 
maturidade” (LAHOZ; ANNA, 2019)�
Rincon (2009), por sua vez, define a norma ISO/IEC 
15504 como um modelo de capacidade de proces-
so de software baseado nos processos da ISO/IEC 
12207� A norma ISO/IEC 12207 está ligada ao proces-
so de desenvolvimento e à manutenção do software 
e é utilizada com a ISO/IEC 15504 (LAHOZ; ANNA, 
2019)�
Entretanto, a norma ISO/IEC 15504 é dividida em cin-
co categorias, com base nas TR do Spice (Technical 
Report) (IBPI, 2014):
 ● Parte 1: Conceitos e Vocabulário (com base nas 
antigas partes 1 e 9 do TR2)�
 ● Parte 2: Realização de uma Avaliação (com base 
nas antigas partes 2 e 3 do TR2, eliminando-se as 
referências à dimensão de processo)�
 ● Parte 3: Guia para a Realização de uma Avaliação 
(com base nas antigas partes 4 e 6 do TR2)�
 ● Parte 4: Guia para a Utilização dos Resultados de 
uma Avaliação (com base nas antigas partes 7 e 8 
do TR2)�
 ● Parte 5: Um Modelo Exemplo para Avaliação (com 
base na antiga parte 5 do TR2)�
A norma possui seus níveis de maturidade semelhan-
tes ao CMM (Figura 7). Os tópicos não são isomórfi-
cos e há um alto nível de abstração definido (PAULK, 
42
1999)� Assim, a norma garante os princípios de qua-
lidade no processo de ciclo de vida do software�
Níveis de capacidade
Otimizando: melhoramento contínuo
Previsível: funciona sob controle
Executando: funciona de forma não planejada
Incompleto: falha ou inexistente
Gerenciando: funciona de forma planejada
Estabelecido: funciona de forma sistemática
0
1
2
3
4
5
Figura 7: Níveis de capacidade ISO 15504. Fonte: Paulk (1999).
Para o desenvolvimento de modelos, o relatório con-
tido na ISO/IEC 15504 ajuda a identificar tanto os 
pontos fracos quanto os pontos fortes na elaboração 
do plano de melhoria, além de verificar a conformida-
de dos requisitos da mesma norma (RABELLO et al�, 
2012)� Na Figura 8, podemos verificar os processos 
envolvidos na norma�
43
Processos Primários
Aquisição (Acquisition)
ACQ� 1: preparação 
ACQ�2: selo de fornecedor 
ACQ�3: contrato
ACQ�4: monitoração do fornecedor 
ACQ�5: aceitação
Fornecimento (Supply)
SPL�1: proposta (tendering) 
SPL�2: release do produto
SPL�3: aceitação e suporte
Engenharia (Engineering)
ENG�1: elic� requisitos ENG�7: integração de SW
ENG�2: an� req sistema ENG�8: teste de SW
ENG�3: arq� sist� ENG�9: integração de sistemaENG�4: an� req SW ENG�10: teste de sistema
ENG�5: design SW ENG�11: instalação de SW
ENG�6: constr� sw ENG�12: manutenção de SW e sist�
Operação (Operation)
OPE�1: uso operacional
OPE�2: suporte à operação
Processos Organizacionais
Gestão (Management)
MAN�1: alinhamento organizacional 
MAN�2: gestão organizacional
MAN�3: gestão de projeto
MAN�4: gestao da qualidade
MAN�5: gestão de risco
MAN�6: medição
44
Melhoria de Processos (Process Improvement)
PIM.1: definição de processo
PIM�2: avaliação de processo
PIM�3: melhoria de processo
Gestão de Recursos (Resource and lnfrastructure)
RIN�1: recursos humanos 
RIN�2: treinamento
RIN�3: gestão do conhecimento
RIN�4: infra-estrutura
Reuso (Reuse)
REU�1: gestão de ativos (assets) 
REU�2: gestão do programa de reuso
REU�3: engenharia de domínio
Processos de Apoio
Apoio
SUP� 1: garantia da qualidade SUP� 6: avaliação de produto 
SUP. 2: verificação SUP� 7: documentação
SUP� 3: validação SUP. 8: gestão de configuração
SUP� 4: revisão conjunta SUP� 9: solução de problemas
SUP� 5: auditoria SUP�10: gestão de mudança
Tabela 4: Quadro de tarefas da ISO/IEC 15504-5. Fonte: Adaptada de 
Rabello et al. (2012).
Assim, a norma ISO/IEC 15504 adotada no Brasil é 
acrescentada de NBR ISO/IEC 15504, ou seja, uma 
das normas que contêm diversos escopos para 
acompanhar os processos do software� Em seus 
escopos, a adoção de outras normas, como a NBR 
ISO/IEC 12207, também é utilizada para completar 
o ciclo de qualidade e necessidades dos requisitos 
que estão descritos na NBR ISO/IEC 15504�
45
ÉTICA NA ENGENHARIA 
DE SOFTWARE
A ét ica pode ser d iv id ida em três n íveis 
(GOTTERBARN, 1999):
 ● Nível 1: São as obrigações que fazem parte da 
humanidade, que envolvam a integridade, justiça, 
lealdade e moral�
 ● Nível 2: Relaciona-se com profissões e cuidados 
do bem-estar social�
 ● Nível 3: Trata-se do Código de ética de cada pro-
fissão especificamente.
Instituições reconhecidas internacionalmente ado-
tam o código de ética, como IEEE e ACM, ambas de 
tecnologia e que estão ligadas diretamente com a 
produção de conhecimento e normas de engenharia�
O código de ética foi desenvolvido por um grupo de 
cooperação internacional com o apoio de indústria, 
governos e instituições que apoiam a ética no traba-
lho (GOTTERBARN; MILLER; ROGERSON, 1999)� Na 
Tabela 4, encontramos alguns princípios da ética na 
engenharia de software:
 
46
Local Descrição
Público Engenheiros de Software devem atuar consis-
tentemente com os interesses públicos�
Clientes e 
empregados
Engenheiros de Software devem atuar de 
modo a atender os melhores interesses dos 
seus clientes e empregados, consistentemen-
te com os interesses públicos�
Produto
Engenheiros de Software devem assegurar 
que seus produtos e modificações relaciona-
dos atendam aos melhores padrões profissio-
nais possíveis�
Julgamento
Engenheiros de Software devem manter a 
integridade e a independência nos seus julga-
mentos profissionais.
Administração
Administradores e líderes de Engenharia de 
Software devem aderir e promover uma abor-
dagem ética ao gerenciamento do desenvolvi-
mento e manutenção de software� 
Profissão
Engenheiros de Software devem desenvolver 
a integridade e reputação da profissão consis-
tentemente com os interesses do público�
Coleguismo Engenheiros de Software devem ser justos e 
dispostos a auxiliar seus colegas�
Identidade
Engenheiros de Software devem participar do 
aprendizado de suas vidas valorizando a prá-
tica da sua profissão e devem promover uma 
abordagem ética à prática da profissão.
Tabela 5: Princípios de Ética. Fonte: Gotterbarn (1999).
A ética em projetos de software está ligada sobretu-
do à prestação de serviços, a contratos e a acordos 
do lado do cliente e da empresa e seus profissionais. 
Visando a garantir uma qualidade de serviços de 
Tecnologia da Informação, alguns métodos e nor-
mas foram estabelecidos para haver um padrão na 
47
entrega dos serviços e que os contratantes cumpram 
aquilo que foi acordado�
A ética dos profissionais da engenharia de softwa-
re não está ligada apenas à integridade da pessoa, 
mas também aos envolvidos no projeto� Logo, ser 
ético envolve compromissos e acordos que, para 
o contratado e o contratante, devem ser honrados�
A NBR/ISO 20000 trata da prestação de serviços na 
área de Tecnologia da Informação (TI) e cobre os 
processos envolvidos na gestão voltada ao objetivo 
do negócio�
48
NBR/ISO 20000 GESTÃO 
DE SERVIÇOS NA ÁREA 
DE TECNOLOGIA DA 
INFORMAÇÃO
A NBR ISO/IEC 20000 é uma especificação do 
Gerenciamento de Serviços na área de Tecnologia 
da Informação desenvolvida pela British Standards 
Institution (BSI), ou Instituto de Padrões Britânicos, 
que substitui a antiga BS 15000 (EXIN, 2010-2011)�
ISO 20000 é o padrão internacional para 
Gerenciamento de Serviços de TI (ITSM), publicado 
pela ISO e Comissão Internacional Eleitoral (ICE)� 
Para se tornar um padrão internacional, a ISO 20000 
teve de ser acordada pela maioria dos países-mem-
bro, o que significa ser aceita pela maioria dos países.
Com a NBR ISO/IEC 20000, descreve-se um conjunto 
de processos de gestão destinado a ajudar a en-
tregar os serviços de TI mais eficientemente tanto 
para aqueles dentro do negócio quanto aos clientes� 
Assim, por meio dos requisitos da norma, é possível 
conseguir melhores práticas, ajudando a melhorar a 
prestação de serviços de TI e aplicável a qualquer 
tamanho da empresa e qualquer indústria�
São requisitos da NBR ISO/IEC 20000:
 ● Processos de planejamento e implementação� 
 ● Processos de entrega de serviços�
49
 ● Processos de relacionamento�
 ● Processos de solução�
 ● Liberação e controle�
Portanto, a NBR ISO/IEC 20000 possui um conceito de 
três níveis representado por uma pirâmide (Figura 9)�
Contexto da ISO/IEC 20000
ISO/IEC
20000-1
ISO/IEC 20000
Code of Practice
DEVEM TER
• Requisitos Mínimos
• Check List
PODEM TER
• Melhoria da Parte I
• Recomendações
História e Partes
ISO/IEC 20000-2
Básicos: Gerenciamento de 
Serviços de TI (ex: ITIL®, 
MOF, CobiT) & 
Gerenciamento da 
Qualidade (ex ISO 9000)
ISO/IEC 20000
Specification
Figura 8: Contexto da ISO/IEC 20000. Fonte: EXIN (2010-2011).
50
METODOLOGIAS 
TRADICIONAIS DE 
DESENVOLVIMENTO DE 
SOFTWARE
Podemos entender a metodologia como um con-
junto de práticas coordenadas com a finalidade de 
atingir um objetivo, fornecendo um roteiro e proces-
sos dinâmicos e iterativo para um desenvolvimento 
estruturado de um projeto de software com foco na 
qualidade� Dessa forma, o desenvolvimento tradi-
cional de software utiliza alguns modelos, dentre os 
quais se destacam o modelo cascata, a prototipação 
e o espiral�
51
MODELO CASCATA
O modelo cascata foi criado em 1970 por Winston 
Walker Royce, sendo bastante aceito até meados da 
década de 1980. Esse modelo tem a finalidade de 
determinar sequencialmente as etapas do desen-
volvimento de um projeto e de garantir que as ideias 
sejam analisadas sob todos os aspectos, de modo 
que nada fique de fora. Possui forma sequencial de 
maneira rígida e menos administrativa, pois todos os 
requisitos são determinados no início do projeto, por 
ser sequencial não pode haver falhas�
Utilizou-se o modelo cascata como base para outros 
modelos de desenvolvimento, como o iterativo, cujas 
fases estão ilustradas na Figura 10:
Requerimento
Projeto
Implementação
Verificação
Manutenção
Figura 9: Modelo Cascata. Fonte: Casa da Consultoria (s. d.).
O modelo cascata sequencial é utilizado principal-
mente em projetos críticos, ou seja, aqueles que en-
52
volvam riscos para pessoas. Tem os requisitos defi-
nidos no início do projeto, assim como seu custo� O 
projeto de software é bem definido e não pode haver 
falha; caso haja, deve ser abortado ou reiniciado� Ele 
tampouco é um modelo iterativo, porém, serve como 
base para outros modelos de desenvolvimento� Cada 
fase do projeto está descrita na Tabela 5:
Fases Descrição
Requisitos
São estabelecidos os requisitosneces-
sários para o produto que o idealizador 
deseja desenvolver, o que normalmente 
se baseia nos serviços que precisam ser 
fornecidos, nas limitações aceitáveis e 
os objetivos do software�
Projeto do 
Sistema
Diversos processos distribuídos por qua-
tro atributos: estrutura de dados, a arqui-
tetura do software, caracterização das 
interfaces e detalhes procedimentais�
Implementação
Quando os programas são criados, 
começa a etapa de implementação� Se 
o projeto tiver um nível de detalhamento 
mais avançado, a etapa de codificação 
pode ser implementada de maneira 
automática�
Verificação
Após o fim da etapa de codificação, a 
fase da realização de testes do sistema 
começa� Este processo foca em dois 
pontos principais: as lógicas internas do 
software e as funcionalidades externas�
Manutenção
A fase da manutenção baseia-se na 
correção de erros que não foram detec-
tados durante os testes, em melhorias 
funcionais e, de preferência, com os 
demais tipos de suporte�
Tabela 6: Modelo cascata. Fonte: Adaptada de Pressman e Maxim 
(2016).
53
MODELO 
INCREMENTAL
O ciclo de vida incremental é agrupado por módulos, 
cujos requisitos são definidos e o planejamento de 
suas fases são executadas sequencialmente, com 
base na importância das funcionalidades segundo 
necessidades do cliente� Assim, cada módulo pas-
sa pelas fases do modelo cascata e, ao final, essa 
parte é entregue ao cliente� Podemos entender esse 
modelo como uma sequência de modelos cascatas 
(Figura 11)�
Requerimento
Projeto
Implementação
Verificação
Implantação
Requerimento
Projeto
Implementação
Verificação
Implantação
Requerimento
Projeto
Implementação
Verificação
Implantação
Incremento 3
Incremento 2
Incremento 1
Figura 10: Modelo Cascata. Fonte: Pressman e Maxim (2016).
54
METODOLOGIA EM 
PROTOTIPAÇÃO
Considera-se este modelo um ciclo de vida que faz 
parte de outros modelos de ciclo de vida� Por exem-
plo, ele pode ser utilizado na produção de um dese-
nho de uma tela com alguma funcionalidade�
Nesse tipo de modelo, não é preciso ter todos os re-
quisitos do projeto definido como no modelo cascata. 
Por isso, é possível ter uma ideia de como ficará parte 
do sistema, sendo possível inclusive trocar informa-
ções com clientes que não têm uma definição certa 
dos requisitos ou que careçam de entendimento�
Na prototipagem, o cliente consegue visualizar me-
lhor o produto, mesmo que parcialmente, apresen-
tando uma resposta mais adequada e, com isso, 
melhorando o entendimento� O ciclo de vida da pro-
totipagem segue as fases ilustrada na Figura 12�
Construção de 
Protótipo
Implantação, 
Entrega e 
Feedback
Comunicação
Plano 
Rápido
Modelagem
Projeto Rápido
Figura 11: Modelo de prototipagem. Fonte: Pressman e Maxim (2016).
55
No protótipo, normalmente não há conexões com 
bancos de dados, pois a intenção é mostrar ao clien-
te como ficaria o desenho do sistema para validar 
alguns requisitos básicos� O cliente pode ainda com-
parar o que foi definido no começo com os projetos 
finais.
56
RAPID APPLICATION 
DEVELOPMENT
O modelo Rapid Application Development (RAD) é 
considerado uma evolução da prototipagem rápida, 
visto que o ciclo de vida é maior, bem como possui 
uma regra de duração entre 60 e 90 dias� É tido como 
um modelo incremental e iterativo�
No modelo RAD, há um forte paralelismo das ativida-
des, sendo que os modelos são independentes� Essa 
característica possibilita que os modelos possam se 
desenvolver por equipes diferentes� Dessa manei-
ra, o levantamento de requisitos costuma ser mais 
dinâmico, como o uso de workshops no lugar das 
entrevistas� É possível, então, um desenvolvimento 
inicial com grau mais alto de abstração e com um 
envolvimento maior do usuário e visualização dos 
protótipos (Figura 12)�
57
modelagem do 
negócio
modelagem 
dos dados
modelagem do 
processo
geração da 
aplicação
teste e 
modificação
60-90 dias
equipe # 3
modelagem do 
negócio
modelagem 
dos dados
modelagem do 
processo
geração da 
aplicação
teste e 
modificação
equipe # 2
modelagem do 
negócio
modelagem 
dos dados
modelagem do 
processo
geração da 
aplicação
teste e 
modificação
equipe # 1
Figura 12: Modelo RAD. Fonte: Devmedia.
58
MODELO ESPIRAL
Este modelo possui um formato de espiral em que 
cada volta passa por quatro fases com a intenção 
de melhorar continuamente, ou seja, se houver algu-
ma manutenção no próximo ciclo, ocorrem falhas 
ou atualizações. Assim, apenas o início é definido; 
por ser um modelo evolutivo, demanda tempo para 
ajustes e custos do projeto�
Com essas características, a adoção por clientes 
torna-se difícil, uma vez que envolve custos que po-
derão ser modificáveis e falta de controle preciso. 
Considera-se, desse modo, o modelo mais completo 
e demorado para se implantar, e suas quatro fases 
são descritas na Tabela 7:
Fases Descrição
Definição de objetivos
Contempla o desempe-
nho e as funcionalidades 
para alcançar os objetivos 
listados com um plano 
gerencial�
Análise de riscos
Analisa e avalia os riscos 
e as restrições� Os protóti-
pos são utilizados tanto no 
desenvolvimento quanto 
na análise de risco�
59
Fases Descrição
Desenvolvimento e validação
Valida-se o modelo 
apropriado para o desen-
volvimento do sistema, de 
acordo com os riscos da 
fase anterior�
Planejamento da próxima 
fase
Promove a revisão do 
projeto, ocorrendo as mo-
dificações necessárias nas 
próximas fases�
Tabela 7: Fases espiral. Fonte: Adaptado de Devmedia.
Há muito itens a serem tratados no modelo espiral, 
para tanto, precisamos entender que cada iteração 
tem diversos requisitos a se realizarem� O espiral 
deve ser entendido em sentido horário (Figura 13)�
Custo Acumulado
Progresso através das fases
Avalia alternativas, 
identifica e resolve 
riscos
Desenvolve e 
verificar o produto no 
nível seguinte
Análise de 
Riscos
Análise de 
Riscos
Análise de 
Riscos
Análise 
de 
Riscos
Ideia de 
Operação
Requisitos de 
Sofware Projeto do 
Produto 
Sofware
Projeto da 
Verificação e 
Validação
Teste de 
AceitaçãoImplementação
Plano de testes
Plano de Integração
Plano de 
Desenvolvimento
Plano de Requisitos
Plano do Ciclo de Vida
Planeja a 
próxima fase
Determina
Objetivos
Alternativas
Restrições
Comprometimento
partição
R
ev
is
ão
Teste de 
Integração
Teste de 
Unidade
Código
Projeto 
DetalhadoRequisitos de 
Validação
Protótipo 1Protótipo 2
Simulações, Modelos, “benchmarks”
Protótipo 3
Protótipo 
Operacional
Figura 13: Modelo espiral. Fonte: Devmedia.
60
https://www.devmedia.com.br/ciclos-de-vida-do-software/21099
https://www.devmedia.com.br/ciclos-de-vida-do-software/21099
CONSIDERAÇÕES FINAIS 
Neste módulo, abordamos o desenvolvimento de 
software distribuído que requer conhecimentos de 
arquitetura cliente-servidor� O conhecimento dos pa-
radigmas de linguagens de programação aplica-se na 
escolha da melhor tecnologia conforme a aplicação�
Além disso, estudamos como as normas e os mo-
delos são importantes no processo de desenvolvi-
mento de software� Nos processos de engenharia, o 
software passa por várias análises e escolhas para 
garantir a qualidade, que engloba os serviços pres-
tados pelos profissionais envolvidos nos projetos, 
como os engenheiros de softwares�
Portanto, é de suma importância entender tudo que 
envolva técnicas e ferramentas da engenharia de 
software para se ter um melhor conhecimento de 
projetos dos quais participamos�
 ● Metodologia em prototipação�
 ● Rapid Application Development (RAD)�
 ● Modelo espiral�
61
SÍNTESE
Paradigmas de Linguagem 
de Programação
1) Engenharia de software distribuído.
Aborda principalmente a arquitetura 
cliente-servidor:
• Servidor Web.
• Aplicações em redes.
2) Engenharia de software orientado a 
serviços.
Aborda arquitetura distribuída de alta 
complexibilidade e sistema distribuído:
• Web Services.
• Composição.
3) Engenharia de software: 
desenvolvimento profissional e ética.
Analisa o desenvolvimento e a prestaçãode serviços em acordo com as normas e 
as técnicas, visando à ética profissional:
• Padronização e qualidade.
• Prestação de serviços e código de 
ética.
4) Metodologias tradicionais de 
desenvolvimento de software.
Apresenta modelos clássicos para o 
desenvolvimento de software:
• Modelo cascata.
• Metodologia em prototipação.
• Rapid Application Development (RAD).
• Modelo espiral.
Referências 
Bibliográficas 
& Consultadas
CAMPOS, F� M� Quais são as reais características da 
qualidade da NBR-ISO/IEC-9126-1? Linhadecódigo: 
Gerência – qualidade e testes� Disponível em: http://
www.linhadecodigo.com.br/artigo/1444/quais-sao-
-as-reais-caracteristicas-da-qualidade-da-nbr-iso_iec-
9126-1.aspx� Acesso em: 10 ago� 2019� 
CASA DA CONSULTORIA� Modelo cascata: o que é e 
como funciona? (s� d�)� Disponível em: https://casa-
daconsultoria.com.br/modelo-cascata/� Acesso em: 
15 ago� 2019�
DEITEL, P�; Deitel, H�; Java: Como Programar� 10� 
ed� São Paulo, Pearson Education do Brasil, 2016 
[Biblioteca Virtual]�
EXIN� ISO; IEC 20000� Fundamentos ISO/IEC 
20000� PMG Education, versão português (Brasil), 
2010-2011�
GALDINO, A� K� Alemanha: saiba como validar 
diploma de engenharia e veja os salários, 8 ago� 
2016� Disponível em: https://engenhariae.com.br/
http://www.linhadecodigo.com.br/artigo/1444/quais-sao-as-reais-caracteristicas-da-qualidade-da-nbr-iso_iec-9126-1.aspx
http://www.linhadecodigo.com.br/artigo/1444/quais-sao-as-reais-caracteristicas-da-qualidade-da-nbr-iso_iec-9126-1.aspx
http://www.linhadecodigo.com.br/artigo/1444/quais-sao-as-reais-caracteristicas-da-qualidade-da-nbr-iso_iec-9126-1.aspx
http://www.linhadecodigo.com.br/artigo/1444/quais-sao-as-reais-caracteristicas-da-qualidade-da-nbr-iso_iec-9126-1.aspx
https://casadaconsultoria.com.br/modelo-cascata/
https://casadaconsultoria.com.br/modelo-cascata/
https://engenhariae.com.br/mercado/alemanha-saiba-como-validar-diploma-de-engenheiro-e-veja-os-salarios
mercado/alemanha-saiba-como-validar-diploma-de-
-engenheiro-e-veja-os-salarios � Acesso em: 20 ago� 
2019�
GUEDES, M� Você sabe o que é Arquitetura 
Orientada a Serviço (SOA)? 25 maio 2017� 
Disponível em: https://www.treinaweb.com.br/blog/
voce-sabe-o-que-e-arquitetura-orientada-a-servicos-
-soa/� Acesso em: 15 ago� 2019�
GOTTERBARN, D� How the new Software 
Engineering Code of Ethics affects you� Software, 
IEEE Software Engineering, v� 1, n� 16, p� 58-64, nov�/
dec� 1999�
GOTTERBARN, D�; MILLER, K�; ROGERSON, S� 
Computer society and ACM approve software engi-
neering code of ethics� Computer Society, v� 1, n� 32, 
p� 84-88, oct� 1999�
IBPI� ISO/IEC 15504� International Best Practice 
Institute� Disponível em: http://ibpi.org/wp-content/
uploads/2012/07/ISO-IEC- 15504_20120808_
DOWNLOAD2.pdf� Acessado em agosto de 2014�
LAHOZ, C�; ANNA, N� S� Os Padrões ISO/IEC 12207 e 
15504 e a Model agem de Processos da Qualidade 
de Software� Disponível em: http://mtc-m18.sid.inpe.
br/col/lac.inpe.br/worcap/2003/10.20.14.01/doc/
LahozWorkcap_versaofinal.pdf� Acesso em: 25 jul� 
2019� 
https://engenhariae.com.br/mercado/alemanha-saiba-como-validar-diploma-de-engenheiro-e-veja-os-salarios
https://engenhariae.com.br/mercado/alemanha-saiba-como-validar-diploma-de-engenheiro-e-veja-os-salarios
https://www.treinaweb.com.br/blog/voce-sabe-o-que-e-arquitetura-orientada-a-servicos-soa/
https://www.treinaweb.com.br/blog/voce-sabe-o-que-e-arquitetura-orientada-a-servicos-soa/
https://www.treinaweb.com.br/blog/voce-sabe-o-que-e-arquitetura-orientada-a-servicos-soa/
http://ibpi.org/wp-content/uploads/2012/07/ISO-IEC-%2015504_20120808_DOWNLOAD2.pdf
http://ibpi.org/wp-content/uploads/2012/07/ISO-IEC-%2015504_20120808_DOWNLOAD2.pdf
http://ibpi.org/wp-content/uploads/2012/07/ISO-IEC-%2015504_20120808_DOWNLOAD2.pdf
http://mtc-m18.sid.inpe.br/col/lac.inpe.br/worcap/2003/10.20.14.01/doc/LahozWorkcap_versaofinal.pdf
http://mtc-m18.sid.inpe.br/col/lac.inpe.br/worcap/2003/10.20.14.01/doc/LahozWorkcap_versaofinal.pdf
http://mtc-m18.sid.inpe.br/col/lac.inpe.br/worcap/2003/10.20.14.01/doc/LahozWorkcap_versaofinal.pdf
LINHARES, E� S�; OGAWA, F� M�; PIMENTEL, J�; 
SOUZA, M� M� Tópicos avançados comparativos 
entre os servidores web: Apache e IIS� Computação 
Aplicada, v� 3, n� 1�, 2014� p�35-39�
MANZANO, J� A� N� G� Algoritmos: lógica para de-
senvolvimento de programação de computadores� 
28� ed� São Paulo: Érica, 2016 [Biblioteca Virtual]�
MANZANO, J� A� N� G� Java 7: programação de com-
putadores: guia prático de introdução, orientação e 
desenvolvimento� São Paulo: Érica, 2011 [Biblioteca 
Virtual]�
MASIERO, P� C� Desenvolvimento de Software 
Baseado em Componentes� (s� d�)� Disponível 
em: https://edisciplinas.usp.br/pluginfile.
php/130351/mod_resource/content/1/DSBC_UML_
Components_1-2-3.pdf� Acesso em: 05 ago� 2019�
MELO, A� C� V�; SILVA, F� S� C� Princípios de 
Linguagem de Programação� São Paulo: Edgard 
Blücher LTDA, 2003 [Biblioteca Virtual]�
PACITTI, T� Paradigmas do software aberto� Rio de 
Janeiro: LTC, 2006 [Minha Biblioteca]
PAULA FILHO, W� P� Engenharia de software: funda-
mentos, métodos e padrões� 3� ed� São Paulo: Gen/
LTC, 2009 [Biblioteca Virtual]�
https://edisciplinas.usp.br/pluginfile.php/130351/mod_resource/content/1/DSBC_UML_Components_1-2-3.pdf
https://edisciplinas.usp.br/pluginfile.php/130351/mod_resource/content/1/DSBC_UML_Components_1-2-3.pdf
https://edisciplinas.usp.br/pluginfile.php/130351/mod_resource/content/1/DSBC_UML_Components_1-2-3.pdf
PAULK, M� C� Analyzing the Conceptual Relationship 
Between ISO/IEC 15504 (Software Process 
Assessment) and the Capability Maturity Model for 
Software� Software Engineering Institute, Carnegie 
Mellon University� Pittsburgh, PA, USA, 1999� 
PRESSMAN, R� S�; MAXIM, B� R� Engenharia de 
Software: uma abordagem profissional. 8. ed. Porto 
Alegre: McGraw-Hill, 2016 [Biblioteca Virtual]�
RABELLO, R� B�; NUNES, J� B�; BARBALHO, R� A�; 
VON WANGENHEIM, C� G� Integração de engenha-
ria de usabilidade em um modelo de capacidade/
maturidade de processo de software� Florianópolis, 
Universidade Federal de Santa Catarina, 2012� 
Disponível em: http://www.gqs.ufsc.br/wp-content/
uploads/2012/11/draftIHC2012_Integracao_EU_
MCMPS.pdf� Acesso em: 15 ago� 2019�
RINCON, A� M� Qualidade de Software� Instituto de 
Informática/Universidade Federal de Goiás (UFG)� 
ENCOINFO, Anais, Curso Superior de Tecnologia em 
Análise e Desenvolvimento de Sistemas/Fundação 
Universidade do Tocantins (Unitins), 2009�
SALÁRIO� Engenharia de software computacional 
básico� Disponível em: https://www.salario.com.br/
profissao/engenheiro-de-software-computacional-
-basico-cbo-212215/� Acesso em: 20 ago� 2019�
SASABE, S� ASQ: Quality Assurance� World congress 
for software quality, San Francisco, CA, v� 1, n� 0, jun� 
http://www.gqs.ufsc.br/wp-content/uploads/2012/11/draftIHC2012_Integracao_EU_MCMPS.pdf
http://www.gqs.ufsc.br/wp-content/uploads/2012/11/draftIHC2012_Integracao_EU_MCMPS.pdf
http://www.gqs.ufsc.br/wp-content/uploads/2012/11/draftIHC2012_Integracao_EU_MCMPS.pdf
https://www.salario.com.br/profissao/engenheiro-de-software-computacional-basico-cbo-212215/
https://www.salario.com.br/profissao/engenheiro-de-software-computacional-basico-cbo-212215/
https://www.salario.com.br/profissao/engenheiro-de-software-computacional-basico-cbo-212215/
20-22, 1995� p� 1-9� Disponível em: http://asq.org/
qic/display-item/?item=10928� Acesso em: 12 ago� 
2019�
SBROCCO, J� H� T� C�; MACEDO, P� C� Metodologias 
ágeis: engenharia de software sob medida� São 
Paulo: Érica, 2012 [Biblioteca Virtual]�
SGANDERLA� K� Qual a principal diferença entre 
BPM e BPEL? 27 maio 2013� In: i Process Soluções 
em Tecnologia� Disponível em: http://blog.iprocess.
com.br/2013/05/qual-a-principal-diferenca-entre-
-bpm-e-bpel/� Acesso em: 20 ago� 2019�
SARMENTO, L� Breve introdução ao RMI – Remote 
Method Invocation, 2003� Disponível em: https://
web.fe.up.pt/~eol/AIAD/aulas/JINIdocs/rmi1.html� 
Acesso em: 15 ago� 2019�
SILVA, J� A� L� História da ISO� 07 mar� 2013� 
Disponível em:http://www.ciriusquality.com.br/in-
dex.php/artigos-noticias/23-iso-9001/54-historia-da-
-iso� Acesso em: 20 ago� 2019�
SOUZA, M� A� F�; GOMES, M� M�; SOARES, M� V�; 
CONCILIO, R� Algoritmos e lógica de programação� 
3� ed� Cengage, 2019 [Biblioteca Virtual]�
TOMCAT� Apache Tomcat (2016)� Disponível em: 
https://tomcat.apache.org/download-80.cgi� Acesso 
em: 20 ago� 2019�
http://asq.org/qic/display-item/?item=10928
http://asq.org/qic/display-item/?item=10928
http://blog.iprocess.com.br/2013/05/qual-a-principal-diferenca-entre-bpm-e-bpel
http://blog.iprocess.com.br/2013/05/qual-a-principal-diferenca-entre-bpm-e-bpel
http://blog.iprocess.com.br/2013/05/qual-a-principal-diferenca-entre-bpm-e-bpel
https://web.fe.up.pt/~eol/AIAD/aulas/JINIdocs/rmi1.html
https://web.fe.up.pt/~eol/AIAD/aulas/JINIdocs/rmi1.html
http://www.ciriusquality.com.br/index.php/artigos-noticias/23-iso-9001/54-historia-da-iso
http://www.ciriusquality.com.br/index.php/artigos-noticias/23-iso-9001/54-historia-da-iso
http://www.ciriusquality.com.br/index.php/artigos-noticias/23-iso-9001/54-historia-da-iso
https://tomcat.apache.org/download-80.cgi
	_Hlk17660324
	_GoBack
	_Hlk15778509
	_Hlk17571486
	_Hlk17669232
	_Hlk17664828
	_Hlk17665033
	_Hlk17665186
	_Hlk17665473
	Introdução
	Engenharia de Software Distribuído
	Remote Method Invocation
	Servidor web
	Entendendo a arquitetura do TOMCAT
	Engenharia de Software Orientado a Serviços
	Web Services
	Engenharia de Software: desenvolvimento profissional e ética
	Profissional de Engenharia de Software
	Principais áreas da Engenharia de Software: Gerenciamento de configuração de software
	Ferramentas e métodos
	Projeto e desenho (Design):
	Qualidade de software
	Teste de Software 
	Normas ISO com foco na qualidade de software
	NBR ISO/IEC 9126-1 qualidade do produto de software
	NBR ISO/IEC 15504 processos de software em níveis de maturidade - qualidade
	Ética na Engenharia de Software
	NBR/ISO 20000 gestão de serviços na área de Tecnologia da Informação
	Metodologias tradicionais de desenvolvimento de software
	Modelo Cascata
	Modelo Incremental
	Metodologia em prototipação
	Rapid Application Development
	Modelo Espiral
	Considerações finais 
	Síntese