E-book 2 - Paradídmas de Linguagens de Programação

Prévia do material em texto

PARADIGMAS DE 
LINGUAGENS DE 
PROGRAMAÇÃO
E-book 2
Bruno Zolotareff dos Santos
Neste E-Book:
INTRODUÇÃO ����������������������������������������������4
PROGRAMAÇÃO IMPERATIVA ��������������� 5
TIPOS COMPOSTOS ����������������������������������10
PROGRAMAÇÃO ORIENTADA A 
OBJETOS �������������������������������������������������������11
PROGRAMAÇÃO FUNCIONAL �������������� 14
PROGRAMAÇÃO IMPERATIVA VS 
PROGRAMAÇÃO DECLARATIVA ����������16
PROGRAMAÇÃO LÓGICA ������������������������17
PROGRAMAÇÃO ORIENTADA A 
EVENTOS ������������������������������������������������������18
PROGRAMAÇÃO CONCORRENTE �������20
GERENCIAMENTO DE PROJETOS 
DE SOFTWARE �������������������������������������������21
PROCESSOS DE PROJETOS ������������������ 25
PROCESSO DE GERÊNCIA DE 
PROJETOS ���������������������������������������������������26
ÁREAS DE CONHECIMENTO DO 
PMBOK ���������������������������������������������������������28
2
MÉTODO DE MELHORIA CONTÍNUA 
PDCA ������������������������������������������������������������29
PROJETO DE SOFTWARE E 
QUALIDADE ASSEGURADA ������������������ 33
DESENVOLVIMENTO DE 
SOFTWARE BASEADO EM 
COMPONENTES ����������������������������������������36
INTERFACES DE COMPONENTES �������38
ABSTRAÇÃO DE COMPONENTES ������ 40
MODELOS GENÉRICO DE 
PROCESSO DE SOFTWARE 
BASEADO EM COMPONENTES �������������41
IMPACTO DAS LINGUAGENS DE 
PROGRAMAÇÃO NA ENGENHARIA 
DE SOFTWARE ������������������������������������������47
CICLO DE VIDA �������������������������������������������51
FLUXO DE TRABALHO ��������������������������� 53
GESTÃO DE PROJETOS���������������������������56
CONSIDERAÇÕES FINAIS ����������������������59
SÍNTESE �������������������������������������������������������60
3
INTRODUÇÃO
Desde o início, a programação tem passado por vá-
rias modificações e adaptações de acordo com as 
necessidades industriais, comerciais e científicas.
A evolução das linguagens gerou uma vasta esco-
lha de linguagens a serem utilizadas em projetos 
de software. Entretanto, com o avanço da tecnolo-
gia na área de linguagens de programação, muitos 
problemas de projetos têm aparecido em relação 
ao software.
Os projetos de software começaram a exigir um alto 
nível de qualidade, assim, padrões de software e me-
todologias foram surgindo baseados em melhoria 
contínua. Nesse sentido, a engenharia de software 
surgiu dada a preocupação com a qualidade do sof-
tware e a padronização dos modelos e processos 
de desenvolvimento. Com isso, melhoraram-se as 
técnicas de programação e o entendimento dos pa-
radigmas em aplicações de acordo com os objetivos.
Neste módulo, estudaremos conceitos de aplica-
ções com paradigmas de programação, proje-
tos de software e o ciclo de vida no processo de 
desenvolvimento.
4
PROGRAMAÇÃO 
IMPERATIVA
Em todas as linguagens de programação imperativas, um 
programa é entendido como uma sequência linear de 
instruções que o computador processa na sequência de-
finida. O microcódigo especifica, no nível do processador, 
como o computador deve lidar com quais dados. Dessa 
forma, os comandos são usados para esse propósito, ou 
seja, para manipular o estado das áreas de memória que 
contêm dados para processamento ou saída. 
Esses dados geralmente são armazenados em variáveis 
para que possam mudar na sequência do programa. A 
ordem dos comandos determina a sequência de tempo 
no programa. Para implementar programas responsivos, 
há instruções de salto que alteram dinamicamente a 
sequência de instruções ordenada uma vez.
De acordo com o paradigma imperativo, uma solução é 
dada: Quais passos individuais devem ser tomados um 
após o outro? Como as variáveis devem ser alteradas de 
modo que o resultado desejado saia no final?
Em primeiro plano está a pergunta “como?” Programas 
imperativos são sequências ramificadas de instruções, 
as quais contêm atribuições que, quando executadas, 
alteram valores de variáveis e, portanto, o estado do 
programa.
Os ramos no programa são decididos por condições 
através de variáveis. As funções parametrizadas são 
5
usadas para abstrair os cálculos e chamá-los em di-
ferentes pontos do programa. Por exemplo, considere 
uma função que resume os elementos de uma lista. 
Está escrito na linguagem C:
int ListSum (IntList l) {
  int sum = 0;
  while (l != NULL)
   { sum = sum + l->val; l = l->next; }
  return sum;
}
Aqui, uma lista é representada por uma referência a um 
par de valores: um val inteiro e uma referência à lista 
restante. 
As atribuições no corpo do loop while adicionam o 
número val do elemento list de l à soma da variável e 
definem l para o próximo elemento. Essas instruções 
são iteradas desde que eu não aponte para a lista vazia. 
Em seguida, o valor da soma variável é retornado como 
resultado da chamada da função.
O paradigma imperativo também é baseado na formu-
lação clássica de algoritmos que especificam sequên-
cias ramificadas de etapas que executam cálculos 
e atribuições a variáveis.
O princípio estrutural abstrato da calculadora de von 
Neumann também corresponde ao paradigma im-
perativo: um processador executa uma sequência 
6
ramificada de instruções que alteram os dados na 
memória.
A programação imperativa possui três aspectos ele-
mentares: tipos, variáveis e valores. Esses elementos 
interagem com a composição do paradigma impera-
tivo de programação. Visando a entendê-los melhor, 
vamos analisar o que cada um deles significa:
 ● Tipos: As regras de classificação das informações 
são agrupadas conforme seu tipo, e o tratamento 
das informações se dá de maneira categorizada de 
acordo com o domínio, senão haveria grandes dificul-
dades para tratar as informações fora do escopo. Se 
não fosse esse tipo de agrupamento, cada informa-
ção teria de ser tratada individualmente. Assim, os 
tipos podem ser três: primitivo, composto e recursivo.
 ● Variáveis: Os atributos são definidos dentro do 
escopo para a manipulação das informações, conhe-
cidas como variáveis de programação; elas definem 
um valor temporário alocado na memória do compu-
tador. Há diferentes tipos de variáveis dependendo 
da linguagem escolhida.
 ● Valores: Os valores das variáveis são atribuídos 
segundo o tipo declarado no escopo da linguagem 
de programação, as informações podem ser, por 
exemplo, nome de objetos, data de aniversário, peso 
de algo etc.
Um conceito na programação de tipos
Conforme abordado anteriormente, há tipos na pro-
gramação imperativa, que são analisados a seguir:
7
 ● Tipo Primitivo: É conhecido como atômico, sem 
subdivisão, possibilitando que cada linguagem de 
programação possa tratar os conceitos de seus do-
mínios diferentemente, pois há arquitetura e supor-
te para aplicações com objetivos diferenciados. A 
maioria utiliza em seus atributos os tipos declarados 
como boolean, int ou integer, real, char e enum.
Existem linguagens cujos objetivos são voltados à 
área científica, como Fortran e C; ao passo que ou-
tras são criadas para fins comerciais, como o Cobol. 
Salientamos, porém, que uma linguagem científica 
não é utilizada apenas em experimentos com fins 
acadêmicos, a aplicação comercial também utiliza 
essas linguagens de programação.
Saiba mais
Saiba mais sobre linguagens como o Fortran têm 
sido utilizadas na programação em foguetes, ao 
ler Desenvolvimento de um microfoguete para 
fotografias aéreas de pequeno formato (LOURE-
DA, 2006), disponível em: http://www.bibl.ita.br/
xiiencita/mec_09.pdf. Acesso em: 03 ago. 2019.
Esse tipo de linguagem é utilizado principalmente 
em aplicações matemáticas com tipos numéricos de 
precisão, como o Fortran. Tais linguagens trabalham 
basicamente com os tipos: inteiro e ponto flutuante.
Não numéricos: Conhecidos principalmente no uso 
de estado verdadeiro ou falso, 0 e 1 (Boolean). 
8
http://www.bibl.ita.br/xiiencita/mec_09.pdf
http://www.bibl.ita.br/xiiencita/mec_09.pdf
Caracteres com agrupamentos também são supor-
tados, por exemplo ‘A’, ’U’, ‘a’...’u’. Além disso, utiliza-
-se um sistemade gerenciamento das informações 
das variáveis.
 ● Alocação dinâmica: Os dados não precisam ser 
declarados sequencialmente no espaço da memó-
ria, visto que a alocação ou desolação de blocos de 
memória pode ser feita automaticamente durante a 
execução. Nesse caso, não é preciso inserir infor-
mações de modo ordenado. A C é um exemplo de 
linguagem que utiliza esse tipo de alocação.
 ● Enumeração: Este tipo oferece uma forma de agru-
pamento de informações, sendo conhecido como 
constante de enumeração. Segue um exemplo em 
Java:
Class enum dias {Dom, Seg, Terç, Qua, Qui, Sex, 
Sab;}
9
TIPOS COMPOSTOS
É uma composição de diferentes tipos, primitivos ou 
não. Para entender melhor o procedimento deste tipo, 
vamos colocar um exemplo em C dessa composição:
enum QuantidadeProduto { 1,2,3,4,5,6,7,8,9,10}
enum CaixasProduto{caixa1, caixa2, caixa3, cai-
xa4, caixa5}
struct DadosP{
 QuantidadeProduto q;
 CaixasProduto p
}
10
PROGRAMAÇÃO 
ORIENTADA A 
OBJETOS
A programação orientada a objetos é um paradigma 
desenvolvido com o princípio de trocar informações 
entre objetos. Teve início com a linguagem Simula 
67, que mais tarde foi aperfeiçoada com o Smalltalk, 
considerada por muitos uma linguagem puramente 
orientada a objetos.
Com o mesmo conceito, a linguagem C++ possui os 
elementos da orientação a objetos, mas não é uma 
linguagem puramente orientada a objetos. Trata-se 
de uma linguagem híbrida, com a qual é possível 
utilizar diferentes paradigmas.
Entretanto, a programação orientada a objetos ficou 
mais conhecida com a linguagem Java por muitos 
motivos, especialmente sua portabilidade, escalabi-
lidade e uso em aplicativo móveis e na Web.
A programação orientada a objetos tem alguns pila-
res: herança, polimorfismo, encapsulamento e abstra-
ção. Praticamente, são utilizados classes e métodos 
com essa programação, a saber:
 ● Herança: considerada a propriedade mais impor-
tante da programação orientada a objeto, a herança 
funciona como uma hierarquia das classes, ou seja, 
11
uma classe herda as propriedades de outra, aumen-
tando assim a reutilização de código.
 ● Polimorfismo: é uma classe que pode ter mais que 
uma característica, por exemplo, uma classe com 
o nome anfíbio herda as características de outras 
classes, como carro e barco. Possui a herança das 
propriedades.
Podcast 1 
 ● Encapsulamento: os atributos privados ou pro-
tegidos são acessados com os getters e setters, 
protegendo o estado das variáveis, em que o en-
capsulamento é feito na construção do objeto ou 
instância da classe.
 ● Abstração: utilizada como uma classe genérica, 
é conhecida como uma superclasse ou classe abs-
trata herdada por classes concretas. Utiliza-se para 
definição de entidades do mundo real.
As classes em POO têm atributos, métodos e heran-
ça. Recomenda-se que a herança seja feita por uma 
classe abstrata, como demonstrado na Tabela 1:
12
https://famonline.instructure.com/files/142261/download?download_frd=1
Classe Abstrata Classe Concreta Classe Principal
public abstract 
class Auto {
private String 
marca;
private int ano;
public void setMar-
ca(String marca){
this.marca = marca;
}
public String get-
Marca(){
 return marca;
}
public void setA-
no(int ano){
this.ano = ano;
}public int getA-
no(){
 return ano;
}
public class 
Carro extens 
Auto {
public void car-
ro(){
this.
setMarca(“VW”);
this.
setAno(2019);
System.out.printl-
n(“O carro é um: “ 
+ this.getMarca() 
+ “\n O ano do 
carro é: ” + this.
getAno();
}
}
public class 
Principal{
public static void 
main(String[] 
args){
Carro car = new 
Carro();
car.carro();
}
}
Tabela 1: Classe abstrata, concreta e principal. Fonte: Elaboração 
própria.
13
PROGRAMAÇÃO 
FUNCIONAL
Conhecida como um tipo de programação que utiliza 
funções matemáticas sem mudança de estado ou 
imutabilidade, a programação funcional é utilizada 
principalmente para multiprocessamento e aplica-
ções matemáticas recursivas. Sua programação re-
aliza-se com funções que chamam outras funções, 
conhecidas também como funções de alta ordem. 
Na tabela 2, temos alguns dos princípios desse tipo 
de programação:
Programação 
Imperativa
versus
Declarativa
São dois paradigmas de 
programação 
Mutable state São funções que dificilmente 
modificam seus valores, utili-
zam funções matemáticas e 
recursividade.
Funções como first-
-class values
São classes que podem ser 
utilizadas para manipular valo-
res, possuem uma estrutura de 
dados apontada a funções.
Higher-order functions É uma função que recebe outra 
função como argumento, tra-
duzida como função de ordem 
maior.
Side-effect-Free 
functions
É um tipo de função que retorna 
os mesmos valores de entrada.
14
Lambdas e Closures São semelhantes a classes 
internas anônimas que podem 
ou não retornar valores. 
Recursividade É uma função que chama a si 
mesmo repetidamente, até a 
condição de parada.
Lazy vs Eager Evalution O valor do cálculo já é conhe-
cido antes de fazer alguma 
requisição.
Gluing functions É um encadeamento de funções.
Tabela 2: Princípios da programação funcional. Fonte: Elaboração 
própria.
Apesar de haver várias linguagens de programação 
funcionais (Ruby, Lisp, Scala etc.), isso não quer dizer 
que uma única linguagem tenha todos os princípios 
mencionados anteriormente. A programação fun-
cional, mesmo sendo um conceito antigo, é cada 
vez mais utilizada em empresas com linguagens 
como Scala, Google Guava e versões mais recente 
do Java 8.
15
PROGRAMAÇÃO IMPERATIVA 
VS PROGRAMAÇÃO 
DECLARATIVA
São dois os paradigmas da programação. Na impe-
rativa, declaramos os passos para o compilador que 
desejamos que sejam executados; já na declarativa, 
colocamos comportamentos e regras (Tabela 3):
Programação imperativa Programação declarativa
for(int i=0;i<30;++i){
if(i % 2 ==0){
System.out.println(i + “é 
ainda”);
}
}
UnaryPredicate<Integer> 
isEven = new 
UnaryPredicate<Integer>() {
 public boolean test(Integer 
number) {
 return number % 2 == 0;
 } };
IntegerRange zeroToTen = new 
IntegerRange(0, 11);
for(Integer number : zeroToTen.
toCollection()) {
 if ( isEven.test(number) ) {
 System.out.println(number + “ 
is even”);
 } }
Tabela 3: Programação imperativa e Programação declarativa.Fonte: 
Elaboração própria.
A programação funcional é declarativa, pois não há 
muitas mudanças na criação das funções. Quando 
se altera algo, isso é feito com aplicação de recur-
sividade. Entretanto, não há preocupação de alterar 
os valores internamente, ou seja, o termo mutable 
data se refere à estabilidade dos dados internos da 
função.
16
PROGRAMAÇÃO 
LÓGICA
A programação lógica é um tipo de linguagem volta-
do à lógica matemática. A primeira desse tipo foi o 
Planner, que é uma linguagem orientada a padrões 
voltados aos objetivos, além de ser bastante utili-
zada para o uso da Inteligência Artificial.
Desde o Planner, houve uma evolução de lingua-
gens, entre as quais estão QA-4, QLISP, Mercury, 
Visual Prolog, Oz e Fill.
Para entender o funcionamento de uma linguagem 
lógica, analise a Figura 1, na qual se pode observar o 
funcionamento das regras de acordo com a lógica:
Figura 1: Exemplo de uso de programação lógica. Fonte: Adaptada 
de Álvares (s. d.).
17
PROGRAMAÇÃO 
ORIENTADA A 
EVENTOS
Há pouco, estudamos que o modelo imperativo deter-
mina a ordem de entrada dos dados. Diferentemente, 
as programações orientadas a eventos não contro-
lam a sequência dos eventos de entrada, bem como 
são direcionadas a reagir a qualquer sequência ra-
zoável de eventos.
Esse tipo de paradigma utiliza laços de repetição de 
eventos, que recebem repetidamente a informação 
no processamento em que é disparada a resposta 
de acordo com o evento. O que determina a entrada 
são os eventos que envolve as funções. A seguir, 
temos alguns exemplos relacionados a eventos em 
programação:
 ● Clicar em botão com o mouse.
 ● Escolher uma opção no menu.
 ● Escrever em uma caixa de texto.
 ● Movimento de mouse.
Na programação em Java, os tipos de eventosão 
definidos pelas subclasses da classe java.Awt.Event. 
Esses eventos são detectados pela classe que im-
plementam a interface Listener (ouvinte), e para 
responder aos eventos sobre os métodos Handlers 
(manipuladores).
18
Os Handlers são implementados no Java dentro das 
classes Listeners, como na Figura 2:
Figura 2: Exemplo de evento no Java.Fonte: Adaptada de Cáceres 
(s. d., p. 8).
19
PROGRAMAÇÃO 
CONCORRENTE
A programação concorrente é um tipo de paradigma da 
programação que realiza a execução concorrente, ou 
seja, de maneira simultânea. A programação paralela 
ou multithreading está associada à linha de execução 
na mesma função.
Em Java, o thread é utilizado com o pacote java.lang. 
Na sequência, estudaremos um código em Java com 
threads para gerar PDF e barra de progresso. O exemplo 
é uma representação da compilação de threading, visto 
que, na implementação, a intenção é gerar um arquivo 
PDF e uma barra de progresso (Tabela 4):
Classe e métodos Implementação
public class GeraPDF imple-
ments Runnable
 {
 public void rodar () {
 // lógica para gerar o 
pdf...
 }
}
public class BarraDeProgresso 
implements Runnable {
 public void rodar () {
 // mostra barra de pro-
gresso e vai atualizando ela...
 }
}
public class MeuPrograma {
 public static void main (String[] 
args) {
 GeraPDF gerapdf = new 
GeraPDF();
 Thread threadDoPdf = new 
Thread(gerapdf);
 threadDoPdf.start();
 BarraDeProgresso 
barraDeProgresso = new 
BarraDeProgresso();
 Thread threadDaBarra = new 
Thread(barraDeProgresso);
 threadDaBarra.start();
 }
}
Tabela 4: Exemplo do uso de threading.Fonte: Adaptada de Caelum 
(s. d.).
20
GERENCIAMENTO 
DE PROJETOS DE 
SOFTWARE
Um projeto é um empreendimento com caracterís-
ticas próprias que tem princípio e fim; é conduzido 
por pessoas e visa a atingir as metas estabelecidas 
dentro dos parâmetros de prazo, custo e qualidade 
(PMBOK, 2017). Trata-se de um empreendimento 
temporário, ou seja, um projeto que tem um ponto 
definido de início e fim, cujo objetivo é criar um pro-
duto ou serviço distinto e único no sentido de que o 
produto do projeto possa se diferenciar de outros.
Gerenciar consiste em “executar atividades e tarefas 
que têm como propósito planejar e controlar ativi-
dades de outras pessoas para atingir objetivos que 
não podem ser alcançados caso as pessoas atuem 
por conta própria” (KOONTZ; O´DONNEL; WEINRICH, 
2002).
A gerência é um dos aspectos mais crítico em pro-
jetos, pois sua ausência demonstra resultados não 
favoráveis para nenhuma organização que esteja 
executando ou planejando um projeto. A aplicação de 
conhecimentos, habilidades, ferramentas e técnicas 
em projetos visa a atingir ou até mesmo exceder às 
necessidades e expectativas dos clientes e demais 
partes interessadas do projeto (PMBOK, 2017).
A gerência de projetos envolve muitas decisões:
21
 ● Escopo, tempo, custo e qualidade.
 ● Diferentes necessidades e expectativas dos clien-
tes e partes interessadas.
 ● Requisitos identificados (necessidades) e não iden-
tificados (expectativas).
Em geral, os projetos são gerenciados a partir de 
metodologias já utilizadas pelas empresas; não 
há um único modo de gerenciar, e sim melhores 
caminhos a seguir baseados em projetos anteriores. 
Sendo assim, os projetos de software possuem uma par-
ticularidade: o primeiro passo para entender é que, mui-
tas vezes, os projetos de software são caros e, às vezes, 
envolvem riscos às pessoas.
É muito grande o risco de projetos de software darem 
errado, por esse motivo alguns guias e metodologias fo-
ram criados com a finalidade de ajudarem esse processo 
de desenvolvimento de software.
Um dos principais guias de gerenciamento de projeto 
é o Project Management Body of Knowledge (PMBOK), 
ou Corpo de conhecimento em Gerência de Projetos. 
Trata-se de um padrão internacional reconhecido pelas 
instituições IEEE e ANSI.
A primeira versão do PMBOK foi publicada pelo Project 
Management Institute (PMI), ou Instituto de Gerência de 
Projeto, em 1987. Fundado em 1969, o PMI tinha como 
objetivo identificar as práticas de gerência em projetos.
Apesar de esta disciplina não ser voltada ao 
Gerenciamento de Projetos, deve-se considerar o 
22
desenvolvimento de softwares um projeto como ou-
tro qualquer, mas com detalhes de engenharia que 
utilizam muitas normas, técnicas e metodologias.
O PMBOK, para muitos, é o principal guia de projetos, 
por isso estudaremos mais sobre ele, abordando os 
sus detalhes e técnicas. Para projetos de software, 
foram lançadas algumas metodologias, que conhe-
ceremos em breve.
Para auxiliar esse processo de software, metodologias 
foram construídas. Nos Estados Unidos da América, foi 
elaborado o Capability Maturity Model (CMM), e depois 
modelos mais atualizados, como o People-CMM e o 
Capability Maturity Model Integration (CMMI).
Na Europa, há um modelo semelhante ao CMMI dos 
Estados Unidos da América. O modelo é reconhecido 
como uma norma ISO/IEC 12207 e evoluiu para o ISO/
IEC 15504. Além desses métodos e normas, há outros 
que são utilizados em Projetos de Software.
O CMMI foi elaborado principalmente pelas forças arma-
das dos Estados Unidos junto com a National Aeronautics 
and Space Administration (Nasa). Na atualidade, muitos 
se preocupam com a Qualidade de Software para os pro-
jetos. Tal preocupação surge principalmente com o ad-
vento da internet, pois a área de Qualidade Assegurada 
é uma das mais importantes em Projetos de Software.
Certamente, você já deve ter ouvido falar da área da 
qualidade e, no tocante a softwares, não é diferente. 
Conhecida como Quality Assurance (QA), ou Qualidade 
23
Assegurada, é algo de grande importância para projetos 
internacionais.
No Brasil, a Qualidade de Software é utilizada sobretudo 
em Projetos de Software de grande porte, de âmbito 
internacional com inúmeras exigências. Provavelmente, 
você já ouviu falar de testes de Software, uma vez que 
essa área faz parte da Qualidade Assegurada.
Aqui, uma norma que está sendo muito recomendada é 
a ISO/IEC 27000, referente à segurança da informação. É 
uma norma que ainda está em construção. Não se preo-
cupe, há diversas normas e métodos para você conhecer 
e aplicar em Projetos de Software. Há um guia especial 
para ser utilizado em software, o Software Engineering 
Body of Knowledge (SWEBOK), ou Corpo de conhecimento 
em engenharia de software.
Você conhecerá um pouco sobre tais serviços voltados 
à tecnologia da informação, conhecida como ITIL e ISO/
IEC 2000.
Há uma família de ISOs para se abordar,mas estudaremos 
as mais utilizadas em Projetos de Software. Você deve ter 
percebido que a Engenharia de Software está envolvida 
em todo o projeto que envolva software.
Agora, você verá que os projetos de software e mode-
los adotados surgiram dos primeiros modelos citados 
no PMBOK. Por isso, abordaremos como os primeiros 
modelos foram elaborados.
Podcast 2 
24
https://famonline.instructure.com/files/142264/download?download_frd=1
PROCESSOS DE 
PROJETOS
Segundo o Project Management Body of Knowledge 
(PMBOK, 2017), um processo é uma série de ações 
que geram resultados. Os processos dos projetos são 
realizados por pessoas e normalmente se enquadram 
em duas categorias:
 ● Processos Orientados ao Produto, especificação 
e criação dos produtos do projeto.
 ● Processos da Gerência de Projeto, que relatam 
a descrição, a organização e o trabalho do projeto.
25
PROCESSO DE 
GERÊNCIA DE 
PROJETOS
O processo de gerência de projetos é semelhante 
ao Plan, Do, Check, Act (PDCA), ou Planejar, Fazer, 
Checar e Agir, que segue o mesmo conceito de con-
tinuidade e fases baseado no ciclo. Na Tabela 5, ob-
servamos o funcionamento do processo de gerência 
de projetos do PMBOK.
SAIBA MAIS
Saiba mais sobre o Ciclo PDCA, visitando ht-
tps://www.siteware.com.br/metodologias/
como-fazer-pdca-passo-a-passo/. 
 Processos da Gerência de Projetos
Processo de 
InicializaçãoReconhecer que um projeto 
ou uma fase deve começar 
e se comprometer com sua 
execução.
Processo de 
Planejamento
Planejar e manter um esquema 
de trabalho viável para atingir 
aqueles objetivos de negócio 
que determinaram a existência 
do projeto.
26
https://www.siteware.com.br/metodologias/como-fazer-pdca-passo-a-passo/
https://www.siteware.com.br/metodologias/como-fazer-pdca-passo-a-passo/
https://www.siteware.com.br/metodologias/como-fazer-pdca-passo-a-passo/
 Processos da Gerência de Projetos
Processo de Execução Coordenar pessoas e outros 
recursos para realizar o que foi 
planejado.
Processo de Controle Assegurar que os objetivos do 
projeto estão sendo atingidos, 
através da monitoração e da 
avaliação do seu progresso, 
tomando ações corretivas 
quando necessárias.
Processo de Finalização Formalizar a aceitação do 
projeto ou a fase e fazer o 
seu encerramento de forma 
organizada.
Tabela 5: Cinco fases do processo de gerência do projeto. Fonte: 
PMBOK (2017).
27
ÁREAS DE 
CONHECIMENTO DO 
PMBOK
O manual do instituto PMI é organizado em áreas de co-
nhecimento, o PMBOK (2017) descreve cada uma dessas 
áreas através de processos, pois as áreas de conhecimen-
to se referem a um aspecto a ser considerado dentro da 
gerência de projetos, em geral dividida em uma maneira 
clara de entender.
O PMBOK é dividido em dez áreas de conhecimento e, 
no final do manual, há um glossário que descreve a 
função citada nos capítulos abordados (Tabela 6).
Áreas de Conhecimento do PMBOK
Qualidade Recursos 
Humanos
Escopo
Partes 
Interessadas
Aquisições Integração Comunicações
Custo Riscos Tempo
Tabela 6: As dez áreas do conhecimento. Fonte: Adaptada de PMBOK 
(2017).
28
MÉTODO DE 
MELHORIA 
CONTÍNUA PDCA
O método de melhoria contínua conhecido como Plan, 
Do, Check, Act, ou simplesmente PDCA, é utilizado por 
muitas corporações em todo o mundo. Assim, o método 
é muito útil em diversas áreas e tem sido adaptado 
de acordo com a necessidade da aplicação no desenvol-
vimento de algum projeto.
O conceito do método de melhorias PDCA foi original-
mente desenvolvido na década de 1930 pelo cientista 
norte-americano Walter A. Shewhart e aperfeiçoado por 
William Edwards Deming para o ciclo PDCA de controle 
estatístico do processo, que pode ser repetido continua-
mente sobre qualquer processo ou problema.
As etapas do ciclo PDCA são interligadas com a finalidade 
de obter melhores resultados. Dessa forma, o planeja-
mento tem controle de outras etapas do processo do 
ciclo de melhoria contínua (SOUZA; GOMES; SOARES; 
CONCILIO, 2019). No PMBOK, pode-se verificar o ciclo 
do PDCA adaptado em cinco fases nos processos 
em projetos (Figura 3):
29
ETAPAS DO CLICO
Processos de 
Iniciação
Processos de 
Planejamento
Processos de 
Execução
Processos de 
Controle
Processos de 
Encerramento
P
A
D
C
A
Act
C
Check
P
Plan
D
Do
Figura 3: Etapas do ciclo de vida de processo. Fonte: PMBOK (2017).
No Manual de Qualidade Assegurada de Software, 
(SCHULMEYER, 2007, p. 70-73), relata-se que um 
paço importante é a utilização do ciclo PDCA em 
projetos de software. Weinstein e Vasovski (2004) 
definem cada etapa do ciclo PDCA baseados no mo-
delo de Deming:
Módulo Plan (Planejar):
 ● Plan – Identificação dos problemas: 
 � Identificar os problemas a serem examinados.
 � Identificar um problema específico para entendê-
-lo melhor.
 � Definir as metas mensuráveis e realizáveis.
30
 � Identificar os interessados e desenvolver canais 
de comunicação.
 ● Plan – Análise de problemas:
 � Dividir o sistema global em processos individuais 
no mapa do processo.
 � Reunir potenciais pela causa do problema.
 � Coletar dados e identificar a raiz do problema.
 � Formular hipóteses.
 � Confirmar e rever o problema principal 
identificado.
Módulo Do (Executar):
 ● Do – Desenvolver / Implementar soluções:
 � Estabelecer critérios de sucesso experimentais.
 � Delineamento experimental para testar hipóteses.
 � Obter a aprovação das partes interessadas e o 
apoio para a solução escolhida.
 � Implementar experimento / solução em uma base 
experimental ou piloto.
Módulo Check (Verificar): 
 ● Check – Avaliar os resultados:
 ● Reunir / analisar dados sobre a solução.
 ● Validar a hipótese.
 ● Check – Atingir o objetivo pretendido:
 ● Se SIM, ir para agir.
31
 ● Se não, ir para planejar, hipótese revise / declaração 
do problema.
Módulo Act (Atuar):
 ● Act – Implementar a solução de escala completa 
(e aproveitar as novas oportunidades):
 � Identificar as mudanças sistêmicas e necessida-
des de formação para a plena aplicação.
 � Planejar o monitoramento contínuo da solução 
melhoria contínuo.
 � Procurar outras oportunidades de melhoria.
32
PROJETO DE SOFTWARE 
E QUALIDADE 
ASSEGURADA
Ao desenvolver projetos, a segurança faz parte da 
qualidade do software, o que envolve fazer testes 
e o ciclo de vida. O PDCA faz parte do processo de 
maturidade na elaboração de software.
A segurança do software em relação à sua qualidade 
está ligada a cada nível de maturidade descrito em 
modelos de referência, dentre eles citamos: 
 ● ISO/IEC 15504, Capability Maturity Model – 
Integration (CMMI) e o modelo brasileiro MPS.BR.
A qualidade de software é algo que se aplica no processo 
em que se definem os requisitos, utilizando métricas de 
melhoramento contínuo. Ainda, realizar as atividades 
de segurança da qualidade em cada escopo, que estão 
relacionadas ao projeto (PRESSMAN; MAXIM, 2016).
A qualidade de software contém uma lista de requisi-
tos, a saber: funcionalidade, confiabilidade, facilidade 
de uso, economia e segurança de uso. Em qualida-
de extra: flexibilidade, manutenibilidade, adaptável, 
clareza, documentação e iteração em melhorias 
(SWEBOK, s. d.).
Sendo assim, a qualidade de software pode ser definida 
segundo os procedimentos das normas citadas anterior-
mente: ISO/IEC 9126-1, ISO/IEC 12207, ISO/IEC 15504, 
ISO/IEC 20000 e ISO/IEC 27000. Entretanto, cada projeto 
33
possui seus próprios requisitos e políticas de qualidade 
e segurança do software.
O projeto de software deve, então, ser visto como uma in-
tegração de requisitos e procedimentos que contenham 
as melhores práticas da engenharia de software a fim de 
garantirem a qualidade de acordo com as necessidades 
do cliente (PRESSMAN; MAXIM, 2016).
A construção de um produto de software é um projeto 
que demanda diversas áreas do conhecimento a serem 
aplicadas (PMBOK, 2017). No entanto, os procedimentos 
descritos na norma ISO/IEC 15504 descrevem os níveis 
de maturidade de um projeto e como cada processo 
de software é realizado conforme o ciclo de vida e as 
áreas de conhecimento de um projeto (BALDASSARRE; 
PIATTINI; PINO; VISAGGIO, 2009).
Já o guia SWEBOK especifica e detalha as melhores prá-
ticas da engenharia de software para o processo de de-
senvolvimento de software, dividindo em dez áreas do 
conhecimento (SWEBOK, s. d.): 
 ● Requisitos de Software 
 ● Design de Software
 ● Construção de Software
 ● Teste de Software 
 ● Manutenção de Software 
 ● Gerenciamento de Configuração de Software 
 ● Gerenciamento de Engenharia de Software 
 ● Engenharia de Processo de Software 
34
 ● Ferramentas e Métodos de Software 
 ● Qualidade de Software
Assim, a gestão do projeto de software envolve diversos 
escopos que são desenvolvidos conforme a necessidade 
do produto. Cada projeto escolhe as metodologias apro-
priadas para o desenvolvimento do software seguindo 
os parâmetros descritos como modelos das normas ISO 
em busca da segurança da qualidade.
35
DESENVOLVIMENTO DE 
SOFTWARE BASEADO EM 
COMPONENTES
Na programação de software, são utilizadas técnicas de 
engenharia para o reaproveitamento de componentes 
que possuem funcionalidades lógicas definidas para a 
comunicação com o uso de interfaces. Na programação 
orientada a objetos, os componentes trocam informa-
ções por mensagens de dados.
Na Engenhar ia de Software Baseada em 
Componentes (ESBC), os requisitos são analisadoslevando em conta a arquitetura do software para um 
esquema de composição baseada em subconjuntos, 
em vez de serem construídos por técnicas convencio-
nais, na qual o design da arquitetura é determinado.
Nesse tipo de arquitetura, a abstração é utilizada na 
composição dos objetos, com o foco na produção de 
alto desempenho. Para garantir o baixo acoplamento 
entre as regras de negócio e os componentes, alguns 
princípios da programação orientada a objetos são 
adotados nas funcionalidades.
A programação de componentes funciona como um 
provedor de serviços, cuja comunicação é realizada pe-
las interfaces. Os componentes podem ser utilizados 
de muitas maneiras e, para entendermos melhor, um 
componente pode ter uma simples função matemática 
que pode ser requisitada.
36
O componente é requisitado de modo independente da 
linguagem de programação, por isso devemos conside-
rá-lo como uma entidade executável. Esse tipo de arqui-
tetura é utilizado principalmente em reúso, considerado 
um elemento-chave em diversos tipos de aplicações.
Componentes utilizados no desenvolvimento possuem 
alguns benefícios, tais quais:
 ● Produção: economia de tempo no desenvolvimento 
de software.
 ● Robustez: qualidade na produção do software, 
devido a muitos componentes já serem testados, 
trazendo velocidade e confiança em projetos com 
escopo definido.
 ● Padronização: utilização de padrões na equipe de 
desenvolvimento orientado a regras de negócio dos 
componentes.
37
INTERFACES DE 
COMPONENTES
Para entendermos melhor os componentes, vamos 
relembrar o conceito de interface, que é um contrato 
da classe com o exterior, ou seja, a assinatura da 
interface colabora com o comportamento da classe, 
padronizando os códigos implementados.
Nos componentes, a interface estabelece os serviços 
prestados, a implantação física pode ser definida 
na integração dos componentes. Com esse tipo de 
serviço, é possível desenvolver um sistema em que 
os serviços são independentes da localização de 
seus componentes, cuja comunicação funciona via:
 ● Interface Provides: é a interface que fornece serviços 
do componente para outros componentes.
 ● Interface Requires: é a interface que define quais re-
quisitos ficaram disponíveis para as suas funcionalidades.
FIQUE ATENTO
A programação por componentes é considerada 
complexa e nem sempre é a melhor solução.
Para termos um melhor entendimento, analisare-
mos dois exemplos de componentes com Provi-
des e Requires na Figura 4.
38
Interface requires Interface provides
Define os serviços 
do ambiente dos 
componentes 
usados pela 
interface
Define os serviços 
fornecidos pelo 
componente para 
outros componentes
sensorManagement
sensorData
sensorData
removeSensor
startSensor
stopSensor
testSensor
initialise
report
listAll
Coletor de 
dados
Componente
Interface requires Interface provides
E
X
E
M
P
LO
IN
T
E
R
FA
C
E
S
Figura 4: Exemplo de uso provides e requires. Fonte: Masiero (s. d., p. 6).
39
ABSTRAÇÃO DE 
COMPONENTES
 ● Abstração funcional: sua única função é imple-
mentada, pois pode ser uma aplicação simples, por 
exemplo, a conversão de dados de reais para dólar.
 ● Agrupamentos casuais: têm relações fracas entre 
os componentes, por exemplos, o uso de funções, 
conversão de dados, dentre outros.
 ● Abstrações de dados: utilizadas em classes de 
linguagens de programação orientadas a objetos, o 
componente é ilustrado como uma abstração.
 ● Abstração em clusters: classes abstratas contidas 
nos componentes que trabalham em conjunto.
 ● Abstração de sistema: trata-se de um sistema com-
pletamente contido.
40
MODELOS GENÉRICO 
DE PROCESSO DE 
SOFTWARE BASEADO EM 
COMPONENTES
Não há consenso do que deve fazer parte de um 
modelo de componentes, porém, algumas caracte-
rísticas precisam ser definidas: os tipos de compo-
nentes, formas de interação entre os componentes 
e o que deve ser definidos aos recursos.
Na definição dos recursos, que é como os compo-
nentes são ligados, os recursos podem ser providos 
por um framework ou uma ligação dos componentes, 
sendo que o modelo que disponibiliza quais com-
ponentes estarão disponíveis (BACHMANN, 2000).
Os modelos apresentam um conjunto de funções que 
se relacionam com um conjunto de componentes já 
existentes no sistema. Todo processo na modelagem 
precisa passar por algumas etapas até os sistemas 
serem desenvolvidos. Essas etapas são:
 ● Seleção: os componentes são pesquisados e ana-
lisados visando a saber qual é o potencial de uso 
para o sistema.
 ● Qualificação: os requisitos selecionados são qua-
lificados e testados de acordo com as necessidades 
de aplicação, como desempenho, confiabilidade e 
usabilidade (PRESSMAN; MAXIM, 2016).
41
 ● Adaptação: a correção de conflitos para que os 
componentes possam ser utilizados no projeto.
 ● Composição: responsável pela integração dos com-
ponentes no sistema que coordena os componentes e 
as realizações das tarefas.
 ● Atualização: nesta fase, os componentes podem 
ser substituídos ou atualizados por componentes 
com novas interfaces.
Essas etapas podem ser conferidas na Figura 5:
Seleção Qualificação Adaptação
Composição Atualização
Figura 5: Atividades do desenvolvimento com componentes. Fonte: 
(PRESSMAN; MAXIM, 2016).
Observe que não há uma ordem nessas etapas, por-
tanto, o que determina é a necessidade de acordo 
42
com os requisitos do projeto. Para essa atividade, 
algumas tarefas são realizadas, conforme consta 
na Tabela 7.
Item Descrição
Especificações de 
requisitos
Para esta fase, podem ser utiliza-
dos modelos, sendo comparável ao 
modelo cascata. As funções e regras 
de negócios são estabelecidas por 
consulta aos usuários.
Análise de 
componentes
As especificações são implementa-
das segundo os requisitos estabele-
cidos, visto que nem sempre há uma 
combinação coerente, e as funcionali-
dades são parcialmente utilizadas.
Modificação de 
requisitos
Os componentes são utilizados e 
modificados conforme a necessidade; 
caso não seja possível, outras alterna-
tivas são realizadas.
Projeto de sistema 
com reúso
Faz-se ou projeta-se uma análise no 
software desde o início, as regras de 
negócio são baseadas nos compo-
nentes existentes caso seja uma atua-
lização do software ou reutilização de 
bases comuns.
Desenvolvimento 
e integração
Nesta fase, os softwares não compra-
dos podem ser desenvolvidos, porém, 
pode ser feito uma integração com 
softwares conhecidos como comer-
cial off-the-shelf (sistemas comerciais 
de prateleira).
Validação O sistema é validado de acordo 
com os requisitos estabelecidos no 
projeto.
Figura 6: Processos de software baseados em componentes. Fonte: 
Adaptada de Pressman e Maxim (2016).
43
O Processos de Software Baseado em Componentes 
identifica os requisitos e remove as incongruências da 
arquitetura. Para tanto, há dois processos envolvidos: 
engenharia de domínio e desenvolvimento baseado 
em componentes (DBC).
A engenharia de domínio tem por objetivo a construção, 
classificação e liberação de um conjunto de componen-
tes de software com as aplicabilidades para softwares 
existentes ou novos projetos.
O DBC estabelece a construção e o controle dos estados 
dos componentes, que possuem cinco estágios: seleção, 
qualificação, adaptação, composição e atualização do 
componente (BROWN; SHORT, 1997).
Na prática, um componente dificilmente é reutilizável e, 
mesmo assim, precisa de modificações, ou seja, de mu-
danças para se adaptar aos novos projetos e estabelecer 
conexão com outros componentes (BOSCH, 1999). Para 
a adaptação de componentes segundo a engenharia de 
software, as aplicações mais conhecidas são:
 ● Encapsulamento de caixa-branca: a modificação é 
feita diretamente no código fonte, onde dificilmente é 
disponibilizada. Quando há necessidade de modificações 
de incompatibilidade, é necessário fazer adaptações, po-
rém, neste caso, torna-se difícil o acesso ao código fonte.
 ● Encapsulamento caixa-cinza: a adaptação do códigoé feita com o uso de Interface de programação de apli-
cações ou Interface de Programação de Aplicação, que 
possibilita o acerto de erros e conflitos.
44
 ● Encapsulamento caixa-preta: neste caso, o código 
não fica exposto, e para sua adaptação é preciso utilizar 
interfaces nas condições de processamento.
Como você já deve ter percebido, a programação por 
componentes apresenta diferenças de incompatibili-
dade. Algumas técnicas de encapsulamento e empa-
cotamento são utilizadas para adaptar as interfaces 
a uma nova versão com o requisito atualizado.
Muitos componentes possuem falha na interação, 
há diversos fatores para ocorrerem erros e falta de 
compatibilidade, e as causas podem estar relaciona-
das à plataforma do sistema e linguagem em que o 
componente foi desenvolvido. Tal fator é conhecido 
como heterogeneidade dos componentes.
Para resolver essa situação de acoplamento de com-
ponentes, desenvolveram-se algumas tecnologias de 
interação por camadas, ou seja, a ligação e a comu-
nicação entre diferentes componentes se realizam 
por uma terceira base, conhecidas como tecnóloga 
de componentes. Algumas dessas tecnologias são:
 ● CORBA Component Model (CMM) do Object 
Management Group (OMG).
 ● Distributed Component Obejct (DCOM) e COM/
COM+ (Component Object Model) da Microsoft.
 ● JavaBeans e Entreprise JavaBeans (EJB).
45
SAIBA MAIS
saiba mais sobre o Middleware, consultando Tec-
nologias de Middleware, de Fernando Martins, 
que se encontra disponível em: https://www.gsd.
inesc-id.pt/~ler/docencia/tm0607/slides/J2EE-
-FernandoMartins.pdf. 
46
https://www.gsd.inesc-id.pt/~ler/docencia/tm0607/slides/J2EE-FernandoMartins.pdf
https://www.gsd.inesc-id.pt/~ler/docencia/tm0607/slides/J2EE-FernandoMartins.pdf
https://www.gsd.inesc-id.pt/~ler/docencia/tm0607/slides/J2EE-FernandoMartins.pdf
IMPACTO DAS LINGUAGENS 
DE PROGRAMAÇÃO 
NA ENGENHARIA DE 
SOFTWARE
Como você já deve ter notado, até este momento as 
linguagens de programação foram surgindo de acor-
do com as necessidades científicas e do mercado 
de trabalho. Voltando um pouco na história, vamos 
relembrar as linguagens e seus propósitos.
A princípio, as linguagens se desenvolveram nos anos 
de 1960 e 1970, como a Fortran e Algol surgiram 
para fins matemáticos e, mais tarde, o Cobol para 
aplicação de negócios. Nessa época, as linguagens 
de programação evoluíam de acordo com o desenvol-
vimento de hardware. Com o lançamento de sistemas 
compartilhados, houve uma grande dificuldade nessa 
fusão de grandes plataformas. Além disso, outros 
problemas de multiprocessamento e programação 
concorrente trouxeram grandes dificuldades para as 
empresas na época.
Com diversas dificuldades, o assunto foi discutido 
abertamente em uma conferência na Alemanha em 
Garmisch-Partenkirchen, em 1968, onde se cunhou o 
nome engenharia de software. O termo e o que deve-
ria ser levado em consideração não foram discutidos, 
assim, a indústria não levou muito em consideração 
e ainda demorou muito tempo para haver mudanças.
47
A evolução foi acontecendo aos poucos; cientistas 
como E.W. Dijkstra e C.A.R Hoare reconheceram a 
linguagem de programação como uma disciplina. 
Algumas de suas publicações, na época, influencia-
ram as linguagens de programação, principalmente 
as estruturadas.
Nesse contexto de mudanças e conceitos de lingua-
gens de programação, houve um retrocesso no en-
tendimento de linguagem de alto nível com o uso da 
linguagem C, a qual era muito utilizada no sistema 
operacional Unix. Os conceitos de abstração eram 
facilmente quebrados na linguagem C, e os termos 
discutidos na engenharia de software não eram sus-
tentados. Porém, para muitos programadores, a lin-
guagem C era considerada melhor que o Assembly.
A linguagem C trazia muitos defeitos em relação 
à verificação de dados e sua consistência. As ma-
trizes possuíam índices que não eram verificados, 
frustrando alguns princípios de qualidade referente 
à engenharia.
Alguns anos depois, precisamente em 1985, surgiram 
a linguagem Ada e C++, em que muitos tentaram 
resolver os erros referentes à linguagem C, que é a 
abstração e a inconsistência de verificação de da-
dos. Porém, ao invés de melhorar, para muitos piorou 
ainda mais a situação (DIJKSTRA, 1962).
A complexibilidade na programação de computa-
dores aumentou, com isso, poderosas estações de 
trabalhos individuais foram criadas. Alguns conceitos 
como Programação Orientada a Objetos (POO) foram 
48
aceitos e, aos poucos, começaram a virar tendência 
de mercado.
A engenharia de software praticamente surgiu em 
crises de software, complexibilidade nos projetos 
e adequações necessárias para fazer um software 
de qualidade. A palavra engenharia representa: criar, 
construir, analisar, desenvolver e melhoramento con-
tínuo. A engenharia de software possui como base 
metodologias, modelos, normas e técnicas utiliza-
dos no processo de desenvolvimento e projeto de 
software.
Para acompanhar o desenvolvimento dessa disci-
plina, observe os encontros e as iniciativas dessa 
evolução na Figura 6:
Figura 7: Linha do tempo de eventos na Engenharia de Software. 
Fonte: Time Toast. 
Como observado na Figura 6, a POO teve uma gran-
de evolução no desenvolvimento de software, pois 
houve praticamente um grande domínio no mercado 
por ser um paradigma de programação que cobre a 
49
https://www.timetoast.com/timelines/historia-da-engenharia-de-software
maioria das aplicações, porém, não é recomendada 
para todos os tipos.
A POO apresenta problemas como qualquer outro 
paradigma, a sua ideia de utilização de objetos e pa-
dronização dos códigos aplicando a Unified Modeling 
Language (UML) trouxe muitas vantagens nos pro-
jetos. Vamos deixar bem claro que nem todas as 
linguagens de POO seguem bem os princípios da 
engenharia de software.
Esses fatores foram decisivos para uma ou outra lin-
guagem se destacar. A POO não é um princípio novo, 
e a UML trouxe vantagens aos projetos. Contudo, não 
é toda linguagem que adota o máximo possível dos 
padrões da UML. Além disso, a arquitetura de cada 
linguagem de programação é modificada para o me-
lhor funcionamento seguindo regras dos fabricantes.
SAIBA MAIS
Saiba mais sobre a UML, assistindo a Unified Mo-
deling Language, uma breve história, disponível 
em: http://www.dsc.ufcg.edu.br/~jacques/cursos/
map/html/uml/historia_uml/historia_uml.htm. 
50
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/historia_uml/historia_uml.htm
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/historia_uml/historia_uml.htm
CICLO DE VIDA
As tarefas envolvidas no desenvolvimento de softwa-
res implicam atividades que pertencem aos proces-
sos do ciclo de vida do software. O modelo escolhido 
para o desenvolvimento é o que determina como 
esse software será projetado.
De acordo com a ISO/IEC 12207 (1998), o ciclo de 
vida é 
Estrutura contendo processos, atividades e 
tarefas envolvidas no desenvolvimento, ope-
ração e manutenção de um produto de sof-
tware, abrangendo a vida do sistema, desde 
a definição de seus requisitos até o término 
de seu uso.
Não há um ciclo de vida ideal para todas aplicações, 
alguns projetos são adotados mais do que um tipo 
de ciclo de vida. O que de fato determina são os 
requisitos e as regras de negócio da aplicação. Os 
modelos mais conhecidos da engenharia de software 
estão descritos na Tabela 8:
SAIBA MAIS
Conheça a ISO/IEC 12207, acessando https://
www.dcce.ibilce.unesp.br/~ines/cursos/eng_
soft/2006/aula03_ISO_IEC.pdf.
51
https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula03_ISO_IEC.pdf
https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula03_ISO_IEC.pdf
https://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/2006/aula03_ISO_IEC.pdf
Modelos Descrição
Cascata
Primeiro modelo de gerenciamento de proces-
sos de software, modelo sequencial, modelo 
com ênfase maior na análise de projeto.
Não é iterativo, utilizado principalmente em 
projetos críticos e de alto custo, uma vez que 
apresentatodo o processo que pode ser iniciado 
do zero ou o projeto é abortado.
Incremental
Neste modelo, os escopos são agrupados em 
módulos, e as prioridades são validadas junto ao 
cliente. Utilizam como base o modelo cascata.
Evolutivo
Esse modelo é escolhido quando os requisitos não 
estão muito claros ou há faltas dele.
Existe um desenvolvimento gradual, a partir de mo-
delos anteriores, o desenvolvimento é atualizado 
em novas versões.
RAD
O modelo Rapid Application Development é 
incremental, utilizado para prototipagem rápida, 
o ciclo de vida não é curto e tem a duração entre 
60 e 90 dias.
Prototipagem
Entende-se como desenvolver parte do projeto, 
como uma tela para ser apresentada e validada 
para o cliente. Serve principalmente para ter uma 
ideia de como ficaria essa parte, muitas vezes 
complexas, por apresentarem resultados mais 
imediatos em pouco tempo.
Espiral
Esse modelo é baseado em análise de riscos, 
onde cada iteração ou volta é analisado: viabili-
dade do projeto, definição de requisitos, desen-
volvimento e testes.
Tabela 7: Modelos de ciclo de vida de software.Fonte: Devmedia. 
52
https://www.devmedia.com.br/ciclos-de-vida-do-software/21099
FLUXO DE 
TRABALHO 
O workflow (fluxo de trabalho) em projetos de software 
normalmente é auxiliado por ferramentas Computer-
Aided Software Engineering (Case), ou Engenharia 
de Software Assistida por Computador. Esse tipo de 
ferramenta faz parte da engenharia de software, não 
entenda como apenas um fluxo de trabalho simples, 
pois cada escopo definido representa as regras de 
negócios e os requsitos do sistema.
Na programação orientada a objetos, uma das fer-
ramentas mais utilizadas foi o Business Process 
Execution Language (BPEL), ou Linguagem de 
Execução de Processos de Negócios. Trata-se de 
uma ferramenta incrível que teve origem em empresas 
como Microsoft e IBM. Algumas dessas ferramentas 
disponibilizam os sistemas de orquestração, que inte-
rage com os requisitos internos e externos do projeto 
de software.
O BPEL tem uma definição para o fluxo entre serviços 
e lógica de acoplamento; para a orquestração, utiliza-
-se a Web Service como base, ferramenta que pode 
ser visual, que é fácil de entender e interagir com o 
fluxo de trabalho. O BPEL utiliza a linguagem XML, é 
capaz de trabalhar com códigos e administrar as ta-
refas a serem executadas em tempo real em projetos. 
Algumas dessas ferramentas são Microsoft BizTalk 
Server e Oracle Process Manager.
Para você ter um entendimento melhor do BPEL, ob-
serve a Figura 7, onde temos o BPEL na ferramenta 
53
Oracle JDeveloper. Analise o workflow e as notações 
utilizadas no lado esquerdo da ferramenta.
Figura 8: Exemplo BPEL no JDeveloper. Fonte: Elaboração própria. 
O BPEL é uma ferramenta muito interessante e com-
plexa, praticamente uma evolução de alguns modelos 
da UML. Entretanto, é uma ferramenta utilizada mais 
ao nível de programadores, por ter funções avançadas. 
Alguns anos depois do BPEL, houve uma evolução da 
ferramenta para ser utilizada em fluxo de processos 
de negócio, essa ferramenta é o Business Process 
Model and Notation (BPMN).
O BPMN tornou-se um padrão mundial no uso de fluxo 
de processos de negócios, uma vez que é considerado 
mais simples do que o BPEL; trouxe para a área de 
negócios uma integração de pessoas que não são 
da área de informática, mas que estão envolvidas 
em processos de negócio e seu fluxo de execução 
(LEYMANN, 2010).
54
O BPMN pertence a UML e, desde a versão 2.0, não 
teve muitas modificações; há ferramentas como o 
BizAge, SigNavio e plug-ins para serem utilizados no 
eclipse e outras plataformas de desenvolvimento.
Uma das empresas com um vasto material para estu-
do é a Camunda, que tem manuais e exemplos práti-
cos envolvendo casos de uso para serem utilizadas 
como aprendizado. Além da própria OMG, que dispo-
nibiliza gratuitamente manuais do BPMN (CHINOSI; 
TROMBETTA, 2012). É algo em que vale a pena investir 
e se especializar, pois faz parte da engenharia de sof-
tware e compõe os projetos de qualidade. As notações 
são simples e há vários manuais disponíveis na Web.
Como você pode perceber na Figura 8, o BPMN é mui-
to semelhante ao BPEL:
Figura 9: Exemplo de BPMN. Fonte: BGT Brasil. 
O BPMN é uma metodologia de fluxo de trabalho mui-
to utilizada em projetos de software. Algumas ferra-
mentas comerciais utilizam o BPMN como forma de 
monitorar todo o processo de negócio ou parte dele.
55
http://www.bgtbrasil.com/bpmn/
GESTÃO DE PROJETOS
A gestão de projetos dependerá muito do propósito, 
se é uma inovação, se é uma atualização, integração 
ou outros fatores. A engenharia de software preocu-
pa-se com todas as fases dos projetos de softwa-
re, desde os processos envolvidos até os serviços 
prestados.
O conhecimento de metodologias, normas e técnicas 
é muito importante em projetos de software de alto 
padrão, principalmente a nível governamental e inter-
nacional, que deve obedecer às normas e métricas 
de qualidade assegurada.
Países como Estados Unidos da América, Canadá, 
alguns europeus e outros desenvolvidos possuem ex-
periência em projetos de software. No Brasil, não há 
uma cultura de software como na Índia, que discuta a 
matemática e a programação de computadores com 
a mesma efervescência como se debate sobre fute-
bol. O Brasil vem utilizando metodologias e padrões 
internacionais para prestar serviços a empresas com 
níveis de maturidade muito altos. Infelizmente, esses 
métodos e normas na maioria das vezes não funcio-
nam muito bem por questões culturais.
O MPS.BR foi uma tentativa de montar um modelo 
parecido com o CMMI ou ISO/IEC 15504, porém, não 
foi largamente adotado pelas empresas e está lon-
ge de ser uma realidade na gerência de software. O 
PMBOK, já citado anteriormente, é um guia do Project 
56
Management Institute (PMI), mundialmente famoso 
e muito bem aceito em qualquer tipo de projeto.
No entanto, você deve estar ciente quanto à realida-
de do mercado brasileiro. O PMBOK vem servindo 
mais como um certificado para gerentes colocarem 
em seus currículos, provando seu conhecimento da 
teoria e as técnicas do guia, mas que não garante 
que vão conseguir gerenciar um projeto de software.
Lembre-se de que as técnicas e metodologias podem 
auxiliar, mas você trabalha com pessoas que podem 
não estar interessadas nessas técnicas ou as utili-
zam totalmente fora da realidade e do contexto do 
projeto em que você trabalha.
No Brasil, desenvolvedores experientes que atuam na 
área de negócios já são considerados engenheiros 
de software, ainda que não possuam uma grande 
experiência nas diversas áreas. Você provavelmente 
participará de projetos de software com pessoas 
que não são da área da computação e que acham 
que sabem como funciona o projeto, porque já está 
definido em um papel.
Além disso, você deve se preocupar com as pessoas 
envolvidas no projeto, pois, com toda certeza, o seu 
maior problema são os erros humanos. Os fatores 
humanos representam a maioria dos casos de fra-
casso de todos os projetos. Por essa razão, saber 
escolher a equipe e trocar ou adquirir novos recursos 
é uma das funções do gerente de projetos.
57
O PMBOK possui as fases do processo que envolve 
um projeto e as dez áreas do conhecimento para você 
ter uma ideia do que precisa monitorar em um proje-
to. Lembre-se de que, em um projeto de software, os 
acontecimentos são mais dinâmicos e há oportuni-
dade de mudanças quando estas forem necessárias, 
dependendo de modelos escolhidos. Entretanto, al-
gumas metodologias para gerenciamento de equi-
pes em projetos de software apresentaram um bom 
resultado, mesmo aqui no Brasil, como é a adoção 
do SCRUM, XP e FDD, que são metodologias ágeis.
Conhecer o negócio e as experiências faz a diferença 
na produção de software, pois um membro sênior 
(por exemplo um consultor) pode levar o projeto a 
outros níveis de maturidade, ao escolher os melhores 
caminhos e com menores chances de erro no projeto.
58
CONSIDERAÇÕES FINAISOs projetos de software requerem um conhecimento 
de normas e técnicas a fim de refinar a qualidade e 
melhorar as equipes que desenvolvem os softwares. 
Você deve ter notado que há uma evolução nos mo-
delos de ciclo de vida voltados aos softwares, sendo 
que o gerenciamento de projetos exige muito mais 
que apenas programar.
Além dos paradigmas de linguagem de programação, 
o impacto com a evolução das tecnologias levou a 
uma nova disciplina, a engenharia de software. O 
estudo da engenharia de software é considerado pri-
mordial em qualquer projeto de grande importância, 
pois as técnicas e os métodos utilizados garantem 
um bom resultado em diversos tipos de projetos.
Ademais, pudemos estudar que há ferramentas ca-
pazes de ser utilizadas para acompanhar o fluxo de 
desenvolvimento ou acompanhamento de projetos, 
como BPEL e BPMN. Portanto, conhecer essas me-
todologias é essencial para elas serem aplicadas em 
projetos que envolvam software.
59
SÍNTESE
Fluxo de trabalho: 
• Fases que envolvem todos os processos de 
negócios no desenvolvimento.
Gestão de projetos:
• Área de conhecimento que precisa estar 
associado à engenharia de software como 
base nos processos envolvidos em projetos 
de software.
Paradigmas de Linguagem 
de Programação
Programação Imperativa; programação 
orientada a objetos; programação 
funcional; programação lógica; 
programação orientada a eventos; 
programação concorrente:
• Conhecer a aplicação e qual é a ideia e o 
pensamento que envolvem a aplicação é 
muito importante para o desenvolvimento de 
software. Estudar os paradigmas e entender 
os conceitos melhorarão seu entendimento na 
programação.
Gerenciamento de projetos de software:
• Técnicas utilizadas para acompanhamento 
dos processos de software. A gerência de 
software deve estar muito envolvida com a 
qualidade e com os requisitos do projeto.
Desenvolvimento de Software baseado 
em componentes:
• Tipo de aplicação complexa e voltada ao 
reúso de software. Essa técnica requer um 
conhecimento de engenharia de software por 
ser complexo. Porém, a depender do tipo de 
projeto, pode ser eficaz e produtivo.
Impacto das linguagens de programação 
na Engenharia de Software:
• A evolução das linguagens de programação 
possibilitou a necessidade de criar e aplicar 
técnicas da engenharia para aumentar e 
padronizar a qualidade de software.
Ciclo de vida:
• Envolve os modelos de processos de 
desenvolvimento de software.
Referências 
Bibliográficas 
& Consultadas
ÁLVARES, A. R. Programação Lógica (Prolog): aula 
11 (s. d.). Cefet-MG/Decom. Disponível em: ht-
tps://homepages.dcc.ufmg.br/~rimsa/documents/
decom009/lessons/Aula11.pdf. Acesso em: 03 
ago. 2019.
BACHMANN, F. et al. Volume II: Technical 
Concepts of Component-Based Software 
Engineering. 2. ed. Technical Report of Software 
Engineering Institute, Carnegie Mellon University, 
may 2000. Disponível em: http://www.sei.cmu.
edu/pub/documents/00.reports/pdf/00tr008.pdf. 
Acesso em: 05 ago. 2019.
BALDASSARRE, M. T.; PIATTINI, M.; PINO, F. J.; 
VISAGGIO, G. Comparing ISO/IEC 12207 and 
CMMI-DEV: Towards a mapping of ISO/IEC 15504-
7. ICSE Workshop on Software Quality, Vancouver, 
BC, USA, 12 Jun. 2009. Disponível em: https://iee-
explore.ieee.org/document/5071558.
BOSCH, J. Superimposition: A component adap-
tation technique. Information and Software 
https://homepages.dcc.ufmg.br/~rimsa/documents/decom009/lessons/Aula11.pdf
https://homepages.dcc.ufmg.br/~rimsa/documents/decom009/lessons/Aula11.pdf
https://homepages.dcc.ufmg.br/~rimsa/documents/decom009/lessons/Aula11.pdf
http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr008.pdf
http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr008.pdf
https://ieeexplore.ieee.org/xpl/conhome/5061466/proceeding
https://ieeexplore.ieee.org/document/5071558
https://ieeexplore.ieee.org/document/5071558
https://www.sciencedirect.com/science/article/pii/S0950584999000075
https://www.sciencedirect.com/science/article/pii/S0950584999000075
Technology, Elsevier, 25 mar. 1999. p. 257-273. 
Disponível em: http://citeseerx.ist.psu.edu/
viewdoc/download?doi=10.1.1.25.7736&rep=rep1&t
ype=pdf. Acesso em: 10 ago. 2019.
BROWN, A. W.; SHORT, K. On Components 
and Objects: The Foundation of Component-
Based Development. International Symposiumn 
Assessment of Software Tools and Technologies. 
IEEE, Jul. 25 1997. p. 112-121. Disponível em: 
https://ieeexplore.ieee.org/document/599921/
authors#authors. Acesso em: 05 ago. 2019.
CAELUM. Apêndice – programação concorrente e 
threads. In: Apostila Java e orientação a objetos 
(s. d.). Disponível em: https://www.caelum.com.br/
apostila-java-orientacao-objetos/apendice-progra-
macao-concorrente-e-threads/. Acesso em: 05 ago. 
2019.
CÁCERES, S. Aplicações de Linguagem de 
Programação Orientada a Objeto – Eventos 
(s. d.). Disponível em: https://www.ic.unicamp.
br/~ra100621/class/2017.2/ALPOO_files/aulas-
Sheila/ALPOO5B-Eventos.pdf . Acesso em: 03 ago. 
2019.
CHINOSI, M.; TROMBETTA, A. BPMN: An intro-
duction to the standard. Computer standards & 
Interfaces, vol. 34, n. 1, jan. 2012. p. 124-134. 
Disponível em: https://www.sciencedirect.com/
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.7736&rep=rep1&type=pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.7736&rep=rep1&type=pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.7736&rep=rep1&type=pdf
https://www.caelum.com.br/apostila-java-orientacao-objetos/apendice-programacao-concorrente-e-threads/
https://www.caelum.com.br/apostila-java-orientacao-objetos/apendice-programacao-concorrente-e-threads/
https://www.caelum.com.br/apostila-java-orientacao-objetos/apendice-programacao-concorrente-e-threads/
https://www.ic.unicamp.br/~ra100621/class/2017.2/ALPOO_files/aulasSheila/ALPOO5B-Eventos.pdf
https://www.ic.unicamp.br/~ra100621/class/2017.2/ALPOO_files/aulasSheila/ALPOO5B-Eventos.pdf
https://www.ic.unicamp.br/~ra100621/class/2017.2/ALPOO_files/aulasSheila/ALPOO5B-Eventos.pdf
https://www.sciencedirect.com/science/article/abs/pii/S0920548911000766
science/article/abs/pii/S0920548911000766. 
Acesso em: 01 ago. 2019.
DEITEL, P.; Deitel, H.; Java: Como Programar. 10. 
ed. São Paulo, Pearson Education do Brasil, 2016 
[Biblioteca Virtual].
DIJKSTRA, E. W. Some critical comments on ad-
vanced programming. Proc. IFIP Congress, Munich, 
Aug. 1962.
KOONTZ, H.; O’DONNEL, C.; WEINRICH, H. 
Management of Education. 12. ed. Auckland: 
McGraw-Hill, 2002.
LEYMANN, F. BPEL vs. BPMN 2.0: Should you care? 
In: International Workshop on Business Process 
Modeling Notation. Springer, Berlin, Heidelberg, p. 
8-13, 2010.
LOUREDA, O. B. Desenvolvimento de um microfo-
guete para fotografias aéreas de pequeno formato. 
In: Anais do XII ENCITA 2006, ITA, out.-2006, p. 23-
26. Disponível em: http://www.bibl.ita.br/xiiencita/
mec_09.pdf. Acesso em: 03 ago. 2019.
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 
computadores: guia prático de introdução, orien-
https://www.sciencedirect.com/science/article/abs/pii/S0920548911000766
http://www.bibl.ita.br/xiiencita/mec_09.pdf
http://www.bibl.ita.br/xiiencita/mec_09.pdf
taçã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: fun-
damentos, métodos e padrões. 3. ed. São Paulo: 
Gen/LTC, 2009 [Biblioteca Virtual].
PERKOVIC, L. Introdução à computação usando 
Python: um foco no desenvolvimento de aplica-ções. Rio de Janeiro: LTC, 2016.
PMBOK. PROJECT MANAGEMENT INSTITUTE. 
Guia de conhecimentos: um Guia do Conjunto em 
Gerenciamento de Projetos. 6. ed., 2017.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de 
Software: uma abordagem profissional. 8. ed. 
Porto Alegre: McGraw-Hill, 2016 [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
PROKOPEC, A. Learning Concurrent Programming 
in Scala. 2. ed. Packt Publishing Ltd, 2017.
SBROCCO, J. H. T. C.; MACEDO, P. C. Metodologias 
ágeis: engenharia de software sob medida. São 
Paulo: Érica, 2012 [Biblioteca Virtual].
SCHACH, S. R. Engenharia de software: os para-
digmas clássico e orientado a objetos. 7. ed. Porto 
Alegre: AMGH, 2010.
SCHULMEYER, G. G. (Ed.). Handbook of Software 
Quality Assurance. 4. ed. Artech House, 2007. 
SEBESTA, R. W. Conceitos de linguagens de pro-
gramação. 11. ed. Porto Alegre: Bookman, 2018.
SOMMERVILLE, I. Engenharia de Software. 10. ed. 
São Paulo: Pearson Education do Brasil, 2018.
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].
SWEBOK. SOFTWARE ENGINEERING BODY OF 
KNOWLEDGE. Guide to the Software Engineering 
Body of Knowledge, 2004. Disponível em: https://
www.computer.org/education/bodies-of-knowled-
ge/software-engineering/v3. Acesso em: 05 ago. 
2019.
https://www.computer.org/education/bodies-of-knowledge/software-engineering/v3
https://www.computer.org/education/bodies-of-knowledge/software-engineering/v3
https://www.computer.org/education/bodies-of-knowledge/software-engineering/v3
TUCKER, A. B.; NOONAN, R. E. Linguagens de 
Programação: Princípios e Paradigmas. 2. ed. 
McGraw-Hill, 2009.
WEINSTEIN, J.; VASOVSKI, S. The PDCA 
Continuous Improvement Cycle. Cambridge: 
Massachusetts Institute of Technology (MIT) 
Leaders for Manufacturing Program, 2004.
	_Hlk15800520
	_Hlk15776630
	_Hlk15777465
	_Hlk15778509
	_Hlk15778190
	_Hlk15803592
	_GoBack
	_Hlk15780275
	_Hlk15780401
	_Hlk14755935
	_Hlk15782314
	_Hlk15798085
	_Hlk15337061
	Introdução
	Programação Imperativa
	Tipos compostos
	Programação Orientada a Objetos
	Programação Funcional
	Programação Imperativa vs Programação Declarativa
	Programação Lógica
	Programação Orientada a Eventos
	Programação Concorrente
	Gerenciamento de projetos de software
	Processos de Projetos
	Processo de Gerência de Projetos
	Áreas de Conhecimento do PMBOK
	Método de melhoria contínua PDCA
	Projeto de Software e Qualidade Assegurada
	Desenvolvimento de Software baseado em componentes
	Interfaces de componentes
	Abstração de Componentes
	Modelos genérico de processo de software baseado em componentes
	Impacto das linguagens de programação na Engenharia de Software
	ciclo de vida
	Fluxo de trabalho 
	Gestão de projetos
	Considerações finais
	Síntese