Fundamentos Sistema de Informação

Prévia do material em texto

Fundamentos 
de Sistemas de 
Informação
1ª edição
2017
Fundamentos 
de Sistemas de 
Informação
Presidente do Grupo Splice
Reitor
Diretor Administrativo Financeiro
Diretora da Educação a Distância
Gestor do Instituto de Ciências Sociais Aplicadas 
Gestora do Instituto da Área da Saúde
Gestora do Instituto de Ciências Exatas
Autoria
Parecerista Validador
Antônio Roberto Beldi
João Paulo Barros Beldi
Claudio Geraldo Amorim de Souza 
Jucimara Roesler
Henry Julio Kupty
Marcela Unes Pereira Renno
Regiane Burger
Ana Araújo Stelle
Elaine Santos
Roque Maitino Neto
Mônica da Consolação Machado
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte 
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos 
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
44
Sumário
Unidade 1
Sistemas de Informação – Conceitos Iniciais ............6
Unidade 2
Tipos de Sistemas de Informação .............................21
Unidade 3
Sistemas de Informação em Negócios .....................38
Unidade 4
Desenvolvimento de Sistemas....................................59
Unidade 5
Engenharia de Software .............................................75
Unidade 6
Engenharia de Requisitos ...........................................91
Unidade 7
Manutenção e Reengenharia ...................................108
Unidade 8
Conceitos de Projeto .................................................123
5
Palavras do professor
Caro aluno, seja bem-vindo à disciplina Fundamentos de Sistemas de 
Informação. 
Prepare-se para descobrir o quão fascinante são os Sistemas de Informa-
ção e a grande contribuição deles para que as empresas se tornem mais 
eficientes e eficazes. 
Você perceberá o quanto a informação é importante para a condução de 
um negócio e como a tecnologia pode sistematizar dados, facilitando o 
acesso aos grandes volumes de informação que as empresas produzem. 
Na primeira unidade, estudaremos os principais conceitos sobre Sistemas de 
Informação, suas dimensões e os conceitos de Tecnologia da Informação.
Na segunda unidade, conheceremos alguns tipos de Sistemas de Infor-
mação, como o Sistema de Informação Gerencial, o Sistema de Apoio à 
Decisão e o Sistema de Informação Executiva.
Na terceira unidade, vamos ter a oportunidade de aprender um pouco 
sobre os sistemas utilizados na gestão da informação para negócios, des-
tacando sua importância para uma gestão bem-feita.
Já na quarta unidade, vamos conhecer sobre os profissionais envolvidos 
no desenvolvimento de sistemas e as carreiras em Sistemas de Informa-
ção, além do ciclo de vida do software.
Nas unidades cinco, seis e sete, aprofundaremos nosso conteúdo 
entrando na Engenharia de Software, Engenharia de Requisitos, manu-
tenção e reengenharia.
Na unidade oito, fecharemos com os conceitos de projeto de Sistemas de 
Informação.
Desejamos que aproveitem bem os conteúdos apresentados nesta disci-
plina; então, vamos lá?! 
1
6
Unidade 1
Sistemas de Informação – 
Conceitos Iniciais 
Para iniciar seus estudos
Você já parou para pensar em quantos Sistemas de Informação usou hoje? 
Para sair de casa e saber qual o melhor trajeto, para saber a previsão do 
tempo ou fazer uma pesquisa de preço em várias lojas on-line; todos os 
dias, usamos diversos sistemas. Mas afinal, o que é um Sistema de Infor-
mação? Essa é a resposta que vamos alcançar nesta unidade.
Objetivos de Aprendizagem
• Compreender o conceito básico de Sistemas de Informação. 
• Entender os principais conceitos envolvidos com os Sistemas de 
Informação. 
• Compreender a relação entre Tecnologia da Informação e Siste-
mas de Informação.
7
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
1.1 Conhecendo os Sistemas
Antes de falarmos sobre os principais conceitos de Sistemas de Informação, é importante compreendermos o 
conceito de sistema. É fundamental saber que nem sempre esse conceito se relaciona à computação, embora, 
por diversas vezes, esteja em nossa mente vinculado a ela. No nosso dia a dia, interagimos com inúmeros sis-
temas: sistema de transporte, sistema de comunicação, sistema de energia. Mas qual é a definição da palavra 
sistema? Segundo Resende e Abreu (2014, p. 34), é:
Um conjunto de partes que interagem entre si, integrando-se para atingir um objetivo ou resultado; partes 
interagentes e interdependentes que formam um todo unitário com determinados objetivos e efetuam 
determinadas funções.
Ou seja, sistema corresponde a um conjunto de partes independentes que interagem formando um todo para 
a realização de um conjunto de objetivos. Um sistema pode ser dividido em partes menores, que são chamados 
subsistemas; portanto, um sistema é um conjunto de subsistemas.
Para entender melhor um sistema, vamos estudar seus componentes de forma detalhada. Basicamente, um sis-
tema apresenta seis componentes:
• Objetivo: é a própria razão de ser do sistema e a finalidade para o qual foi criado.
• Entradas: estabelecem toda matéria-prima que inicia o processo de transformação, ou seja, a energia, o 
material ou os dados que dão início ao processo.
• Processamento: é a função que possibilita a conversão ou a transformação de insumos (entrada) em um 
produto, serviço ou resultado (saída). 
• Saídas: correspondem a tudo o que resultou do processo e devem ser coerentes com os objetivos do 
sistema.
• Controles e Avaliações: mecanismo existente para que seja identificado se as saídas estão coerentes com 
os objetivos estabelecidos para a criação do sistema.
• Retroalimentação: também chamada de feedback do sistema, pode ser considerada uma nova entrada no 
sistema. 
Feedback: Termo em inglês que significa dar resposta a determinado pedido ou aconteci-
mento. Um feedback pode ser positivo ou negativo. Exemplo: apresentei esse relatório para 
os gerentes e o feedback foi bastante positivo. 
Glossário
8
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
A figura a seguir representa os componentes de um sistema de forma genérica.
Figura 1.1 – Componentes de um sistema.
Processos de
Transformação
Entradas Saídas
C
on
tr
ol
e 
e 
av
al
ia
çã
o
RETROALIMENTAÇÃO
OBJETIVOS
 
Legenda: Demonstração do fluxo de um sistema.
Fonte: Elaborada pelo autor (2018).
1.2 Sistemas de Informação
Sistemas de Informação (SI) é um termo usado para descrever um tipo de sistema (automatizado ou manual) que 
coleta, processa e transmite informação para um usuário. Podemos então deduzir que a principal função de um 
SI é processar dados, transformando-os em informações úteis para a tomada de decisão.
Figura 1.2 – O Processamento de Dados.
Dados
(Entrada)
Informação
(Saída)
Processamento
Legenda: Diagrama do processamento de dados por um sistema de informação.
Fonte: Elaborada pelo autor (2018).
Esses sistemas são um conjunto de pessoas, software, hardware, redes de telecomunicações e recursos de dados 
que coletam, armazenam, processam e distribuem informações. Eles apoiam a realização de tarefas ou proces-
sos, integrando vários agentes, unidades e departamentos, formando uma cadeia de informação.
Todo o entendimento sobre as necessidades, os requisitos das informações, as atividades, as regras e os proce-
dimentos a serem seguidos é determinado pelos profissionais responsáveis pelas atividades que serão apoiadas 
pelo Sistema de Informação. O SI será utilizado por pessoas; por isso, os resultados de sua aplicação devem estar 
orientados às necessidades dessas pessoas, as quais podemos denominar usuários-chave.
9
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
Segundo Resende e Abreu (2014), em geral, os sistemas procuram atuar como:
• instrumentosque possibilitam uma avaliação das informações das empresas;
• facilitadores dos processos das empresas; 
• meios para suportar qualidade, produtividade e inovação tecnológica organizacional;
• geradores de modelos de informações para auxiliar os processos decisórios empresariais;
• produtores de informações oportunas e geradores de conhecimento;
• valores agregados e complementares à modernidade, à continuidade, à lucratividade e à competitividade 
empresarial.
1.2.1 Dado, Informação e Conhecimento
A partir de agora, vamos abordar os principais conceitos envolvidos nos fundamentos de um Sistema de Informação.
Se o objetivo de um sistema de informação é coletar, processar e transmitir informação, precisamos entender a 
relação entre dado, informação e conhecimento.
Vamos tomar como exemplo um convite para um evento. Nele, está informado o seguinte endereço:
Figura 1.3 – Convite para evento.
Legenda: Exemplo de convite para evento contendo informações básicas.
Fonte: Plataforma Deduca (2018).
Esses quatro elementos são os dados. Os dados são códigos que, analisados individualmente, não possuem 
significado. Esses dados precisam ser agrupados de maneira ordenada com: nome da rua + número + bairro + 
cidade. Somente com esse arranjo você saberá onde será o evento. A combinação desses dados brutos formará 
o endereço, ou seja, a informação.
10
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
A informação pode ser definida como um conjunto de dados organizados e processados de forma que tenham 
valor. Possibilita resolver problemas e também ajuda nas tomadas de decisões. De um modo geral, podemos dizer 
que a informação é um conjunto de dados moldados e dotados de relevância e propósito e útil para as pessoas. 
A informação apresenta as seguintes características: 
Quadro 1.1 – Características da informação.
Precisa Sem erros. Uma informação errada pode ser gerada por causa de dados 
incorretos que são lançados como entrada. A informação deve ser 
definida de forma correta.
Completa Deve conter todos os fatos que sejam relevantes.
Clara Uma informação deve ser simples e apresentada de forma clara.
Veloz Deve ser disponível no momento exato, nem antes e nem depois, mas 
no momento exato.
Flexível Uma informação deve ser armazenada de forma que possa ser utilizada 
para diferentes finalidades, auxiliando em diferentes tomadas de 
decisões.
Confiável Uma informação confiável depende dos dados de origem e de qual 
método foi utilizado para coletar os dados.
Relevante Com uma informação relevante, é possível tomar decisões sobre 
determinado processo.
Acessível Deve ser de fácil acesso para usuários, no formato adequado.
Verificável A informação deve ser passível de verificação por parte daquela pessoa 
que vai tomar alguma decisão.
Segura A informação deve ser acessada somente por pessoas autorizadas.
Legenda: Descrição das características essenciais à informação.
Fonte: Elaborado pelo autor (2018).
No nosso exemplo de endereço, o dado é o nome da rua; já a informação é o nome da rua, o número, o bairro e a 
cidade; o conhecimento, por sua vez, é saber como chegar ao endereço do evento.
O conhecimento é a capacidade de compreender um conjunto de informações e entender como elas podem ser 
úteis e como podem ser usadas em determinada tarefa ou tomada de decisão.
O dado é o fato bruto, a informação é o dado dotado de relevância e propósito e o conheci-
mento é o uso das informações para a tomada de decisão.
Entendidos esses conceitos de dado, informação e conhecimento, percebemos a importância e as relações de 
cada um desses elementos.
11
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
1.2.2 Dimensões dos Sistemas de Informação
Quando falamos de SI enquanto disciplina, nos referimos a uma área multidisciplinar que integra abordagens 
técnicas e comportamentais em seu estudo. Nesse contexto, quando conceituamos Sistemas de Informação, 
devemos considerar que os SIs apresentam três diferentes dimensões: a dimensão tecnológica, a organizacional 
e a humana. Observe as características a seguir: 
1. Dimensão tecnológica: refere-se a infraestrutura (hardware, software e comunicações), a aplicações orientadas 
ao ambiente organizacional (intranet, por exemplo) e a aplicações de gestão externa (extranet, por exemplo). 
:Intranet: Rede interna de determinada empresa. Caracteriza-se por ser fechada e exclusiva, 
de modo que podemos compará-la a um site, o qual, porém, só pode ser acessado pelos 
funcionários dentro da empresa. 
Extranet: Quando a informação de uma intranet fica acessível para um grupo de clientes ou 
fornecedores.
Glossário
2. Dimensão Organizacional: relaciona-se com processos (modelagem de negócio) e abordagens de gestão 
(mudança, cultura organizacional e liderança). 
3. Dimensão Humana: refere-se às pessoas que fazem uso dos sistemas, bem como às pessoas que desen-
volvem os processos de aprendizagem relacionados a esses sistemas. 
1.3 Tecnologia da informação 
É bastante comum encontrar definições de SI relacionadas à Tecnologia da Informação (TI) ou mesmo à computação. 
O termo Sistemas de Informação abrange componentes inter-relacionados que coletam, processam, armaze-
nam e distribuem informações. Já o termo TI é usado para referir-se à infraestrutura, às técnicas de implementa-
ção e às formas de comunicação (redes, internet etc.). 
A confusão entre esses dois conceitos existe pelo fato de alguns autores, como Stair (2016), considerarem a TI 
como a parte tecnológica dos SIs, o que inclui hardware, software e Banco de Dados (BD). Essa é a visão que ado-
tamos nesta disciplina: a TI é a dimensão tecnológica dos Sistemas de Informação.
De acordo com Stair (2016), um Sistema de Informação baseado em computadores (CBIS – Computer Based Infor-
mation System) trata-se de um conjunto de hardware, software, banco de dados, pessoas, procedimentos e 
telecomunicações.
12
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
Figura 1.4 – Representação gráfica de um Sistema de Informação.
pe
ss
oa
s
organizações
tecnologia
Sistemas de
Informações
Hardware
Software
Bancos de dados
Comunicações
Usuários Procedimentos
Legenda: Inter-relacionamentos existentes entre o Sistema de Informações e demais áreas.
Fonte: Elaborada pelo autor (2018).
A infraestrutura de tecnologia é definida como um conjunto de recursos (que inclui todos os componentes de 
um CBIS) usado para coletar, manipular, armazenar e processar dados e informações. Esses são conceitos ele-
mentares de um Sistema de Informação com base em computador.
Quais são as tecnologias de informação que fazem parte do seu dia a dia? 
1.3.1 Hardware 
Hardware é a denominação para todos os equipamentos de um computador usados para realizar atividades de 
entrada, processamento, armazenagem e saída. Os equipamentos de entrada são mouses, teclados, dispositivos 
de escaneamento, leitores de códigos de barras e outros tipos de dispositivos que permitem transmitir/digitar 
dados para o computador.
Os dispositivos de processamento incluem memória do computador, processadores e chips. Quanto mais eficien-
tes os chips e processadores, mais eficiente será o processamento de um conjunto de informações. Já os disposi-
tivos de saída referem-se às telas de computadores e impressoras.
13
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
Hard: Em inglês, quer dizer duro, por isso, a denominação hardware serve para tudo o que é 
equipamento relacionado aos Sistemas de Informação, ou seja, o hardware é o que podemos 
ver ou tocar, o que é tangível.
Glossário
Os componentes de hardware de um sistema de computação incluem diferentes dispositivos de entrada e de 
armazenamento. Um sistema deve organizar e manipular dados, e um Sistema de Informação consegue fazer 
isso pela interação entre uma ou mais unidades centraisde processamento (CPU – Central Processing Unit). 
A figura a seguir demonstra, de forma mais clara, os principais componentes de hardware, que incluem dispositivos 
de entrada e saída, dispositivos de armazenamento primário e secundário e unidade de processamento (CPU).
Figura 1.5 – Componentes de um hardware.
Unidade de 
controle
Unidade
aritmética/lógica
Área de armazenagem de registro
Memória (Armazenamento primário)
Equipamentos de processamento
Equipamentos de comunicação
Armazenamento secundário
Dispositivos 
de entrada
Dispositivos 
de saída
Legenda: Figura com esquema de funcionamento de um hardware.
Fonte: Stair (2016, p. 101).
Agora, vamos entender um pouco de cada conceito apresentado na figura anterior. Uma CPU é constituída de 
uma unidade de controle, uma unidade aritmética (ALU) e áreas de armazenagem de registro (registrador). 
• Unidade aritmética: uma ALU refere-se a um conjunto de componentes que realiza cálculos matemáticos 
e uma série de comparações lógicas. 
14
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
• Área de armazenagem de registro: um registrador é uma área usada para armazenamento temporário de 
instruções de programas e dados – antes, durante e depois da execução por parte da CPU. 
• Unidade de controle: a unidade de controle é uma área que acessa instruções do programa, decodifi-
cando-as e coordenando o fluxo de entrada/saída de uma ALU e dos registradores.
• Armazenamento primário: refere-se ao tipo de armazenamento de dados que a CPU pode acessar dire-
tamente. O armazenamento primário pode ser: 
 » Memória de acesso aleatório (RAM – Random Access Memory): tipo de memória que armazena dados 
temporariamente. Esse é um tipo de memória volátil, ou seja, se o dispositivo for desligado, perdem-se 
as informações.
 » Memória somente de leitura (ROM – Read Only Memory): não é volátil, ou seja, seus dados persistem 
mesmo se o computador for desligado. A ROM armazena dados permanentemente. 
 » Memória cache: é um tipo de memória de alta velocidade que um processador pode acessar de forma 
mais rápida em comparação ao acesso à memória principal. 
• Armazenamento secundário: armazenar dados é fundamental para manter bons sistemas em perfeito 
funcionamento. Para a maior parte das organizações, a melhor solução para armazenar grande quanti-
dade de dados são as opções de armazenagem secundária, que podem ser disco rígido externo, unidade 
USB (pen drive, cartucho de fita etc.). Esses dispositivos secundários podem guardar cópias de dados e 
somente pessoas autorizadas podem ter acesso às informações contidas nesses dispositivos de armaze-
namento secundário. 
• Dispositivos de entrada: são periféricos, como mouse, teclado, dispositivos touch screen, canetas de luz, 
leitores ópticos, scanners, entre outros que enviam informações para “dentro” do computador. 
• Dispositivos de saída: podem ser monitores, telas, impressoras, entre outros dispositivos/periféricos que 
transmitem/imprimem informações para o usuário. 
1.3.2 Software 
Uma vez que os Sistemas de Informação passam a ser computadorizados, é necessário que a lógica de processos, 
atividades ou rotinas sejam representada e executada. Esses comandos lógicos são organizados na forma de 
programas de computador.
Segundo Resende e Abreu (2014), o software é uma sequência de instruções escritas para serem interpretadas 
por um computador com o objetivo de executar tarefas específicas.
Sem o software, o hardware seria inerte. Na verdade, toda inteligência no funcionamento dos computadores está rela-
cionada a algum tipo de software. Este não é tangível e somente pode ser evidenciado pelas suas funcionalidades. 
Stair (2015) classifica software em software de sistema e software de aplicação.
O software de sistema é uma categoria que compreende os softwares que operam tarefas fundamentais para o 
funcionamento do hardware. Nessa categoria, há sistemas operacionais, utilitários e ferramentas de desenvolvi-
mento de software. 
Um sistema operacional é um software cujo objetivo é dispor para os usuários uma forma de utilização do har-
dware, que permite gerenciar o funcionamento do sistema do computador. 
15
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
Em resumo, podemos dizer que um sistema operacional é uma máquina virtual que permite acessar recursos de 
hardware sem que seja necessário possuir o conhecimento detalhado de como os dispositivos funcionam.
Conheça a linha do tempo dos sistemas operacionais acessando <https://www.tecmundo.
com.br/sistema-operacional/2031-a-historia-dos-sistemas-operacionais-ilustracao-.
htm>. Acesso em: 23 jan. 2018. 
A categoria software de aplicação refere-se àqueles que permitem usar a tecnologia para resolver problemas 
específicos. Divide-se em genéricos e personalizados.
Os softwares de aplicação genéricos são os sistemas gerenciadores de banco de dados, sistemas de gestão inte-
grada (ERP – Enterprise Resource Planning), editores gráficos, editores de texto, entre outros de uso geral. 
Já softwares de aplicação personalizados são desenvolvidos sob demanda para atender a necessidades específi-
cas, por exemplo, um sistema desenvolvido para uma escola ou para uma oficina mecânica, entre outros. 
1.3.3 Banco de dados
Os Sistemas de Informação, especialmente os desenvolvidos para o uso empresarial, dependem de estruturas de 
armazenamento e processamento dos dados coletados nas operações de negócios.
As empresas prezam pela segurança de seus bancos de dados, pois estes são uma das peças mais importantes 
dos Sistemas de Informação com base em computadores.
Atualmente, existem no mercado vários programas para armazenar dados, como Oracle, SQL Server, DB2, Post-
greSQL, MySQL, o próprio Access ou Paradox, entre outros.
Um banco de dados é uma coleção organizada de dados, integra um Sistema de Informação e trata-se de uma 
parte relevante, já que é responsável por armazenar dados. É por meio de um banco de dados que as empresas 
conseguem gerar informações e reduzir custos. 
Vamos caracterizar os principais conceitos envolvendo banco de dados, quais sejam: sistema gerenciador de 
banco de dados, o administrador do banco de dados e a hierarquia de dados. 
• Sistema gerenciador de banco de dados: conjunto de programas que manipula e controla um banco de dados. 
• Administrador de banco de dados: é o profissional de SI capacitado para trabalhar com a administração 
de um banco de dados da empresa, definindo usuários, permissões de acesso, entre outras tarefas. 
• Hierarquia dos dados: é a forma como os dados são organizados. A hierarquia é composta por bits, carac-
teres, campos, registros, arquivos e banco de dados.
Um caractere é um bloco básico de construção, que inclui letra maiúscula, minúscula, dígito numérico ou sím-
bolo especial. Um campo pode ser um nome, número, ou qualquer combinação de caracteres que descreve algo. 
https://www.tecmundo.com.br/sistema-operacional/2031-a-historia-dos-sistemas-operacionais-ilustracao
https://www.tecmundo.com.br/sistema-operacional/2031-a-historia-dos-sistemas-operacionais-ilustracao
https://www.tecmundo.com.br/sistema-operacional/2031-a-historia-dos-sistemas-operacionais-ilustracao
16
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
Um registro trata-se de uma coleção de campos de dados que estão relacionados entre si. Já um arquivo é uma 
coleção de registros que podem relacionar-se entre si.
 Os dados são recursos valiosos que uma organização possui. Ao preparar e manter um banco de dados, uma 
empresa deve levar em consideração o seu conteúdo e a sua estrutura. Assim, um banco de dados bem geren-
ciado e bem projetado é uma ferramenta altamente valiosa para auxiliar a tomada de decisões.
1.3.4 Rede de Computadores
Uma rede de computadores é um conjunto interligado de computadores que propicia o compartilhamento de 
recursos e a melhoriado processo de comunicação.
As redes de computadores são compostas tanto pela estrutura física de cabeamento de rede para a comunicação 
entre os computadores quanto pelos recursos humanos que gerenciam essa rede interna em uma organização.
Quando diversas redes são interligadas, podemos enviar uma mensagem entre elas. A mensagem poderá trafe-
gar por diferentes caminhos, os quais temos condições de mapear durante a transmissão.
Figura 1.6 - Rede de computadores.
Legenda: Representação de rede de computadores.
Fonte: Plataforma Deduca (2018).
17
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais 
A rede de computadores poder ser classificada em três categorias de acordo com sua abrangência: LAN, MAN e 
WAN.
• Redes LAN (Local Area Network): são redes locais em que conectam computadores e dispositivos den-
tro de um mesmo ambiente, podendo atingir desde uma sala até um prédio ou um campus universitário.
• Redes MAN (Metropolitan Area Network): são redes metropolitanas com abrangência superior àquelas 
possuídas pelas LANs. Por meio dessa estrutura de dados, conseguimos interconectar, por exemplo, filiais 
de uma empresa em municípios distantes que compartilham essa estrutura para as suas atividades. Atra-
vés dela, podem trafegar voz e dados usando as linhas de transmissão de voz ou fibras ópticas disponíveis.
• Redes WAN (Wide Area Network): são redes de abrangência superior às MANs. São geograficamente 
distribuídas e podem conectar países e continentes. Podem usar as estruturas de satélites ou mesmo de 
cabos submarinos.
A partir do que vimos neste tópico, podemos notar que sem as redes de computador fica muito mais difícil a cir-
culação da informação em uma organização, já que elas reúnem os computadores, distribuindo as informações 
e os recursos para todos de forma rápida e segura.
18
Considerações finais
Nesta unidade, tivemos acesso a muitas informações e conteúdos impor-
tantes sobre os Sistemas de Informação. Vamos retomar os pontos princi-
pais estudados até aqui?
• O Sistema de Informação é um tipo de sistema que coleta, pro-
cessa e transmite informação para um usuário.
• A principal função de um Sistema de Informação é processar dados, 
transformando-os em informações úteis para a tomada de decisão.
• Os dados são códigos que, sozinhos, não possuem significado.
• Informação é um conjunto de dados organizados e processados 
de forma que tenham valor.
• O conhecimento é a capacidade de compreender um conjunto de 
informações.
• A informação deve possuir as seguintes características: precisa, 
completa, clara, veloz, flexível, relevante, confiável, acessível, veri-
ficável e segura.
• Os Sistemas de Informação possuem três dimensões: dimensão 
tecnológica (seus componentes são hardware, software e dados); 
dimensão organizacional (seus componentes são os procedimen-
tos); e dimensão humana (seus componentes são os indivíduos).
• A Tecnologia da Informação é a infraestrutura de um Sistema de 
Informação.
• Hardware é a denominação para todos os equipamentos de um 
computador usados para realizar as atividades de entrada, pro-
cessamento, armazenagem e saída. Os equipamentos de entrada 
são mouses, teclados, dispositivos de escaneamento, leitores de 
códigos de barras etc.
• O software é composto por uma sequência de instruções escritas em 
linguagens específicas, as quais serão interpretadas por um com-
putador com o intuito de executar uma série de tarefas específicas.
Referências bibliográficas
19
RESENDE, Denis Alcides; ABREU, Aline França de. Tecnologia da Infor-
mação Aplicada a Sistemas de Informação Empresariais. 9. ed. São 
Paulo: Editora Atlas, 2014. ISBN digital 9788522490455
REZENDE, D. A. Planejamento de sistemas de informação e informá-
tica: guia prático para planejar a tecnologia da informação integrada ao 
planejamento estratégico das organizações. 4. ed. São Paulo: Atlas, 2011
STAIR, R. M. Princípios de sistemas de informação. São Paulo: Cengage 
Learning, 2016. 
21
2Unidade 2
Tipos de Sistemas de 
Informação 
Para iniciar seus estudos
Caro aluno, aqui estamos em mais uma unidade do nosso curso. Depois 
de tomar contato com conceitos básicos relacionados aos Sistemas de 
Informação, chegou a hora de você conhecer alguns dos seus tipos. Não 
se trata, no entanto, de passarmos por todo o conteúdo da unidade clas-
sificando à exaustão todos os tipos e subtipos de sistemas. Ao invés disso, 
discutiremos as principais características das ferramentas que o gestor de 
uma empresa, por meio da sua indicação e orientação, poderá dispor para 
gerenciar processos de modo assertivo.
Iniciaremos nossos estudos abordando os processos de negócios e situ-
ando-os como peças fundamentais na construção de um Sistema de 
Informação. Discutimos também nesta fase inicial questões relativas à 
vantagem competitiva e sua relação com a correta escolha de um SI. Na 
sequência, as principais características de tipos de ferramentas de gestão 
são exploradas de modo a habilitar você a escolher a mais adequada para 
o caso real.
Leia com atenção todo conteúdo do e-book, aproveite bem suas indica-
ções de leitura e esmere-se na resolução dos exercícios. Assim, logo você 
se tornará referência na disciplina. Sigamos adiante!
22
Objetivos de Aprendizagem
• Discutir a relação entre vantagem competitiva e a escolha ade-
quada do Sistema de Informação.
• Oferecer ao aluno o conceito e as características dos Sistemas de 
Informação Gerencial, Sistemas de Apoio à Decisão e Sistemas de 
Informação Executiva.
• Habilitar o aluno a escolher e propor o Sistema de Informação 
adequado à resolução da situação concreta.
23
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
2.1 Processos de negócios e vantagem competitiva
Para que uma organização possa gerar seus produtos e/ou oferecer seus serviços com excelência, é necessá-
rio que adote e siga procedimentos. Esses procedimentos, quando organizados e disseminados na organização, 
viram processos.
Nas palavras de Stair e Reynolds (2015, p. 6), “processo é um conjunto de tarefas logicamente relacionadas rea-
lizadas para alcançar um resultado definido”. Em um ambiente organizacional, há inúmeros exemplos dessas 
tarefas: no processo de negócio chamado Contabilidade conseguimos identificar, entre outras, contas a pagar e 
contas a receber. No Marketing, acontecem pesquisas de satisfação dos clientes, tratamento de reclamações e 
tratamento de produtos devolvidos, por exemplo. Por fim, no âmbito dos Recursos Humanos, as tarefas caracte-
rísticas incluem contratação de empregados, demissões, rescisões e orientações no local de trabalho.
Alguns desses processos, pela sua natureza, comunicam-se com diversas áreas funcionais da empresa. É difícil 
imaginarmos, por exemplo, que o lançamento de um novo aparelho de telefonia celular deixe de envolver con-
juntamente processos de design, marketing, engenharia do produto e recursos humanos (para eventual contrata-
ção de nova mão de obra especializada), entre outros.
Seria legítimo apontarmos esses processos que superam as barreiras departamentais como 
fatores que motivaram a necessidade de criação de mecanismos de controle integrado da 
organização? 
Parece-nos claro que a eficiência aplicada no planejamento e na execução dos processos de negócio de uma 
organização pode levá-la a conseguir vantagem competitiva em relação a seus competidores. Stair e Reynolds 
(2015) definem vantagem competitiva como um benefício significativo e, de preferência, com incidência de 
longo prazo, para a empresa sobre seus concorrentes. Ela pode – e certamente irá – resultar em produtos de 
maior qualidade, melhor serviço ao cliente e menores custos.
É coerente imaginarmos, então, que as organizações devem usar seus Sistemas de Informação (SI) como ferramen-
tas eficientes para obtenção de vantagem competitiva. A relação entre os SI e vantagem competitiva será mais bem 
explorada adiante. Por ora, foquemosnos aspectos que levam as organizações a buscar vantagem competitiva.
Stair e Reynolds (2015) citam o modelo das cinco forças como meio adequado para explicar tais aspectos. Vejamos:
• Rivalidade entre os concorrentes que já existem: uma empresa fortemente competitiva é aquela que 
arca com altos custos em sua atividade e pouca diferenciação do seu produto com o dos concorrentes, 
que geralmente são numerosos. 
Nesse ambiente, é razoável que seja aplicada muita atenção em como seus recursos são utilizados (gastar 
pouco é tão importante quanto ganhar muito!) e em como alcançar vantagem competitiva por meio de 
investimento em certa inovação que ainda não tenha sido colocada em execução por seus concorrentes. 
Para que o entendimento desse aspecto seja completo, tomemos como exemplo um supermercado que, 
buscando vantagem competitiva, resolve investir em uma forma de evitar que seu cliente enfrente filas, 
possibilitando o pagamento das compras via autoatendimento ou pelo uso de aplicativo de celular.
24
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
• Ameaça de novos concorrentes: a situação ideal para o surgimento de novos concorrentes dá-se em 
setores cuja atividade apresenta custos baixos e para a qual a tecnologia é simples e amplamente dis-
ponível. Um pequeno bar pode ser o exemplo ideal para ilustrar essa situação: o início do negócio não 
demanda grande investimento financeiro e os equipamentos e processos para condução do negócio são 
disponíveis e conhecidos.
Quando a ameaça de novos participantes no mercado é alta, o desejo de buscar e man-
ter vantagem competitiva para dissuadir novos concorrentes é, também, normalmente alta 
(STAIR e REYNOLDS, 2015). 
• Ameaça de produtos e serviços substitutos: quanto menos inovador for um produto, mais propenso estará 
de ter similares no curto prazo. A necessidade de obtenção de vantagem competitiva cresce na mesma pro-
porção em que aumentam a facilidade e a conveniência para a obtenção de um produto substituto.
Por vezes, o apelo do produto similar é tão mais forte que o anterior perde totalmente a vantagem com-
petitiva e cai em desuso. Alguns exemplos incluem as câmeras digitais (em substituição às câmeras tradi-
cionais) e os serviços de vídeo por streaming, que tornaram bastante precária a viabilidade das locadoras 
tradicionais de filmes.
• Poder de barganha dos consumidores: imagine que você coordena uma empresa que fornece seu produto a 
um grande cliente consumidor. Por motivos que você ignora, de uma hora para outra, esse cliente resolve não 
mais adquirir seu produto. Preocupante, para dizer o mínimo. É justamente para fins de retenção de clientes 
(principalmente os mais significativos) que as empresas precisam aumentar sua vantagem competitiva. 
• Poder de barganha dos fornecedores: esse poder de barganha vale também, em certa dimensão, para a 
relação do fornecedor com o cliente consumidor. Tanto neste caso como no anterior, o aumento da van-
tagem competitiva é preponderante para a manutenção sadia das relações de fornecimento e consumo 
de bens e serviços.
Ato contínuo a essa exposição surge uma questão simples: qual a relação direta entre a obtenção da vantagem 
competitiva e os Sistemas de Informação? Ao contrário da pergunta, a resposta não é tão imediata assim.
A descoberta dessa relação começa pela compreensão do conjunto de estratégias que devem ser adotadas para que a 
organização alcance vantagem competitiva em relação ao seu concorrente. Embora não seja objetivo desta unidade, 
entrar em detalhes, é justo mencionar que a execução dessas estratégias se torna factível, em maior ou menor grau, 
pela correta utilização de ferramentas computacionais ou, especificamente, dos Sistemas de Informação.
Para fins de exemplificação, uma dessas estratégias é a necessidade de criação de novos produtos e serviços, a 
fim de que a empresa não perca a participação no mercado e entre em declínio. Se o lançamento de um novo 
produto implica em conhecer os desejos e as necessidades do cliente, então, nada melhor do que começar a 
extrair essas informações de um Sistema de Informação de relacionamento com o cliente, não acha?
Outra estratégia relacionada é a chamada “Liderança em Custo”. Em suma, ela consiste em reduzir as despesas 
em matérias-primas e aumentar a eficiência nos processos de industrialização, de modo a obter preço de venda 
altamente competitivo. Para nos atermos a um exemplo apenas, imagine como um sistema de e-procurement 
25
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
(ferramenta que automatiza processos de cotações entre fornecedores) poderia ajudar na busca pelas melhores 
condições de compra.
Figura 2.1: Coleta de Dados para melhor Decisão Corporativa.
Legenda: A coleta de dados é realizada em diversas bases de dados para análise e utilização, como na tomada de decisões.
Fonte: Plataforma Deduca (2018).
Bem, você já deve estar curioso para conhecer esses sistemas, não é? Agora, o texto segue com a descrição dos 
principais Sistemas de Informação e, ao conhecê-los, esperamos que você adquira habilidade para decidir pela 
ferramenta correta para o tipo de problema que se apresentará em sua vida profissional.
2.2 Sistemas de Informação Gerencial
Foi-se o tempo em que todas as decisões tomadas em uma empresa se baseavam apenas na percepção de uma 
ou duas pessoas. Não que a importância de fatores subjetivos tenha simplesmente desaparecido nesses proces-
sos, mas já é muito difícil conceber uma escolha sem base em informação objetiva.
Neste item do conteúdo, serão abordados os sistemas de informação gerencial. O principal objetivo desses siste-
mas é ajudar os gestores a tomarem decisões mais precisas enquanto conduzem o negócio. Os resultados podem 
ser aumento nas receitas, redução de custos e a realização dos objetivos corporativos (STAIR; REYNOLDS, 2015).
Antes de tratarmos especificamente dos sistemas que dão nome a este item do nosso conteúdo, vale um breve 
registro sobre o que envolve a tomada de uma decisão. Em primeira análise, toma-se uma decisão para resolver 
um problema. Além da experiência no assunto, bom senso e inteligência, o tomador de decisão deve basear-se 
no planejamento estratégico e nos objetivos gerais da empresa, conforme sustentam Stair e Reynolds (2015).
26
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Herbert Simon, economista americano agraciado com o prêmio Turing, em 1975, criou um modelo de três estágios 
que expressa um processo típico de tomada de decisão. Os três estágios incluem informação, projeto e escolha. 
Renomeado mais tarde para estágio da inteligência, essa primeira etapa do processo inclui a identificação de 
potenciais problemas e oportunidades que advêm daquela decisão. 
No estágio de projeto, o tomador da decisão pensa em soluções alternativas para o problema e pondera a viabili-
dade delas. Por fim, é no estágio da escolha que, de fato, a ação é definida. Seria tudo muito simples se a natureza 
dos problemas não variasse tanto.
Stair e Reynolds (2015) concebem um Sistema de Informação Gerencial (SIG) como um organismo que não se 
restringe apenas ao elemento tecnológico e que é decisivo na obtenção de vantagem competitiva.
Um sistema de informação gerencial (MIS, Management Information System) é um conjunto integrado 
de pessoas, procedimentos, bancos de dados e dispositivos que fornece aos gestores e aos tomado-
res de decisão informações que ajudam a alcançar os objetivos organizacionais. Os MISs sempre dão 
às empresas e a outras organizações uma vantagem competitiva, fornecendo as informações certas 
para as pessoas certas em formato e tempo certos (STAIR; REYNOLDS, 2015, p. 443).
Como o próprio nome sugere, um SIG deve atender às necessidades dos gerentes (ou gestores) ao fornecer-lhes 
informações atualizadas das operações regulares da organização. 
Resende e Abreu (2014) sustentam que os SIGs operam com dados agrupadosdas operações da empresa e 
alguns desses dados incluem:
• planejamento e controle de produção: quantidade total produzida;
• faturamento: valor do faturamento do dia, valor acumulado do mês;
• contas a pagar: número de títulos a pagar do dia, valor total a pagar do dia;
• estoque: percentual de estoque distribuído por grupo de materiais.
Os relatórios criados pela ferramenta devem conter base para a tomada correta da decisão e serão tratados mais 
adiante.
Por ora, voltemos nossa atenção para a figura a seguir. Ela nos mostra, entre outras coisas, as fontes que for-
necem dados para processamento no sistema. É bom registrar que, no caso particular, nem todas essas fontes 
podem estar ativas.
Observe como os dados de entrada podem originar-se de fontes internas e externas. Os sistemas executados no 
âmbito da organização (representados na figura como ERP e TPS), junto com suas respectivas bases de dados, são 
identificados como fontes internas.
Vale como exemplo a seguinte situação: o Sistema de Processamento de Transação (SPT ou TPS) realiza e registra 
uma transação de rotina, como um pedido de venda ou uma reserva de hotel feita por funcionário. Esse dado 
serve de insumo para o Sistema de Informação Gerencial gerar informação estruturada para o nível gerencial. 
27
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Sistema de Processamento de Transação: Sistema básico que serve para o nível operacional da 
organização. Realiza e grava as transações de rotina diárias necessárias para conduzir o negócio. 
Glossário
Do ambiente externo, vêm os dados gerados por fornecedores, acionistas e clientes. É natural imaginarmos que 
esses dados serão considerados externos, de fato, se não tiverem passado ainda pelo sistema de processamento 
de transação. Voltemos aos relatórios apresentados na figura a seguir:
Figura 2.2: Fontes das informações gerenciais.
Cadeia de 
fornecimento e 
transações
empresariais
Sistemas
ERP e TPSs
Banco de 
dados 
operacional
Banco de 
dados com 
transações 
válidas
Inserção e 
listas de erros
Sistemas de 
informação
Relatórios detalhados
Relatórios de exceções
Relatórios sollicitados
Relatórios sobre os 
indicadores-chave
Relatórios agendados
Banco de 
dados de 
aplicativos
Bancos de 
dados 
internos 
corporativos
Bancos de 
dados 
externos
Sistemas de 
informações 
especializadas
Sistemas de 
apoio às 
informações 
executivas
Sistemas de 
apoio à 
decisão
Extranet 
corporativa
Intranet 
corporativa
Sistemas de 
apoio à decisão
Funcionários
Legenda: São diversas as fontes de informações em uma organização onde cada 
uma desempenha um papel específico no apoio à gestão.
Fonte: Stair e Reynolds (2015, p. 444).
28
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Eles são divididos em cinco tipos: relatórios detalhados, relatórios de exceções, relatórios solicitados, relatórios 
sobre indicadores-chave e relatórios agendados.
Um desses relatórios merece detalhamento: o relatório de indicadores-chave. Ele resume as atividades críticas do 
dia anterior e normalmente está disponível no início de cada dia de trabalho. Essas atividades críticas reúnem os 
aspectos mais relevantes do negócio e são definidas pelos gestores, primeiros interessados nessas informações.
Não é difícil imaginarmos uma situação em que esse tipo de relatório seria consultado toda manhã pelo gestor: 
as vendas tiveram uma queda sem explicação aparente e recentemente iniciaram retomada. É natural que as 
quantidades relacionadas às vendas componham o relatório de indicadores chaves e que as consultas aos núme-
ros sejam diárias.
Pois bem, assim tratamos os SIGs. É certo que a extensão do assunto extrapola os limites deste texto, mas você já 
tem o bastante para ser capaz de identificar situações em que são necessários na organização. Eles devem atender 
executivos de nível gerencial e apresentam, em relatórios variados, informações em vários formatos e conteúdo.
Passemos agora para o estudo dos Sistemas de Apoio à Decisão.
2.3 Sistemas de Apoio à Decisão
Embora os sistemas voltados aos níveis gerenciais não carreguem em seu nome a expressão “apoio à decisão”, 
não é necessário muito aprofundamento em seus conceitos para entender que eles oferecem suporte de infor-
mação para a tomada de decisão.
De fato, a grande maioria dos sistemas de informação voltados ao mundo corporativo é, em maior ou menor 
grau, voltada a apoiar a decisão de que tem a responsabilidade por ela.
Você já ouviu falar de Raciocínio Baseado em Casos ou RBC? Trata-se de uma aplicação da 
inteligência artificial no processo de tomada de decisões. Sobre o tema, veja o artigo do pro-
fessor Alexey de Carvalho, disponível em http://pgsskroton.com.br/seer/index.php/rcger/
article/viewFile/2638/2509.
O vídeo a seguir oferece demonstração de ferramenta de RBC. disponível em https://www.
youtube.com/watch?v=F9U0DwaTe_I&list=PLOK7WMjGqhjJG_Fzy-nkT-0ng1Mgd5ogS 
(Acesso em: 11 jan. 2018) 
A categoria de sistemas chamados e entendidos como Sistemas de Apoio à Decisão (SAD) apresenta algumas 
peculiaridades que a diferenciam dos outros sistemas. Uma dessas características próprias é a possibilidades de 
estabelecer cenários e simulações de situações que poderiam ocorrer em determinada circunstância da ativi-
dade da empresa.
Ensinam Resende e Abreu (2014) que os SADs utilizam com frequência a questão “e se” para a geração das infor-
mações de simulações e cenários. Alguns exemplos dos cenários incluem:
http://pgsskroton.com.br/seer/index.php/rcger/article/viewFile/2638/2509
http://pgsskroton.com.br/seer/index.php/rcger/article/viewFile/2638/2509
https://www.youtube.com/watch?v=F9U0DwaTe_I&list=PLOK7WMjGqhjJG_Fzy-nkT-0ng1Mgd5ogS 
https://www.youtube.com/watch?v=F9U0DwaTe_I&list=PLOK7WMjGqhjJG_Fzy-nkT-0ng1Mgd5ogS 
29
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
• determinação do local mais adequado para instalação de um ponto de venda;
• elaboração de orçamentos com variações de valores;
• simulação da viabilidade de vender ou não determinado produto, com base na sua rentabilidade.
A possibilidade de criação de simulações específicas e de condições “e se” para a análise do cenário parece bas-
tante útil, não acha?
Stair e Reynolds (2015) nos oferecem algumas características genéricas de um Sistema de Apoio à Decisão. Elas 
podem e devem nos servir de guia para a escolha entre implantar ou não um SAD na organização. Vamos a algu-
mas delas:
• fornece acesso rápido às informações: a decisão de quanto aumentar ou diminuir a produção de um 
item com base em suas vendas deve ser tomada com a rapidez necessária para que a ação não se torne 
obsoleta antes mesmo de ser tomada. Um SAD típico deve ser capaz de informar as quantidades vendidas 
e também de projetar cenários de vendas no curto prazo.
• lida com grandes volumes de dados de diferentes fontes: é difícil rebater o argumento de que, quanto 
maior e mais diversificado o volume de dados, mais exata será a informação por eles gerada. É com essa 
grande quantidade de dados que deve operar um SAD. Você reconhece aqui alguma relação com Big Data?
Big Data: Termo que descreve um grande volume de dados, sejam estruturados ou não, que 
são gerados por empresas e usuários comuns. Essa massa de dados, se corretamente anali-
sada, pode levar a melhores decisões e movimentos comerciais estratégicos. 
Glossário
• flexível: oferece relatórios completos em formato gráfico e textual.
• complexo: realiza análises complexas, sofisticadas e comparações utilizando pacotes avançados de software. 
Nesse ponto, já sabemos a finalidade e as principais características de um SAD. Falta-nos, contudo, conhecer as 
partes que o compõem. Das três partes que serão abordadas, ao menos duas são comuns a outros tipos de siste-
mas. Por isso, será sobre o componente mais específico de um SAD que lançaremos olhar mais atento.
30
Fundamentos de Sistemas deInformação | Unidade 2 - Tipos de Sistemas de Informação
Figura 2.3 – Tomada de decisão.
Legenda: As decisões tomadas por uma organização devem levar em consideração as 
informações coletadas, além de serem classificadas de acordo com as sus consequências.
Fonte: Plataforma Deduca (2018).
Na lição de Resende e Abreu (2014), um SAD é geralmente composto pelo:
• banco de dados e seu sistema gerenciador: este componente é o que contém todos os dados gerados 
na empresa e que passam por um computador. Como armazenamento e recuperação dos dados são 
processos complexos, é mandatória a necessidade de que tais dados sejam manipulados por um software 
Sistema Gerenciador de Banco de Dados (SGBD).
• software gerenciador de interface: esta é a parte do sistema que deverá interagir com o usuário. Seu 
funcionamento dá-se por meio da junção dos seus recursos com os recursos do Banco de Dados e dos 
modelos de dados. 
A interface com o usuário e o meio de comunicação do homem com o computador e muito do sucesso do sis-
tema está ligado à facilidade de acesso a ícones e menus do programa. Comandos de voz e telas sensíveis ao 
toque também costumam conquistar usuários, principalmente os mais jovens.
A combinação de boa funcionalidade com uma interface agradável deverá resultar na alta produtividade de 
quem opera o sistema.
• banco de modelos e seu sistema gerenciador com um motor de inferência: este é o componente 
mais específico de um SAD. Sem ele, a distinção entre um sistema de informação gerencial ficaria mais 
difícil de ser feita.
Resende e Abreu (2014) lembram da necessidade de inserir modelos de gestão próprios da empresa para que o 
SAD atue adequadamente.
31
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Com base em regras “e se” para gerar cenários, o SAD é constituído por um conjunto de modelos 
de gestão capaz de lidar com os dados da empresa por meio de simulações, cálculos, insights, 
resolução de problemas matemáticos, entre outros cenários (RESENDE; ABREU, 2014, p. 191).
Apesar de existirem outras, a distinção mais clara entre um sistema gerencial e um de apoio à decisão é a pos-
sibilidade de o segundo oferecer simulações e construções de cenários. O que estudaremos na sequência serão 
os Sistemas de Informação Executiva, mais comumente conhecidos pela sua sigla da língua inglesa. Avancemos!
2.4 Sistemas de Informação Executiva
Um Sistema de Informação Executiva (Executive Information Systems ou EIS) é a forma mais simples e amigável de 
oferecer informação a executivos da alta administração. É o meio pelo qual o executivo acompanhará resultados 
diários das funções empresariais e, a critério dele, todas as áreas funcionais poderão ser incluídas no relatório.
Por guardarem similaridades com os dois tipos de Sistemas de Informação estudados aqui anteriormente, nossa 
abordagem se aterá às particularidades dos EIS e pontos comuns entre os tipos de SI não serão explorados.
Resende e Abreu (2014) citam três aspectos críticos para a implementação bem-sucedida de um EIS:
• Simplicidade de uso: um gestor de alto escalão definitivamente não se importará se o sistema que ele 
usa foi criado com a mais moderna tecnologia computacional ou se a metodologia de desenvolvimento 
adotada compõe o estado da arte da Engenharia de Software. O que ele espera, de fato, é facilidade de 
uso e informação objetiva e rápida, de preferência dada em grandes caracteres.
Os autores citam que a forma amigável de exibir informações ao executivo efetiva-se por uma série de facili-
dades, tais como recursos de multimídia, apresentação de gráficos, tabelas e quadros, utilização de símbolos, 
ícones e cores.
Também não espere que pessoas do alto escalão se disponham a passar horas em treinamento para habilitarem-
-se a usar o sistema. Enfim, o simples e o objetivo aplicados ao sistema conquistarão a atenção do executivo.
• Orientação para gráficos: um gráfico bem elaborado tem a capacidade de resumir dados e evitar a lei-
tura de valores em excesso. Um bom EIS deve permitir ao usuário executivo a visualização dos dados em 
formato gráfico. A informação apresentada numericamente pode fornecer detalhes do que se deseja 
observar, mas os gráficos sintetizam a massa de dados e a tornam mais rapidamente compreensível.
• Complementação em vez de substituição: um EIS típico aproveita dados já existentes na organização. 
Os autores sustentam que a implantação de um sistema executivo não deve requerer grandes mudanças 
nos Sistemas de Informação Operacionais da empresa, que já estão ativos e consolidados. O EIS não tem 
como função o processamento de dados operacionais das funções empresariais. Ao contrário, ele apenas 
complementa as informações existentes.
• Opções de funcionamento: esta quarta característica da implementação relaciona-se fortemente com 
a anterior e poderia muito bem ser denominada “opções de criação da base de dados”. Podemos imagi-
nar três situações em que os dados são inseridos na base para viabilização do funcionamento do sistema.
A primeira e menos indicada dá-se pela digitação dos dados já existentes e gerados durante o exercício das fun-
ções da empresa. O retrabalho é certo e a propensão a erros é muito grande. A não ser em situação em que não 
exista outra opção, jamais adote essa solução.
A segunda opção – e também pouquíssimo indicada – é a população da base de dados por meio de ferramen-
tas de software que, em períodos predeterminados, fazem a exportação de dados da base principal para a base 
32
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
do EIS. Imagine a situação em que o executivo, ao consultar seu EIS para a tomada de uma decisão importante, 
descobre que os dados que o alimentam ainda não foram atualizados. Situação perigosa, para dizer o mínimo. A 
mesma recomendação feita para o primeiro modo vale para o segundo.
Por fim, a terceira e mais indicada maneira é a de não criar base própria para o EIS, seja por digitação ou por 
exportação de dados. Ao invés disso, os responsáveis pelo desenvolvimento e pela implementação do sistema 
deverão criar um mecanismo para que os dados sejam buscados em uma base comum a todos os sistemas e 
sejam processados e disponibilizados pelo EIS no formato conveniente.
Figura 2.4 – Pirâmide de Sistemas de Informação em cada nível administrativo.
 
 
SA - Automação
SPT - Operacional
SAD e SIG - Gerencial
SAD e SIG 
Gerencial
Legenda: Cada nível possui uma função importante e sua atuação está devidamente definida.
Fonte: Elaborada pelo autor (2018).
Aí está colocada a síntese do que precisamos saber para decidirmos pela adoção ou não de um Sistema de Infor-
mação Executiva. É natural que muitas variáveis devam ser consideradas e ponderadas na decisão, incluindo o 
desejo do executivo. No entanto, sem esse conhecimento básico, não poderíamos sequer sugerir a adoção de um 
Sistema de Informação desse tipo.
E por falar em tipos de SI, é necessário mencionar a existência de muitas (muitas mesmo) outras modalidades de 
sistema. Utilizando critérios de uso em certos níveis organizacionais, em áreas funcionais e a aptidão em suportar 
certos tipos de decisão, os SIs receberam numerosas classificações. Como temos mencionado, não é objetivo 
desta unidade descrevê-las todas.
É necessário registrar, contudo, que sistemas de comércio eletrônico, de planejamento de recursos empresariais, 
de relacionamento com clientes e de gestão do conhecimento, entre outros, compõem a miríade de recursos dos 
quais dispõem as organizações para ajudá-las a gerir seu negócio e para dar suporte ao tomador de decisão com 
informação de qualidade.
33
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Embora a variedade de ferramentas seja importante no contexto, é a habilidade do gestor do sistema (entendido 
em sentido amplo, pois gerir um sistema pode incluir desde ações de desenvolvimento até manutenção diária) 
que será decisiva parao sucesso do investimento. E nunca é demais lembrar: esse gestor é você!
34
Considerações finais
Nesta unidade, foram abordados os Sistemas de Informação Gerencial, 
Sistemas de Apoio à Decisão e os Sistemas de Informação Executiva, além 
de aspectos relacionados a processos de negócios e vantagem competi-
tiva. Em resumo, você teve contato com os seguintes temas:
• Processos de negócios e vantagem competitiva: processo é 
um conjunto de tarefas logicamente relacionadas realizadas para 
alcançar um resultado definido. Em um ambiente empresarial, há 
vários exemplos de processos de negócio: contabilidade, marke-
ting e recursos humanos são alguns deles. A diversidade de sis-
temas de informação deve suprir as necessidades específicas de 
cada um deles. 
As organizações usam os sistemas de informação para a obtenção 
de vantagem competitiva. Alguns fatores explicam a necessidade 
de obter-se tais vantagens: rivalidade entre os concorrentes que 
já existem, ameaça de novos concorrentes, ameaça de produtos 
e serviços substitutos, poder de barganha dos consumidores e 
poder de barganha dos fornecedores.
• Sistemas de Informação Gerencial: um sistema de informação 
gerencial (MIS, Management Information System) é um conjunto 
integrado de pessoas, procedimentos, bancos de dados e disposi-
tivos que fornece aos gestores e aos tomadores de decisão infor-
mações que ajudam a alcançar os objetivos organizacionais. Os 
dados de entrada podem originar-se de fontes internas e exter-
nas e as informações geradas servem como base decisória para 
gerentes de todas as áreas funcionais da organização.
• Sistemas de Apoio à Decisão: a categoria de sistemas chamados 
e entendidos como Sistemas de Apoio à Decisão (SAD) apresenta 
algumas peculiaridades que a diferenciam dos outros sistemas. 
Uma dessas características próprias é a possibilidades de esta-
belecer cenários e simulações de situações que poderiam ocorrer 
em determinada circunstância da atividade da empresa. Algumas 
particularidades caracterizam um SAD: acesso rápido às informa-
ções, operação com grandes volumes de dados de diferentes fon-
tes, flexibilidade e complexidade funcional.
35
• Sistemas de Informação Executiva: um Sistema de Informação 
Executiva (Executive Information Systems ou EIS) é a forma mais sim-
ples e amigável de oferecer informação a executivos da alta admi-
nistração. É o meio pelo qual o executivo acompanhará resultados 
diários das funções empresariais e, a critério dele, todas as áreas 
funcionais poderão ser incluídas no relatório.
Além desses abordados, outros sistemas compõem a variedade de recur-
sos dos quais dispõem as organizações para ajudá-las a gerirem seu 
negócio, incluindo sistemas de comércio eletrônico, sistemas de planeja-
mento de recursos empresariais, sistemas de relacionamento com clien-
tes e sistemas de gestão do conhecimento.
Referências bibliográficas
36
RESENDE, D. A.; ABREU, A. F. de. Tecnologia da Informação Aplicada a 
Sistemas de Informação Empresariais. 9. ed. São Paulo: Editora Atlas, 
2014. ISBN digital 9788522490455.
STAIR, R. M.; REYNOLDS, G. W. Princípios de Sistemas de Informação: 
Tradução da 11a edição norte-americana. 3. ed. brasileira, Cengage Lear-
ning, 2015. 752 p. ISBN 9788522118625.
38
3Unidade 3
Sistemas de Informação em 
Negócios 
Para iniciar seus estudos
Você está iniciando o estudo da terceira unidade da disciplina Fundamen-
tos de Sistemas de Informação. Preparado para mais questões, aponta-
mentos e reflexões? 
Esta unidade trata de sistemas de inteligência de negócios, comércio ele-
trônico e sistemas para gestão de informação e conhecimento. Esses siste-
mas elevam a competitividade das empresas e aumentam sua eficiência. 
Empresas informadas saem na frente da concorrência em qualquer seg-
mento de negócio. Está preparado para sair na frente? Então, vamos lá!
Objetivos de Aprendizagem
• Compreender sobre os sistemas de informação e as suas vanta-
gens competitivas.
• Conhecer o comércio eletrônico e o comércio móvel.
• Saber sobre os sistemas de gestão de conhecimento e informação 
especializada
39
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
3.1 A Informação e os Sistemas 
O mundo dos negócios está cada vez mais competitivo e desafiador, além de exigir constante inovação e a remo-
delagem de um mesmo negócio. Nesse cenário, a informação e o conhecimento têm papel fundamental no 
direcionamento estratégico das empresas.
O nosso desafio é responder a três questões importantes: 1) Como as empresas podem explorar os sistemas de 
informação para negócios e estarem à frente da concorrência? 2) Como transformar imensos volumes de dados 
armazenados em informações úteis para a tomada de decisão? 3) Como as tecnologias e o comércio eletrônico 
podem ajudar a remodelar um negócio?
São respostas a esses questionamentos que você verá agora.
3.2 Vantagem Competitiva 
Para as empresas, a gestão da informação sobre mercado, concorrência, pesquisa e desenvolvimento por meio 
de sistemas de informação resulta em vantagem competitiva. 
Vantagem Competitiva: Termo que designa a superioridade de longo prazo de uma empresa 
em relação aos seus concorrentes. Pode resultar em produtos de qualidade superior, melho-
res serviços e custos mais baixos. 
Glossário
Mas você sabe por que as empresas devem investir em estratégias e sistemas para obter vantagem? Segundo 
Stair e Reynolds (2015), os fatores que motivam as empresas a investirem em vantagem competitiva são a rivali-
dade entre concorrentes existentes; a ameaça de novos concorrentes; a ameaça de produtos e serviços substitu-
tos; e o poder de barganha dos compradores dos fornecedores.
Uma organização utiliza o seu sistema de informação como auxílio para buscar tal vantagem competitiva. Um 
bom exemplo é o caso de um restaurante de entrega de comida, para o qual você, como cliente, sempre liga, 
e todas as vezes tem que fornecer o seu endereço e telefone. Já um restaurante que faz uso de um sistema de 
informação mantém os dados do cliente cadastrados; assim, quando esse cliente liga, não precisa repetir todos 
os dados. Esse restaurante, portanto, está em vantagem (competitiva) em relação ao primeiro. 
Outro fator que contribui de forma considerável para uma empresa é a presença, em seu quadro de funcionários, 
de pessoas com formação em desenvolvimento para dispositivos móveis. Essa é a grande tendência do mercado 
atual; além disso, profissionais entendidos de redes sociais alavancam a vantagem competitiva. 
Uma empresa que obtém vantagem competitiva sempre certifica-se de que o seu departamento de SI ofereça 
apoio às metas e às estratégias da organização. 
Por fim, não se trata do quanto uma empresa gasta com um sistema de informação, mas sim de como gerencia 
os seus investimentos em tecnologia. 
40
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
Para pensarmos sobre essa função, podemos lançar perguntas como: os investimentos são aplicados de forma 
certa? Os profissionais desenvolvem os programas certos? Os recursos são atuais?
O quadro a seguir, retirado do livro “Princípios de sistemas de informação” (STAIR; REYNOLDS, 2016), demonstra 
como algumas empresas fazem uso da tecnologia para alcançarem vantagem competitiva.
Quadro 3.1 – Exemplos de vantagem competitiva nas empresas.
Empresa Comercial O uso competitivo de sistemas de informação
Gillette Produtos de barbear Faz o uso de sistemas de fabricação 
computadorizados e avançados, desenvolvidos para 
produzirem produtos de alta qualidade a baixo custo.
Walgreens Lojas de 
medicamentos e 
conveniência
Faz o uso de sistemas de comunicação por satélite, 
desenvolvidos para conectarem as lojas locais com 
sistemas de computador centralizados.
Wells Fargo Serviços financeiros Fez uso de sistemas de informação para desenvolver 
banco 24 horas, caixas eletrônicos, investimentos e 
aumentar o atendimento ao cliente.
Legenda: Vantagem competitiva.Fonte: Stair e Reynolds (2016, p. 68).
Diante do cenário atual, em que cada vez mais surgem novas tecnologias, é possível alguma 
empresa/negócio viver sem nenhum tipo de sistema de informação? 
Agora que entendemos o conceito de vantagem competitiva, vamos conhecer algumas ferramentas e sistemas 
para incrementar os sistemas de informação para negócios. 
3.3 Business Intelligence
Business Intelligence (BI) pode ser traduzido como inteligência nos negócios. A finalidade do BI é que o tomador 
de decisões tenha, a qualquer momento, todas as informações relevantes para suportar um processo de decisão.
Inteligência Empresarial, ou Business Intelligence, é um termo do Gartner Group. O conceito surgiu na década 
de 1990 e descreve as habilidades das empresas para levantar dados e informações para uso da alta gerência, 
transformando a tomada de decisão mais assertiva por estar pautada em informações. Portanto, o BI refere-se ao 
processo de coleta, análise organizacional, disseminação e monitoramento de dados e informações que possam 
oferecer suporte para a tarefa de gestão de negócios.
https://pt.wikipedia.org/wiki/Gartner_Group
41
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
As organizações tipicamente coletam informações com a finalidade de analisarem o ambiente empresarial, 
somando a essas informações as pesquisas de marketing, industriais e de mercado, além de análises competiti-
vas, podendo assim direcionar e monitorar o seu nicho de mercado específico. 
Organizações competitivas adquirem inteligência na proporção em que ganham robustez em vantagem com-
petitiva, considerando tal inteligência como o aspecto central para competir em alguns mercados. É comum que 
os coletores de BI tenham as fontes primárias de informação dentro das suas empresas. As fontes secundárias 
de informações incluem aspectos como necessidades do consumidor, processo de decisão do cliente, pressões 
competitivas, condições industriais relevantes, aspectos econômicos e tecnológicos e tendências culturais.
O ambiente de BI baseia-se em um modelo global de apoio à decisão com capacidade para a elaboração e a imple-
mentação das estratégias da empresa. Os gestores passam a ser apoiadores no processo de identificação de opor-
tunidades e ameaças, aumentando a capacidade de responder com rapidez a mudanças exigidas pelo mercado. 
O BI obedece à estrutura dos sistemas de informação gerencial e é destinado a gerentes e gestores de maior nível 
hierárquico; desse modo, deve ser um sistema de fácil uso e interação.
O BI pode ser aplicado aos negócios para aumentar o valor agregado em vários aspectos:
• no monitoramento de indicadores e na progressão de metas;
• na análise de dados;
• nos relatórios corporativos;
• na colaboração, mediante compartilhamento eletrônico de dados e informações em diferentes grupos 
de trabalho, dentro e fora da empresa ou do departamento;
• na gestão do conhecimento, por meio de estratégias e práticas para identificar, criar, representar, distri-
buir e disponibilizar as percepções e experiências relacionadas ao conhecimento dos negócios.
O grande benefício que o BI traz para uma empresa é o aumento de sua capacidade de fornecer informações 
precisas no momento certo, incluindo uma visão em tempo real do desempenho da empresa de modo geral e de 
suas partes individuais.
Assista a um vídeo de 60 segundos que mostra uma ferramenta de BI em ação: <https://
www.youtube.com/watch?v=RzH71cNmaXc>.
Para entender melhor o conceito de BI, tenha em mente que tudo começa com a coleção de dados contidos no 
data warehouse. O data mining, por sua vez, “minera” os dados, extraindo informações relevantes. Vamos enten-
der esses conceitos agora.
https://pt.wikipedia.org/wiki/Marketing
https://www.youtube.com/watch?v=RzH71cNmaXc
https://www.youtube.com/watch?v=RzH71cNmaXc
42
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
3.3.1 Data Warehouse 
Um data warehouse é um banco de dados que contém dados históricos resumidos em diferentes níveis de deta-
lhamento. É uma coleção de dados orientada por assuntos e integrada, cujo objetivo é oferecer suporte aos pro-
cessos de tomada de decisão.
Figura 3.1: Sistema data warehouse.
Legenda: Os componentes de um Data Warehouse.
Fonte: Plataforma Deduca (2018).
Essa base de dados é usada para a geração de relatórios e para análises gerenciais, e é mantida separada do 
banco de dados dos sistemas da empresa.
Os usuários desse ambiente geralmente são pessoas ligadas às áreas estratégicas da empresa, e esperam encon-
trar informações que sejam importantes para o processo de tomada de decisões. Entre estas, temos: 
• valor e quantidade das vendas por tempo e produto;
• dados financeiros e contábeis, que envolvem contas a receber, a pagar e estoques; 
• dados de Recursos Humanos, tais como idade, características e desempenho dos funcionários;
• comparativos de custos; 
• dados sobre logística e distribuição de produtos;
• dados sobre o marketing da empresa; 
• dados da concorrência. 
43
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
Em razão do grande número de possibilidades de análise, os usuários podem ficar um pouco confusos com os 
dados contidos em um data warehouse. Nesse contexto, é necessária uma ferramenta que auxilie na análise dos 
dados, e essa ferramenta é o data mining. 
Veja agora as principais questões relacionadas a um data warehouse: 
• Principal função: dispor informações para gerar novos conhecimentos que a empresa possa usar de 
forma estratégica. 
• O que se espera encontrar: informações sobre empresa e concorrentes. 
• Tecnologias associadas a um data warehouse: Data Mining, OLAP (processo analítico), Banco de Dados 
Multidimensional (MDD), OLTP (Processos de transações on-line), Data Mart, Repositório de Dados Ope-
racional (ODS). 
3.3.2 Data Mining
Data mining (mineração de dados) é a exploração e a análise das grandes quantidades de dados para identificar 
modelos e regras relevantes. Com um data mining, é possível que uma empresa compreenda melhor os seus 
clientes ou que compare as suas vendas mensais.
Um data mining descobre padrões ocultos nos dados, e esses padrões, se forem entendidos, permitem, por exem-
plo, antecipar o comportamento de compras de clientes; permitem ainda que a empresa se prepare para o lan-
çamento de novos produtos ou serviços.
O data mining emprega tecnologias de inteligência artificial com o objetivo de analisar imensos volumes de dados 
armazenados em um data warehouse. Portanto, podemos definir o data mining como a extração automática de 
dados sobre padrões, tendências, associações, mudanças e anomalias previamente não identificadas.
3.3.3 OLTP e OLAP
As siglas OLTP e OLAP são muito usadas no contexto do Business Intelligence (BI). Contudo, ambas possuem con-
ceitos diferenciados e são aplicadas em contextos diferentes. 
OLTP, do inglês “On-line Transaction Processing”, refere-se aos sistemas transacionais (sistemas operacionais das 
organizações). São usados para processar dados de rotina gerados diariamente por meio dos sistemas de infor-
mática da empresa, e oferecem suporte às funções de execução do negócio organizacional. 
De forma mais resumida, OLTP são sistemas que se encarregam de registrar as transações existentes em deter-
minada operação organizacional. Exemplo: sistema de transações bancárias que registra as operações realizadas 
por um banco ou por cartões de crédito. 
Já OLAP, do inglês “On-line Analytical Processing”, refere-se à capacidade de analisar grandes volumes de infor-
mações de diferentes perspectivas dentro de um data warehouse. O OLAP faz referência às ferramentas analíticas 
que são usadas no BI para visualizar informações gerenciais e oferecer suporte para as funções de análises do 
negócio organizacional. 
Para uma melhor compreensão, veja o quadro a seguir com as diferenças entre OLTP e OLAP: 
44
Fundamentos deSistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
Quadro 3. 2 - Comparativo de OLPT e OLAP.
OLTP OLAP
Foco Nível operacional da organização, 
objetiva a execução operacional 
do negócio. 
Nível estratégico da organização, 
objetiva a tomada de decisão e a 
análise empresarial.
Armazenamento O armazenamento é feito em 
modelo relacional normalizado, 
otimizado para a utilização 
transacional, sendo que os dados 
possuem altos níveis de detalhes. 
É feito em estruturas do DW com 
otimização no desempenho de 
grandes volumes de dados. Os 
dados possuem altos níveis de 
sumarização (resumo). 
Abrangência É usado por técnicos e analistas. É usado por gestores e analistas 
para a tomada de decisões. 
Permissão nos 
dados
São permitidas leitura, inserção, 
modificação e exclusão de dados.
É permitido apenas inserir e ler 
dados, sendo que, para o usuário 
final, está disponibilizada apenas a 
leitura.
Legenda: OLTP X OLAP
Fonte: Elaborado pela autora (2018).
3.3.3 Banco de dados multidimensionais (MDD) 
Um sistema de banco de dados multidimensional serve para armazenar suas informações como um cubo 
n-dimensional. Ou seja, os dados estão armazenados em matrizes e estas podem ser visualizadas lado a lado, de 
forma que é possível lidar simultaneamente com diversas visões do dado que está sendo analisado. 
Mais especificamente, a modelagem multidimensional – ou dimensional, como às vezes é chamada – consiste na téc-
nica de modelagem de banco de dados para auxiliar as consultas do data warehouse nas mais diversas perspectivas. A 
visão multidimensional proporciona mais intuição no processamento analítico por meio das ferramentas OLAP. 
3.3.4 Data mart 
Os data marts são bancos de dados departamentais (por unidades de negócio) que podem mostrar visões rela-
cionais ou multidimensionais. Exemplo: um DBM (Data Base Marketing) que tem como objetivo armazenar os 
dados referentes aos clientes em potencial de uma empresa, permitindo traçar as estratégias de marketing por 
meio de identificação de perfis dos clientes. 
45
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
3.3.5 Repositório de Dados Operacionais(ODS) 
Um ODS é um repositório de dados centralizado que contém informações acessíveis às aplicações corporativas. 
Essas informações referem-se aos processos operacionais do negócio da empresa. Os processos, por sua vez, 
estão baseados em banco de dados único e ficam centralizados, sendo orientados aos negócios da empresa. 
A função do ODS é reunir as informações que se encontram distribuídas pela empresa e disponibilizá-las em um 
repositório centralizado e em menor prazo quando solicitadas.
Agora que aprofundamos o nosso conhecimento em BI, vamos conhecer os sistemas especialistas.
3.4 Sistemas de Informação de Negócio Especializados 
Além de sistemas como ERP, SPT e SAD, como vimos na unidade anterior, as organizações também dependem 
de sistemas especializados. Muitas delas fazem uso de sistema de gestão do conhecimento (SGC ou Knowledge 
Management System), inteligência artificial, sistemas especialistas e realidade virtual. Acompanhe agora a defini-
ção desses conceitos: 
Sistema de Gestão do conhecimento: o SGC é um sistema de acompanhamento de programas de trei-
namento on-line e seu objetivo é agilizar o planejamento e o controle sobre a transferência de conheci-
mento em projetos. 
Inteligência Artificial (IA): é o campo no qual um sistema adquire características da inteligência humana. 
Exemplo: um sistema que auxilia médicos nos diagnósticos de exames/doenças. A IA inclui vários campos 
secundários, conforme consta na figura a seguir.
Figura 3.2: Principais elementos da inteligência artificial.
Legenda: Elementos da inteligência artificial.
Fonte: Adaptada de Stair e Reynolds (2016, p. 27). 
46
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
A robótica é a área na qual as máquinas realizam tarefas complexas e rotineiras, por exemplo, a soldagem de 
carros como parte das atividades de uma montadora de veículos. Já os sistemas de visão permitem que robôs e 
outros equipamentos vejam, armazenem e processem imagens virtuais. O processamento de linguagem neural 
envolve computadores capazes de entender e agir com comandos verbais ou escritos (seja inglês, português, 
espanhol ou outros idiomas). Os sistemas de aprendizagem, por sua vez, possibilitam que os computadores 
aprendam a partir de erros ou experiências passadas; exemplos: jogar games, tomar decisões empresariais. A 
rede neural é um ramo da IA que permite que computadores reconheçam e atuem de acordo com tendências e 
padrões. Algumas empresas usam as redes neurais para destacarem as tendências e otimizarem o retorno sobre 
os seus investimentos. 
Sistemas especialistas: fornecem ao computador capacidade de sugerir e atuar como alguém especiali-
zado em algum campo. O valor desses tipos de sistemas é permitirem às organizações capturarem e usa-
rem a sabedoria de especialistas/experts. Assim, anos de experiência e conhecimentos não são perdidos 
quando um especialista vai a óbito ou transfere-se da empresa. A coleta de dados, os procedimentos e as 
regras devem ser seguidos para a obtenção do resultado esperado. Esses dados coletados ficam contidos 
na base de conhecimento do sistema especialista. Uma base de conhecimento é um conjunto de regras, 
dados, procedimentos e relações que deve ser seguido para alcançar o valor esperado. 
Para entender melhor o conceito de um sistema especialista, vamos imaginar um diagnóstico médico. Tal tarefa 
exige conhecimento específico, dessa forma, são necessárias pessoas capacitadas para realizarem o diagnóstico 
médico, ou seja, pessoas especialistas. Para que essas atividades sejam realizadas por outras pessoas que não 
detêm tal conhecimento, é preciso que exista os sistemas especialistas. Esses sistemas têm o objetivo de substi-
tuir o homem na solução de problemas específicos, usando para isso o conceito de inteligência artificial, ou seja, 
os sistemas especialistas (SE) são uma das técnicas da IA.
Um SE apresenta as seguintes vantagens: 
• Melhora a produtividade, pois é mais rápido que pessoas. 
• Otimiza a acessibilidade, pois torna o conhecimento acessível em diversos locais. 
• Substitui especialistas, fazendo com que a informação permaneça indefinidamente, não importando se 
a pessoa especialista está no local ou não. 
Realidade virtual e multimídia: realidade virtual e multimídia são tipos de sistemas especializados usa-
dos por muitas organizações. A realidade virtual é uma simulação de um ambiente real ou imaginário 
que possa ser vivido em três dimensões. Anteriormente, a realidade virtual referia-se à realidade virtual 
imersiva, ou seja, aquela em que o usuário é imerso em um mundo 3D artificial, gerado pelo computador. 
Porém, a realidade virtual também se refere às aplicações não imersas em sua totalidade, por exemplo, 
navegação controlada por um mouse em um ambiente 3D sobre um monitor gráfico. Atualmente, uma 
nova forma de realidade virtual é a realidade aumentada, que tem o potencial de sobrepor dados digitais 
a imagens ou a fotos reais. Dispositivos de entrada, como luvas digitais e joysticks, permitem que o usuá-
rio possa navegar em um ambiente virtual e interagir com os objetos virtuais. A experiência é aprimorada 
com o uso de sons, reconhecimento de voz e outras tecnologias.
Agora que conhecemos os sistemas especialistas, vamos ver como o processo de venda foi remodelado nos últi-
mos anos, transformando a experiência de compras presencial para uma compra on-line. Vamos conhecer sobre 
o comercio eletrônico.
47
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
3.5 Comércio Eletrônico 
O comércio eletrônico é a realização de atividades comerciais feitas por meio de computadores, ou seja, qualquer 
transação comercial executada entre empresas. 
As atividades empresariais candidatas àconversão ao comércio eletrônico são as que envolvem os trabalhos com 
impressão em papel ou que são inconvenientes para os clientes. 
Por que aprender sobre comércio eletrônico? 
Podemos apresentar o comércio eletrônico em diferentes categorias. Observe: 
• Comércio eletrônico negócio a negócio (B2B - Business-to-Business): o comércio eletrônico negócio a 
negócio é um subconjunto do comércio eletrônico em que todos os participantes envolvidos são empre-
sas. É bastante útil para conectar parceiros de negócios. Uma empresa pode usar o comércio eletrônico 
tanto para comprar mercadorias ou serviços de seus fornecedores como para vender os seus produtos. 
Figura 3.3: O comércio eletrônico.
Legenda: Representação do comercio eletrônico e sua diferentes interações.
Fonte: Plataforma Deduca (2018).
48
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
• Comércio eletrônico negócios a clientes (B2C - Business-to-consumer): é uma forma de comércio eletrô-
nico em que os clientes tratam diretamente com a empresa, sem intermediários. O B2C cresce cada vez 
mais rápido e a razão para isso é que muitos bens e serviços são mais baratos quando são adquiridos pela 
internet. Mais do que ferramenta para fazer pedidos, a internet é uma ótima forma de comparar preços e 
características de diversos produtos e serviços. 
• Comércio eletrônico cliente a cliente (C2C - Consumer-to-Consumer): é um subconjunto de comércio ele-
trônico que envolve transações eletrônicas entre clientes por meio de um terceiro que facilita esse processo.
Quadro 3.3: Diferenças entre os tipos B2B, B2C e C2C.
Fatores B2B B2C C2C
Valor de venda. Milhares ou milhões de 
dólares.
Dezenas ou centenas 
de dólares. 
Dezenas de dólares.
Duração do 
processo de vendas.
Dias para meses. Dias para semanas. Horas para dias.
Número de 
tomadores de 
decisão envolvidos.
Diversas pessoas, até uma 
dúzia ou mais.
Uma ou duas. Uma ou duas.
Uniformidade da 
oferta.
Tipicamente uma oferta 
uniforme de produto.
Oferta de produto 
mais customizado.
Oferta de produto 
simples, um de cada 
tipo.
Complexidade 
do processo de 
compra.
Extremamente complexo, 
muito espaço para 
negociação sobre preço 
pagamento, entrega, 
quantidade, qualidade 
opções e características. 
Relativamente 
simples, discussão 
limitada sobre as 
opções de preços, 
pagamento e 
entrega.
Relativamente simples, 
discussão limitada 
sobre as opções de 
pagamento, entrega 
e negociação de alto 
preço. 
Motivação para a 
venda.
Acionado por uma decisão 
ou necessidade de 
negócio.
Acionado por 
uma necessidade 
ou emoção do 
consumidor 
individual.
Acionado por 
uma necessidade 
ou emoção do 
consumidor individual.
Legenda: B2B, B2C e C2C.
Fonte: Adaptado de Stair e Reynolds (2016, p. 360).
De tudo o que vimos até aqui, devemos destacar que a compreensão do comércio eletrônico é importante, pois 
trata-se de um assunto que transforma muitas áreas e carreiras. Um exemplo de mudança é a forma como as 
empresas interagem com seus fornecedores e clientes, usando a internet como grande aliada. Nesse sentido, 
o comércio eletrônico é, sem dúvidas, umas das aplicações de internet que apresenta futuro mais promissor. O 
comércio eletrônico abrange a compra e a venda de produtos e serviços pela internet. Podemos citar exemplos 
de algumas empresas do Brasil que operam com o comércio eletrônico, são elas: Lojas Americanas, Ponto Frio, 
Lojas Marisa, Ford, Fiat e muitas outras.
49
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
As principais razões para usuários fazerem compras on-line são: 
• não enfrentar filas; 
• poder fazer compras em qualquer horário; 
• não precisar enfrentar trânsito ou preocupar-se com estacionamento; 
• receber o produto em casa. 
Até pouco tempo, empresas apenas criavam sites para vender os seus produtos. Atualmente, 
com a disponibilidade de smartphones e tablets, algumas empresas também lançam apli-
cativo de vendas para dispositivos móveis. Assim, o usuário pode baixar o aplicativo e fazer 
a compra por meio deste, sem a necessidade de abrir o navegador e acessar o site cada vez 
que for realizar uma compra. 
Contudo, ao disponibilizar um site comercial, seja ele feito para computador ou para dispositivo móvel, alguns 
fatores que envolvem o mercado da internet devem ser considerados: É preciso controlar o estoque, pois qual-
quer um dos mais de 600 milhões de internautas pode desejar comprar algum produto colocado à venda; e, 
se a procura é grande, pode acontecer de o site efetuar a venda e acabar demorando para entregar o produto, 
gerando problemas legais e também dúvidas sobre a idoneidade do site. 
Ainda que a loja tenha o produto disponível para pronta-entrega, deve-se considerar que o usuário pode morar 
em um local que seja de difícil acesso. Em vista disso, o comércio eletrônico impulsionou um grande desenvol-
vimento das empresas de logística em todo o mundo, para que fosse (e ainda seja) possível atender aos usuários 
nas mais diversas regiões. 
Por essas e outras questões, um sistema de informação de comércio eletrônico deve incluir todas as funções 
internas e externas das organizações, que são marketing, financiamento, produção, vendas e negociação. 
O comércio eletrônico não deve ser visto como um fator à parte da empresa, mas sim como uma parte que inte-
gra o processo de negócio dela. O comércio eletrônico auxilia as organizações a responderem de forma mais 
efetiva às necessidades dos seus clientes, bem como permite ter melhor fluxo interno com os fornecedores. 
O comércio eletrônico alterou ainda a maneira como os negócios são dirigidos atualmente, e a tendência é que 
esse tipo de comércio continue crescendo cada vez mais.
O comércio eletrônico é, portanto, um sistema que permite alavancar as vendas de uma empresa, já que alcança 
um número mais expressivo de clientes. Contudo, as empresas envolvidas no uso de comércio eletrônico devem 
ser cautelosas, a fim de evitarem que regras sejam violadas, por exemplo, vender produtos impróprios ou proibi-
dos por leis municipais, estaduais ou federais.
50
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
3.5.1 Comércio Móvel
O comércio móvel é um segmento do comércio eletrônico que cresce rapidamente. O comércio móvel está rela-
cionado com o uso de dispositivos móveis e sem fio. 
Figura 3.4: O comércio móvel.
Legenda: Representação do comercio móvel.
Fonte: Plataforma Deduca (2018).
Nesse sentido, espera-se que o número de sites móveis continue aumentando em função dos avanços das tec-
nologias sem fio e do desenvolvimento de novos aplicativos, além da disponibilidade de equipamentos mais 
baratos (STAIR, 2016). 
Algumas empresas criaram sites específicos para usuários de dispositivos móveis. Além de usar o site para ven-
das, organizações podem usá-los para fazer a integração com redes sociais.
3.5.2 Vantagens do comércio eletrônico e móvel 
A utilização de um comércio eletrônico ou móvel possibilita que as organizações reduzam os custos para realiza-
rem seus negócios, entre outras vantagens, as quais veremos a seguir.
• Redução de custo: com o comércio eletrônico/móvel, é possível reduzir etapas que consomem esforço e 
tempo no processo de pedidos e entregas. Com isso, as organizações podem reduzir as necessidades de 
estoque e armazenamento. 
• Aceleração do fluxo de bens e informações: quando as organizações se conectam por meio do comércio 
eletrônico, os fluxos de informações são acelerados, e isso ocorre devido às conexões e comunicações 
que já estão estabelecidas. As informações fluem facilmente entre o comprador e vendedor. 
51
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
• Aumento na precisão: quando se permite que compradores forneçam especificações e informações de seus 
pedidos, permite-se eliminar erros humanos no processo de inserção de dados por parte do fornecedor.• Melhora do serviço ao consumidor: o consumidor pode receber detalhes da sua compra, data de entrega 
e nota fiscal por e-mail, o que ajuda a fidelizá-lo. Além disso, quando a empresa é pontual quanto às 
datas de entregas, acaba eliminando o desejo do cliente de procurar por outras empresas, já que ele ficará 
satisfeito com a fidelidade da empresa em que comprou seus produtos ou serviços. 
3.5.3 Os desafios do comércio eletrônico 
Quando uma empresa decide converter seu processo de negócio tradicional em processo de comércio eletrô-
nico, ela enfrenta muitos desafios. Por isso, nem todos os empreendimentos na área de comércio eletrônico con-
seguem ser bem-sucedidos. O primeiro desafio, de acordo com Stair e Reynolds (2016), refere-se a questões de 
privacidade: 
Enquanto dois terços das pessoas compraram ao menos um item online e o volume das compras 
em dólares continua a crescer, cerca de um terço de todos os adultos usuários da internet não 
comprará nada pela internet em razão das preocupações quanto à privacidade ou falta de con-
fiança nesse tipo de comércio (STAIR; REYNOLDS, 2016, p. 367).
Entre os medos dos clientes, podemos citar o roubo de identidade (uso de informações pessoais sem permissão) 
e a quebra de sigilo, o que pode comprometer as informações dos compradores. 
Figura 3.5: Sigilo e proteção dos dados do usuário.
Legenda: Representação da segurança dos dados dos usuários do comercio eletrônico.
Fonte: Plataforma Deduca (2018).
Outro desafio diz respeito a superar a falta de confiança do cliente. Muitos clientes deixam de comprar on-line 
porque não confiam nos vendedores on-line. As dúvidas são: o produto será mesmo enviado? Essa empresa é 
séria? Se houver problemas com o produto ou com os serviços, quem resolverá? 
52
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
Os comerciantes devem criar estratégias que possam construir a confiança em seus clientes. As empresas devem 
demonstrar para os seus clientes o desejo de construir um relacionamento forte, oferecendo programas de fide-
lidade. Pode-se também exibir, no site, todas as certificações de segurança que a empresa tiver.
O comércio eletrônico e móvel oferece muitas oportunidades e permite que as empresas possam vender em um 
mercado global. As pessoas e as organizações podem adquirir produtos e serviços de todo o mundo, contudo, 
essas oportunidades são acompanhadas de alguns obstáculos resultantes dessa dimensão global do comércio, 
tais como: 
• Desafios culturais: o site deve ser atraente e fácil de usar. Deve-se tomar cuidado para que o site não seja 
ofensivo para as pessoas ao redor do mundo.
• Desafios de linguagem: as diferenças de linguagens podem ser barreiras para que alguns visitantes 
entendam as informações do site. 
• Desafios da moeda: o site deve conseguir estabelecer preços e aceitar pagamentos em diferentes moedas. 
• Desafios da infraestrutura: o site deve permitir acesso para uma variedade de equipamentos e dispositivos. 
3.5.4 Aplicativos para o comércio eletrônico e móvel 
Vimos que o comércio eletrônico e móvel é usado de forma instigante e inovadora. Agora, conheceremos alguns dos 
vários aplicativos B2B, B2C e C2C e de comércio móvel no varejo, atacado, produção, marketing e serviços bancários.
O varejo eletrônico (também chamado de e-tailing) é a venda direta de serviços ou produtos, realizada pelas empre-
sas, para os seus clientes por meio de uma vitrine eletrônica. Tal vitrine é projetada em um modelo de carrinho de 
compras on-line ou de catálogo eletrônico. Um exemplo de aplicativo para varejo é o site www.walmart.com. 
Outra forma de promover a venda de varejo é o cybermall (também chamado de shopping virtual ou e-mail), que, 
por sua vez é um tipo de site que oferece muitas opções de produtos e serviços em um local da internet. Seria algo 
parecido como um shopping center físico. 
Para o atacado, de acordo com Stair e Reynolds (2016), o ponto-chave é fazer investimentos em bens e serviços 
de manutenção, reparo e operação (MRO – Manufacturing, Repair and Operations). 
Ainda de acordo com Stair e Reynolds (2016), as compras de MRO representam 40% do total de vendas de uma 
empresa de fabricação. MRO inclui desde simples materiais e acessórios para escritório até equipamentos mais 
complexos, como motores e compressores. 
Nesse contexto, é preciso destacar que muitos fabricantes transferem suas operações da cadeia de suprimentos 
para a internet, visando melhorar o serviço ao cliente.
O que é cadeia de suprimento? A cadeia de suprimentos (também conhecida no Brasil como 
Supply Chain) é definida como um sistema de organizações, pessoas, atividades, informações 
e recursos que estão envolvidos na atividade de fazer o transporte de produtos ou serviços 
dos fornecedores até os seus clientes. 
53
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
Na internet, os fabricantes podem formar um intercâmbio eletrônico, que, por sua vez, é um tipo de fórum em 
que fornecedores, fabricantes e concorrentes realizam a compra e a venda de mercadorias e trocam informações 
sobre o mercado. 
Essa abordagem acelera a movimentação de matérias-primas e produtos entre os membros da comunidade do 
negócio e reduz a quantidade de estoque a ser mantida.
Um exemplo de aplicativo usado nessa abordagem de fabricação é o Retail Link, intercâmbio eletrônico usado 
pela Walmart para conectar os seus fornecedores (STAIR; REYNOLDS, 2016). 
No aspecto do marketing, por meio da internet, as empresas podem reunir mais informações sobre o compor-
tamento e as preferências dos clientes. O recolhimento desses dados não é tarefa simples, pois cada visitante 
de uma página oferece de forma voluntária os seus dados, ou seja, depende-se da boa vontade dos clientes em 
fornecer informações. 
Os anunciantes reúnem os dados que conseguem coletar para identificar partes específicas dos seus mercados. 
Com isso, é possível direcionar mensagens publicitárias para determinado público, o que chamamos de segmen-
tação de mercado. 
A segmentação de mercado resume-se a dividir o grupo de possíveis clientes em subgrupos (sexo, renda, estado 
civil etc.) para enviar mensagens comerciais específicas para cada subgrupo.
A empresa americana Nielsen, por exemplo, realiza medição e análise de como os clientes fazem para conseguir 
informações sobre o que desejam e sobre como eles compram mercadorias e serviços. A empresa usa um banco 
de dados chamado Business Facts, que contém informações para mais de 12 milhões de empreendimentos. Com 
os dados fornecidos, é possível estimar vendas para cada negócio e classificá-lo de acordo com os clientes. 
É importante destacarmos ainda que muitas empresas disponibilizam aplicativos de celulares que permitem aos 
compradores fazerem comparação de preços e produtos na internet. Um exemplo é o price check, da Amazon 
(site de venda de livros digitais).
Ainda no sentido de diferenciarem-se no universo do comércio móvel e eletrônico, muitos fabricantes e varejistas 
realizam o envio de cupons de desconto diretamente para os celulares dos seus clientes. Um exemplo dessa abor-
dagem é o Groupon, que permite que os clientes utilizem os códigos de cupons disponibilizados pelas empresas. 
Figura 3.6: Descontos em produtos no comercio eletrônico.
Legenda: Representação dos descontos das lojas virtuais.
Fonte: Plataforma Deduca (2018).
54
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios 
Por fim, gostaríamos de destacar os serviços bancários. Por meio de aplicativos on-line, os consumidores de ser-
viços bancários podem verificar o saldo de suas contas e realizar transações, como pagamentos e transferências. 
Todos os grandes bancos disponibilizam aplicativos para dispositivos móveis, que permitem aos seus clientes 
fazerem todas as transações. São exemplos os aplicativos de bancos como Caixa Econômica e Bradesco. 
Como podemos perceber, o comércio eletrônicoe móvel é uma tendência que aumenta os lucros de empresas. A 
comodidade de fazer uma compra em casa ou realizar algum tipo de transação em qualquer lugar é um grande 
diferencial para fidelizar o consumidor.
55
Considerações finais
Nesta unidade, aprendemos sobre os sistemas de informação para negó-
cios. Vamos retomar os pontos principais estudados até aqui?
• Uma organização utiliza o seu sistema de informação para buscar 
vantagem competitiva.
• Uma empresa que obtém vantagem competitiva sempre se cer-
tifica de que o seu departamento de SI ofereça apoio às metas e 
estratégias da organização.
• Business Intelligence (BI) pode ser traduzido como inteligência nos 
negócios. A finalidade do BI é que o tomador de decisões tenha a 
qualquer momento todas as informações relevantes para suportar 
um processo de decisão.
• No BI, tudo começa com a coleção de dados contidos no data 
warehouse. O data mining, por sua vez, “minera” os dados, 
extraindo informações relevantes.
• O OLTP, do inglês “On-line Transaction Processing”, refere-se aos 
sistemas transacionais.
• O OLAP, do inglês “On-line Analytical Processing”, refere-se à 
capacidade de analisar grandes volumes de informações de dife-
rentes perspectivas dentro de um data warehouse.
• Um sistema de banco de dados multidimensional serve para a 
modelagem de bancos de dados que auxiliam as consultas do 
data warehouse nas mais diversas perspectivas.
• Os data marts são bancos de dados departamentais (por unida-
des de negócio) que podem mostrar visões relacionais ou multi-
dimensionais.
• SGC é um sistema de acompanhamento de programas de treina-
mento on-line e seu objetivo é agilizar o planejamento e o con-
trole sobre a transferência de conhecimento em projetos.
• Inteligência Artificial é o campo no qual um sistema adquire 
características da inteligência humana.
56
• A robótica é a área na qual as máquinas realizam tarefas comple-
xas e rotineiras.
• Os sistemas especialistas fornecem ao computador capacidade 
de sugerir e atuar como alguém especializado em algum campo.
• As realidades virtual e multimídia são tipos de sistemas especiali-
zados usados por muitas organizações.
• O comércio eletrônico é a realização de atividades comerciais por 
meio de computadores.
• O comércio móvel está relacionado com o uso de dispositivos 
móveis e sem fio.
• Existem grandes desafios para o comercio eletrônico, principal-
mente no tocante à segurança dos dados da internet.
Referências bibliográficas
57
STAIR, Ralph M.; REYNOLDS, George W. Princípios de Sistemas de 
Informação. 11. ed. Cengage Learning Editores, 2016. ISBN Digital: 
9788522124107.
STAIR, Ralph M.; REYNOLDS, George W. Princípios de Sistemas de Infor-
mação: Tradução da 11. ed. norte-americana. 3. ed. brasileira, Cengage 
Learning, 2015. 752p. ISBN 9788522118625.
59
4Unidade 4
Desenvolvimento de Sistemas
Para iniciar seus estudos
Caro aluno, seja bem-vindo à quarta unidade do nosso curso!
Conhecer os principais Sistemas de Informação, distinguir suas principais 
características e ter capacidade para sugerir e orientar aquisições são, 
de fato, habilidades fundamentais para alguém do ramo de Sistemas de 
Informação. Sem elas, o desempenho do profissional ficaria comprome-
tido e sua reputação arranhada com o tempo.
Ocorre, no entanto, que o conhecimento de aspectos relacionados ao 
desenvolvimento dos sistemas também é essencial nessa atividade. 
Nesse sentido, esta unidade aborda, além desse tema, o perfil do profis-
sional envolvido na criação de uma ferramenta computacional e o ciclo 
de vida de um sistema.
Mesmo que desenvolver programas não seja sua prioridade imediata, o 
conhecimento do seu processo de criação será absolutamente indispensável 
para que seus contatos com a equipe de desenvolvimento sejam exitosos.
Então, sem mais demora, iniciamos nossa caminhada nesta unidade. 
Bom estudo!
Objetivos de Aprendizagem
• O aluno será capaz de compreender conceitos principais, profis-
sionais envolvidos, carreiras em Sistemas de Informação, ciclo de 
vida do software.
60
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Tópicos de estudo
Iniciamos, nesta unidade, nosso estudo sobre desenvolvimento de sistemas. Embora as oportunidades para a reali-
zação profissional em Tecnologia da Informação sejam amplas, é na atividade de desenvolvimento de sistemas que 
boa parte dos envolvidos baseiam suas carreiras. Há que se registrar, desde já, que “desenvolver sistemas” não se 
restringe à programação de computadores. Mais do que isso, o sucesso nessa atividade requer domínio do processo 
de construção de uma ferramenta computacional, que inclui levantamento de requisitos, desenho da solução, 
transformação do desenho em código de programa, testes e a efetiva implantação da aplicação.
No entanto, antes de nos aventurarmos pelo ciclo de vida de um software, estudaremos juntos os conceitos bási-
cos de desenvolvimento de sistemas e um pouco do que se espera de um profissional de TI.
Preparado? Boa leitura!
4.1 Conceitos fundamentais
Desenvolver softwares não se restringe ao uso de uma linguagem de programação para criar uma aplicação de 
computador. Embora a efetiva criação do programa nessa etapa seja importante do processo que abordaremos, 
ela não se completa de forma isolada.
Para que possamos entender como um processo de desenvolvimento de software efetiva-se, é necessário que 
entendamos as partes que compõem seu conceito, sempre considerando o âmbito da Engenharia de Software 
em suas caracterizações.
Engenharia de software: O IEEE elaborou a seguinte definição para engenharia de software: 
(1) A aplicação de uma abordagem sistemática, disciplinada e quantificável no desenvol-
vimento, na operação e na manutenção de software; isto é, a aplicação de engenharia ao 
software. (2) O estudo de abordagens como definido em (1) (PRESSMAN; MAXIM, 2016). 
Glossário
Iniciamos nossa abordagem pela caracterização de processo. Pressman e Maxim (2016) ensinam que processo 
é um conjunto de atividades, ações e tarefas realizadas na criação de algum artefato. Embora correta, essa defi-
nição nos parece bastante genérica e pode ser aplicada a quase a totalidade dos ramos de atividade humana. A 
figura a seguir ilustra, como exemplo, o processo de montagem de um automóvel.
61
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Figura 4.1 - Processo de montagem de um automóvel.
Legenda: Imagem com ilustração de uma linha de produção de automóveis.
Fonte: Plataforma Deduca (2018).
Nosso trabalho de definição dos termos avança com a retomada da caracterização de software, que já foi defi-
nido em unidade anterior. Embora seja bastante comum considerarmos software como sinônimo de programa 
de computador, nossa conceituação não pode contentar-se apenas com isso.
Sommerville (2010) amplia os limites da expressão e afirma que software não é apenas um programa, mas tam-
bém todos os dados de documentação e configuração associados necessários para que o programa opere cor-
retamente.
A criação de um produto de software não se restringe, definitivamente, a um ato isolado. A adoção de um pro-
cesso bem estruturado e dominado pela equipe tem o potencial de proporcionar segurança e economia de 
recursos durante a execução do projeto. Por sua vez, um processo caótico, no qual etapas e funções não são bem 
definidas, oferece alta probabilidade de insucesso do projeto.
Existem diversas conceituações relacionadas ao processo de software, mas podemos defini-lo como uma sequ-
ência de etapas que objetivam a produção e a manutenção de um software. Nessas etapas, incidem padrões, 
verificam-se entradas e saídas e verifica-se o inter-relacionamento de recursos humanos e materiais.
Por causa de sua complexidade e abrangência, foram criados diversos modelos de processo de desenvolvimento 
de software, cada um com suas particularidades e facilidades de aplicação em contextos específicos. Dois dos 
mais conhecidosincluem:
• Processo evolucionário
Como o nome sugere, esse processo baseia-se na evolução de uma implementação inicial de um produto de sof-
tware. A cada ciclo evolutivo, versões mais aprimoradas do sistema são oferecidas ao usuário, até que o produto 
desejado e nas especificações corretas esteja pronto. Sommerville (2010) apresenta dois tipos fundamentais de 
processo evolucionário:
a. Desenvolvimento exploratório: nesta modalidade, o profissional envolvido deve entrar em sintonia com 
o cliente para explorar os requisitos e promover a entrega do sistema final. O desenvolvimento segue 
um padrão bastante racional: começa com as partes do sistema que já são compreendidas e evolui para 
versões mais bem-acabadas por meio da adição de novas funcionalidades sugeridas pelo cliente e/ou 
usuário.
62
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
b. Prototipação: é uma versão inicial de um sistema de software usada para demonstrar conceitos, expe-
rimentar opções de projeto e, geralmente, conhecer mais sobre o problema e suas possíveis soluções 
(SOMMERVILLE, 2010). O protótipo de uma interface de usuário, por exemplo, pode ser desenvolvido para 
que o usuário tenha parâmetro para decidir sobre localização de campos e menus.
O desenvolvimento do protótipo deve ser rápido, a fim de não comprometer prazos. Ele pode ser usado na fase de 
requisitos, para ajudar na descoberta e validação destes; na fase de projeto; e na fase de testes.
Por fim, é sempre importante alertar o cliente que o protótipo não corresponde à versão final do produto.
Essa abordagem de desenvolvimento coloca o cliente como figura ativa do processo de desenvolvimento e mini-
miza a ocorrência de mal-entendidos entre ele e a equipe de desenvolvimento. No entanto, a maior efetividade 
desse paradigma em relação a outros (o modelo em cascata, por exemplo) também dá-se pelo fato de existirem 
mais oportunidades para que o cliente mude de ideia em relação a determinada funcionalidade do sistema sem 
que cause grande prejuízo financeiro e de tempo.
Se as etapas para a construção de um software já foram definidas e testadas ao longo do 
tempo, será então coerente afirmar que, ao segui-las com rigidez e assertividade, um profis-
sional de TI conseguirá, em todos os casos, concluir com êxito seu projeto de criação de um 
sistema computacional? 
Essa abordagem, aliás, inspirou o surgimento de metodologias ágeis de desenvolvimento, incluindo o Extreme 
Programming. É justamente sobre elas que lançaremos luz em nosso próximo item do conteúdo.
• Processo Ágil de Desenvolvimento
Em sua essência, os métodos ágeis têm menos ênfase nas definições de atividades e mais ênfase nos fatores 
humanos do desenvolvimento. São claramente mais adequados à natureza do trabalho de profissionais de TI, 
já que se baseiam na necessidade de sucessivas revisões na obra. Atividades intelectuais não são executadas de 
forma linear e não são determinísticas.
Durante a construção de um software, há que se considerar uma infinidade de detalhes que nem sempre são lem-
brados logo na primeira oportunidade. Da mesma forma, ao tratar pela primeira vez das funcionalidades que deseja 
para o produto, o cliente ainda não as conhece por completo e não consegue ter visão global do que necessita. Que 
tal darmos a ele a oportunidade de aprender e mudar de ideia ao longo do processo de desenvolvimento?
Na Unidade 6 do nosso curso, quando tratarmos especificamente de requisitos de software, teremos oportuni-
dade de constatar que o comportamento das condições necessárias para que um sistema exista é bastante volátil 
e altera-se com muita facilidade. Sabedores desse fato, os criadores do XP o adequaram para suportar tal incons-
tância.
Outra característica marcante dessa metodologia é sua adequação para equipes pequenas, com não mais do que 
10 membros. É sempre bom lembrarmos que o cliente (sim, o cliente) também faz parte da equipe e, como todos 
os demais, é um elemento que tem direitos e deveres.
Outra marca do XP é sua indicação para projetos implementados em linguagens orientadas a objetos. Pela utili-
zação desse paradigma, é possível, desde o começo, entregar ao cliente partes executáveis do produto para que 
63
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
ele possa aprender sobre a solução que se desenha e registrar suas impressões para a equipe. A essa comunica-
ção em duas vias e em curtos períodos damos o nome de feedback.
Embora parte da literatura sobre o XP liste cinco valores fundamentais da metodologia, descreveremos quatro 
deles.
• Feedback: baseia-se na comunicação entre cliente e equipe à medida que o sistema cresce em funciona-
lidades. Funciona assim:
(i) A equipe entrega ao cliente parte executável do sistema.
(ii) O cliente utiliza, revisa e eventualmente muda de ideia em relação a certas funcionalidades já imple-
mentadas.
(iii) De posse dessas informações, a equipe faz a devida readequação no sistema (ou na parte já imple-
mentada), inclui mais funcionalidades e retorna-o ao cliente, que repete a operação anterior.
• Comunicação: por meio de suas práticas, o XP visa promover a estreita comunicação entre membros da 
equipe e entre a equipe e o cliente. O esforço para tornar o cliente parte efetiva da equipe procura evitar 
que o desenvolvimento do projeto ou mesmo a implementação de funcionalidades sejam feitos de forma 
especulativa. As reuniões diárias entre membros da equipe são, por exemplo, providência efetiva no esta-
belecimento da comunicação.
• Simplicidade: é comum entre profissionais de TI o raciocínio de que implementar funções que o cliente 
não solicitou e tornar mais complexas as que ele, de fato, pediu, é um meio de causar boa impressão. O XP, 
no entanto, prega que a simplicidade é elemento-chave para o desenvolvimento de sistemas eficientes, 
objetivos e perfeitamente adequados às necessidades dos clientes. 
• Coragem: uma das práticas do XP incentiva a permissão para que todos os membros da equipe tenham 
acesso pleno e irrestrito ao código que está sendo construído. Outra prática estimula que o programa, 
mesmo pronto e funcional, seja alterado para acomodar as regras de codificação da linguagem Java. 
A implantação de uma nova metodologia de desenvolvimento, bem diferente da tradicional e baseada na intensa 
interação entre cliente e equipe, pode gerar desconfiança no alto escalão da empresa. Bem, já temos argumen-
tos suficientes para entender que a coragem deve ser um dos fundamentos do XP, não acha?
De acordo com o documento intitulado “Manifesto Ágil”, os métodos ágeis valorizam:
• indivíduos e interação entre eles mais que processos e ferramentas,
• software em funcionamento mais que documentação abrangente,
• colaboração com o cliente mais que negociação de contratos,
• responder a mudanças mais que seguir um plano. 
Disponível em: <http://www.manifestoagil.com.br/> 
http://www.manifestoagil.com.br/
64
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Essas bases do XP são elementos motivadores das práticas adotadas pela metodologia. Uma delas é a prática do 
cliente presente. Ela assume o papel principal no processo de quebra de paradigmas proposto pelo XP. Afinal, 
não era considerada como válida – sequer aconselhável – a presença efetiva do cliente durante o desenvolvi-
mento de um programa. Via de regra, a participação dele no projeto dava-se apenas no momento da coleta de 
requisitos e na implantação do sistema.
O modelo ágil, no entanto, sugere que o cliente deve conduzir o desenvolvimento a partir da utilização do sis-
tema e que sua proximidade da equipe viabiliza essa condução. Essa prática nos revela que:
• O distanciamento é natural entre equipe e cliente.
• A proximidade fomenta o feedback, torna-o mais constante e evita mudanças bruscas na condução do 
projeto.
• Cliente próximo evita trabalho especulativo.
• Quanto mais distante o cliente estiver, mais difícil será demonstraro valor do serviço.
• Para ter um cliente mais presente, deve-se enfrentar o desafio cultural, bem como a falta de disponibili-
dade dele e a distância entre ele e a equipe.
Outra prática importante e de fácil operacionalização é a programação em par. 
Desenvolvedores não trabalham sozinhos em um projeto XP. Você também pode achar pouco convencional, mas 
na programação em par, dois programadores trabalham em um mesmo problema, ao mesmo tempo. Aliás, quem 
foi que disse que o XP é convencional?
Em determinado momento, o condutor assume o teclado e o navegador acompanha o trabalho, fazendo revi-
sões e sugestões. Em outro, há revezamento de papéis. As correções são feitas no momento da programação, 
evitando que pequenos erros se tornem grandes problemas no futuro. 
A condução da programação deve ser realizada, em tempos alternados, pelos dois programadores. Eles devem 
alternar-se, escrevendo código a cada 15 ou 20 minutos. Conveniente, não acha?
Feitas as considerações sobre esses processos (ou modelos) de desenvolvimento de software, é esperado que 
você consiga eleger o que melhor se adeque ao perfil da equipe, dos recursos e do problema que se apresenta. E 
lembre-se: os modelos não são mutuamente exclusivos e a combinação de suas melhores características é um 
meio de aumentar as chances de bons resultados.
Passemos agora para a abordagem de alguns perfis profissionais em nosso ramo de atividade.
4.2 Perfis profissionais em Sistemas de Informação
Cumpre iniciar este item com um breve conselho: duvide de quem afirma saber absolutamente tudo a respeito de 
Tecnologia da Informação! Pela complexidade e variedade dos temas relacionados a essa área, fica muito difícil 
acreditar que isso seja possível, ainda mais quando se considera a necessidade sempre urgente de atualizações 
naquilo que se imagina conhecer.
Por isso, não é de se espantar que a TI abrigue atualmente tantos perfis e funções em seus quadros profissionais.
Como temos afirmado, não é apenas de desenvolvedores (antes chamados programadores) que vive a área de 
Sistemas de Informação. Se desenvolver programas não é sua maior habilidade, não desanime. A TI ainda assim 
tem guardado um bom lugar para você.
65
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Não se trata, contudo, de descrever e classificar exaustivamente cada uma das funções da área. Ao invés disso, 
esta parte do nosso conteúdo deverá lhe servir como um delineador de perfis de pessoas que poderão fazer parte 
do seu convívio profissional, seja como colega de trabalho, seja como alguém que temporariamente dividirá seu 
tempo em um projeto específico.
Comecemos pela descrição de uma equipe de trabalho típica da metodologia Extreme Programming.
É bem verdade que as metodologias ágeis, de modo geral, estimulam a convivência de habilidades diversas em 
sua equipe. Em outras palavras, elas buscam não promover a especialização como meio para o sucesso da equipe. 
Mesmo assim, é preciso definir funções entre os participantes do projeto, inclusive para fins de organização da 
equipe, como segue:
Gerente do projeto: tem a responsabilidade de conduzir as etapas do projeto, tratar diretamente com o cliente 
e tratar dos assuntos administrativos. Embora o cliente idealmente faça parte da equipe de desenvolvimento, é 
com esse gerente que ele terá contato com mais frequência.
Coach: compete a ele a escolha e a manutenção da tecnologia que será utilizada no desenvolvimento do pro-
duto. Deve ser experiente e conhecedor das habilidades técnicas da equipe para que a linguagem de programa-
ção seja de domínio comum na equipe.
Analista de teste: este profissional escreve os testes que serão realizados no produto (ou em parte dele) junto 
com o cliente. Ele também é responsável por enviar ao pessoal de desenvolvimento os resultados dos testes 
como meio de promover o feedback.
Redator técnico: documentar é preciso, mas esse processo não pode tornar-se motivo para morosidade do 
desenvolvimento. É com a missão de livrar a equipe da documentação que o redator técnico entra em cena.
Desenvolvedor: antes chamado simplesmente de programador, este profissional é responsável, inclusive, por 
levantar requisitos junto ao cliente, esboçar a solução e codificar o programa.
Tanto na condição de desenvolvedor quanto em qualquer outra que você esteja engajado no projeto do Sistema 
de informação, será absolutamente comum o contato com o usuário e/ou o cliente. De tão importantes no con-
texto, esses perfis merecem desdobramentos. 
Tipicamente, o cliente é o primeiro e mais importante componente do projeto. Para fins de conceituação, trata-
-se da pessoa ou do grupo de pessoas para quem o sistema é construído. É ele que define as características do 
sistema e tem o direito de não pagar se não ficar satisfeito com o produto. 
Sim, há grandes possibilidades de mal-entendidos entre o profissional que cuida do desenvolvimento do sistema 
e o cliente. Problemas de comunicação são frequentes.
Outro elemento-chave no contexto é o usuário. A comunicação com ele é tão importante que se sugere que o 
usuário seja membro da equipe de projeto. Caso não seja possível a comunicação direta com o usuário, deve-se 
redobrar a atenção na documentação do sistema.
É fato que usuários têm perfis heterogêneos e que é um erro presumir que todos são iguais. Vejamos alguns dos 
seus tipos:
• Usuários operativos: são funcionários burocratas, operacionais e até mesmo administradores que terão 
contato diário com o sistema. Estão interessados em qual tipo de entrada terão que realizar ou como 
reverter uma entrada incorreta. Tendem a ter uma visão local e conhecer apenas a tarefa específica que 
executam. Podem ter dificuldades em explicar como suas atividades encaixam-se na organização ou qual 
a finalidade da organização.
• Usuários supervisores: são funcionários em atividades de supervisão. Geralmente, chefiam um grupo 
de usuários operativos, sendo responsáveis por seus desempenhos. Não raro, já foram usuários operati-
66
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
vos um dia e acabaram sendo promovidos. Por isso, conhecem o serviço do subordinado. Têm interesse 
em aumentar o volume de trabalho realizado e reduzir custos e erros por meio do sistema. Esse perfil de 
usuário pode considerar o sistema como um meio de reduzir a quantidade de usuários operativos ou de 
evitar o aumento desse número quando o volume de trabalho crescer. Nesse contexto, o analista (você, 
no caso) pode ser envolvido em disputas políticas.
• Usuários executivos: geralmente, não se envolvem diretamente com o projeto. É a autoridade financeira 
para as necessidades do projeto e, na maioria dos casos, não foram usuários operativos ou esqueceram-
-se dessa experiência. Seu interesse no sistema gira em torno de aspectos estratégicos de lucros e per-
das a longo prazo, incluindo novos mercados, novos produtos e novas vantagens competitivas. Eles são 
interessados na visão global do sistema e desprezam detalhes, principalmente aqueles relacionados à 
execução do projeto.
Quanto mais elevado o nível do executivo, menos provável que conheça ou se interesse por tecnologia. Você deve 
concentrar as discussões com ele nas características essenciais do sistema. As metas e prioridades da gerência 
podem ser conflitantes com as dos usuários.
E lembre-se sempre: gerentes têm diferentes opiniões e visões e competem entre si. Alguns serão favoráveis, 
outros serão contra ou omissos em relação ao novo sistema. As opiniões podem mudar ao longo do desenvolvi-
mento do projeto.
Embora a caracterização dos usuários por tipo de função já cubra a maioria dos perfis que poderemos encontrar, 
outra classificação pode ser bastante útil: por nível de experiência.
• Usuário amador: sempre pronto a dizer: “Não entendo nada de computador!”. Normalmente, tem longa 
experiência de trabalho e começou suas atividades antes do advento do computador. Pode até ser jovem, 
mas achao computador tedioso, intimidante ou irrelevante. Seu verdadeiro problema é a dificuldade em 
compreender a linguagem do profissional. Se esse usuário não entender o sistema, há grande possibili-
dade de insatisfação e boicote.
• Usuário novato: geralmente, já participou de projetos anteriores ou já escreveu alguns “programinhas”. 
Com alguma frequência, acha que sabe exatamente o que quer que o sistema faça e está sempre dis-
posto a apontar todos os erros do profissional de TI. Pode envolver-se demais em discussão de tecnologia 
sem estar apto para isso.
• Usuário perito: de fato, conhece Sistemas de Informação e tecnologia de computadores e geralmente 
colabora efetivamente com o projeto. Considere tê-lo como aliado como multiplicador do projeto junto 
aos demais usuários. 
Em relação aos profissionais de TI que podem estar envolvidos no projeto do Sistema de Informação, apresen-
tamos no início deste item o perfil do pessoal do desenvolvimento ágil. Vejamos agora algumas das funções 
tradicionais em um projeto:
• Analista de Sistemas: membro essencial de qualquer projeto de desenvolvimento de sistemas. Ele é 
comparado a um arqueólogo e escriba, pois desvenda os anseios do cliente e documenta especificações. 
Deve ter perfil inovador e explorar novas maneiras para o cliente conduzir seu negócio ou atividade. É 
esperado que seja diplomático e hábil negociador, já que pode ver-se diante de desentendimentos entre 
os diversos tipos de usuários. Não raramente será o líder técnico do projeto. Enfim, um analista precisa ter 
habilidade com as pessoas, conhecimento de aplicações e habilidade em tecnologia.
• Pessoal de operação: responsável por tarefas indispensáveis na continuidade dos serviços no setor de TI, 
tais como instalação e manutenção de redes, segurança de hardware, backups, manipulação e manuten-
ção de impressoras, entre outras. Tem pouco contato com o analista, mas eventuais restrições técnicas 
colocadas pelo pessoal de operação devem ser conhecidas e consideradas.
67
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
É muito provável que você já tenha tido contato com alguma outra nomenclatura de funções e cargos em TI. 
Arquiteto de software, engenheiro de software, administrador de bancos de dados certamente são algumas des-
sas denominações que você já conhece. Vale a pena conhecê-las melhor.
Uma grande variedade de funções e especialidades surgiu nos últimos anos no mundo da 
TI. Reportagem da Revista Exame, disponível em <https://exame.abril.com.br/carreira/os-7-
-profissionais-mais-disputados-na-area-de-ti/> (Acesso em: 23 jan. 2018) analisa algumas 
das mais disputadas habilidades que um profissional de TI deve reunir para ter êxito para ser 
bem-sucedido.
Assista ao vídeo disponibilizado pelo canal Olhar Digital, disponível em <https://www.you-
tube.com/watch?v=ZqkARSPXUJI> (Acesso em: 23 jan. 2018). As profissões do futuro são 
resumidamente descritas em pouco menos de seis minutos. 
 
Que tal uma olhada mais detida em um dos (ainda) principais modelos de desenvolvimento de software? Então, 
sigamos com o ciclo de vida tradicional de um software.
4.3 Ciclo de vida do software
Embora a expressão “ciclo de vida do software” possa ser aplicada a qualquer processo de desenvolvimento, é ao 
modelo em cascata que ele é associado com mais frequência. Esse modelo é o mais tradicional e, embora venha 
sendo alvo de críticas, ainda tem lugar garantido entre os preferidos das empresas de desenvolvimento.
A figura a seguir mostra a representação das fases do modelo em cascata. 
https://exame.abril.com.br/carreira/os-7-profissionais-mais-disputados-na-area-de-ti/
https://exame.abril.com.br/carreira/os-7-profissionais-mais-disputados-na-area-de-ti/
https://www.youtube.com/watch?v=ZqkARSPXUJI
https://www.youtube.com/watch?v=ZqkARSPXUJI
68
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Figura 4.2 - Representação das fases do modelo em cascata.
Requisitos
Projeto
Implementação
Testes
Manutenção
Fonte: Elaborada pelo autor (2018).
Note que uma fase do processo depende do resultado ou do produto gerado pela fase anterior. As setas de retro-
alimentação, dispostas no sentido contrário à cascata, indicam a possibilidade de retorno às fases anteriores, 
considerando nelas a ocorrência de falhas. Em outras palavras, o retrocesso a uma fase anterior serve, em tese, 
para sanar problemas que, se levados adiante, acarretariam mais prejuízo ao desenvolvimento.
Para que a proposta de ensino desta unidade seja contemplada, cada uma das fases do modelo será descrita 
sucintamente.
4.3.1 Requisitos
A fase de requisitos de software preocupa-se com descoberta, análise, especificação e validação das proprieda-
des que devem ser apresentadas para resolver tarefas relacionadas ao software que será desenvolvido. Requisitos 
são as condições necessárias para que determinado evento aconteça. Tome como exemplo uma aula presencial. 
Para que ela aconteça, é necessária a presença de professor, alunos, lousa, giz, carteiras. Todos esses itens for-
mam o conjunto de requisitos da aula. No desenvolvimento de software, acontece o mesmo. Além das funções 
que desempenhará, fazem parte dos requisitos de um software as restrições às quais ele estará sujeito. Exemplos 
dessas restrições incluem questões ligadas ao orçamento disponível ou ao armazenamento de dados.
O projeto de um software fica vulnerável quando o levantamento dos requisitos é executado 
de forma inapropriada. Caso uma falha seja cometida na fase de levantamento dos requi-
sitos do produto, ela deverá propagar-se nas fases seguintes de projeto e implementação. 
Assim, quanto antes a falha for corrigida, menos dispendioso será seu reparo. 
69
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
4.3.2 Projeto
Uma vez levantados, analisados, especificados e validados os requisitos, o processo deverá nos levar ao desenho 
do produto. Se os requisitos nos mostram o que o sistema deverá fazer, o projeto deverá refletir como ele o fará. 
Por meio do projeto, os requisitos são refinados de modo a tornarem-se aptos a serem transformados em pro-
grama. O trabalho principal de um projetista é o de decompor o produto em módulos, que podem ser conceitu-
ados como blocos de código que se comunicam com outros blocos por meio de interfaces.
4.3.3 Implementação
É na implementação que o produto se torna palpável e pode ser apresentado ao cliente. A correta tradução dos 
requisitos mais uma vez estará sendo colocada em teste, já que as funcionalidades e restrições se tornam “visí-
veis” agora. Como estratégia de implementação, a equipe poderá dividir o trabalho de forma que cada progra-
mador (ou um pequeno grupo deles) fique responsável por um módulo do sistema. Idealmente, a documentação 
gerada pela fase de projeto deve servir como principal embasamento para a codificação, o que não afasta a 
necessidade de novas consultas ao cliente e à equipe de projetistas.
4.3.4 Testes
Aplicar testes significa executar um programa para que defeitos sejam descobertos. Embora não se trate de asse-
gurar que o código está perfeito, a confiança no produto aumenta bastante conforme a qualidade dos testes 
aplicados. O processo inclui planejamento, elaboração de casos de teste, a efetiva execução do programa e a 
análise dos resultados.
Em que pese a existência de outras igualmente importantes, é nas técnicas funcional e estrutural que os testa-
dores mais se apóiam. A primeira baseia-se nas funções do software para a geração dos requisitos de teste e a 
segunda baseia-se no conhecimento da estrutura interna (ou implementação) do programa.
4.3.5 Manutenção
Com o produto implementado, testado e disponibilizado ao cliente, chega ao fim o trabalho da equipe, certo? 
Ainda não! 
Embora espere-se que o software inicialmente atenda aos requisitos colocados pelo usuário, o produto deverá 
sofrer alterações e evoluir durante sua utilização. Defeitos não detectadosna fase de teste também se manifes-
tarão e tudo isso requer manutenção.
Embora os esforços durante o desenvolvimento tendam a gerar um produto próximo do ideal, não se pode abrir 
mão da manutenção como parte integrante do ciclo de vida do produto.
Os dois tipos mais comuns de manutenção incluem manutenção corretiva, que corrigirá problemas detectados 
durante a plena utilização do programa; e manutenção perfectiva, que irá aprimorar funções já existentes ou 
incluir outras novas.
70
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Terminamos nosso estudo sobre processo de desenvolvimento de sistemas e nossa abordagem dos principais 
perfis profissionais em um ambiente de criação de software. Esperamos que o conteúdo aqui tratado seja apro-
priado e útil em sua vida profissional. Bom senso e bom nível de percepção no trato com os usuários e clientes 
certamente serão fundamentais para que você se torne uma boa referência nos projetos dos quais participar.
Esmere-se nas leituras adicionais, na resolução dos exercícios e até nosso próximo encontro!
71
Considerações finais
Nesta unidade, você teve contato com alguns dos principais processos de 
desenvolvimento de sistemas e com o perfil de profissionais que atuam 
no ramo. Em resumo, estudamos: 
Conceitos fundamentais de desenvolvimento de sistemas: neste item, 
tratamos do desenvolvimento de sistemas como a sequência de passos 
que visam à produção e manutenção de um software e que se inter-rela-
cionam com recursos (humanos e materiais), padrões, entradas e saídas e 
com a própria estrutura da organização.
Nesse contexto, focamos em dois métodos de desenvolvimento bas-
tante utilizados nos dias atuais, quais sejam, o processo evolucionário e 
o Extreme Programming. O processo evolucionário, como o próprio nome 
sugere, baseia-se na evolução de uma implementação inicial de um pro-
duto de software. A cada ciclo evolutivo, versões mais aprimoradas do sis-
tema são oferecidas ao usuário, até que o produto desejado e nas especi-
ficações corretas esteja pronto.
O Extreme Programming (XP) é uma metodologia ágil de desenvolvi-
mento, adequada para projetos que possuem requisitos que se alteram 
constantemente, para equipes pequenas e para a construção de progra-
mas orientados a objetos. É indicado também para ocasiões em que se 
deseja partes executáveis do programa logo no início do desenvolvimento 
e que ganhem novas funcionalidades assim que o projeto avança.
O XP apoia-se em quatro pilares para atingir seus objetivos: feedback, 
comunicação, simplicidade e coragem e duas das suas principais práticas 
incluem o cliente presente e a programação em par.
Perfis profissionais em Sistemas de Informação: a grande variedade de 
habilidades que se requer de um profissional acaba gerando uma miríade 
de perfis desejados para atuação em TI. Neste item, tratamos de alguns 
perfis de pessoas envolvidas em projetos, com ênfase em clientes/usuá-
rios. No entanto, começamos a abordagem do tema com a descrição dos 
componentes de uma equipe típica do XP. Ela é composta por gerente do 
projeto, coach, analista de teste, redator técnico e desenvolvedor.
A necessidade de estabelecer uma boa comunicação com usuários e 
cliente será muito frequente em qualquer projeto. O cliente é peça funda-
mental na definição das características do sistema e tem o direito de não 
72
pagar se não ficar satisfeito com o produto. Por sua vez, o usuário deverá 
operar diretamente o sistema e sua variedade de perfis pode ser agrupada 
em usuários operativos, usuários supervisores e usuários executivos. Além 
disso, pelo seu nível de conhecimento, costuma-se classificá-los como 
usuário amador, novato e perito.
O Analista de Sistemas é peça essencial de qualquer projeto de desenvol-
vimento de sistemas e deve conduzir a atividade do cliente na busca por 
inovações em seus processos de negócios. É esperado que seja diplomá-
tico e hábil negociador, além de conhecedor de tecnologia.
Ciclo de vida do software: esta expressão é mais comumente associada 
ao modelo tradicional ou em cascata. Ele é composto pelas fases de requi-
sito, projeto, implementação, testes e manutenção, nessa ordem. A fase 
de requisitos de software preocupa-se com descoberta, análise, especi-
ficação e validação das propriedades que devem ser apresentadas para 
resolver tarefas relacionadas ao software que será desenvolvido. Uma vez 
levantados, analisados, especificados e validados os requisitos, o processo 
deverá nos levar ao desenho do produto ou projeto de software. Na fase 
de implementação, o projeto é transformado em linguagem de progra-
mação para que, de fato, o produto passe a ser executável. Com a parte 
ou o todo pronto, o processo passa para a fase de testes. Aplicar testes 
significa executar um programa para que defeitos sejam descobertos. 
Embora não se trate de assegurar que o código está perfeito, a confiança 
no produto aumenta bastante conforme a qualidade dos testes aplicados. 
O processo inclui planejamento, elaboração de casos de teste, a efetiva 
execução do programa e a análise dos resultados.
Referências bibliográficas
73
PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software - Uma 
Abordagem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968p. 
ISBN 9788580555332.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: A. Wesley 
Publishing Company, 2010. 552p.
75
5Unidade 5
Engenharia de Software 
Para iniciar seus estudos
Você está iniciando a quinta unidade da disciplina Fundamentos de Siste-
mas de Informação. Já passamos por vários conteúdos interessantes, mas 
agora você deve ficar atento porque entrará na engenharia de software; 
iremos aprofundar os conhecimentos nesta empolgante unidade. Está 
pronto? Vamos em frente!
Objetivos de Aprendizagem
• O aluno será capaz de compreender sobre: definição de software, 
campos de aplicação, webapps, aplicativos móveis, computação 
em nuvem, definição de engenharia de software, o processo de 
software, a prática da engenharia de software.
76
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
5.1 Conhecendo os Softwares
Vamos iniciar relembrando o que vimos na Unidade 1 sobre o conceito de software. Segundo Resende e Abreu 
(2014), software é uma sequência de instruções escrita para ser interpretada por um computador com o objetivo 
de executar tarefas específicas; não é tangível e somente pode ser evidenciado pelas suas funcionalidades. O 
software tornou-se muito importante na modernidade. Sommerville (2010, p. 3) afirma:
O mundo moderno não poderia existir sem o software. Infraestruturas e serviços nacionais são 
controlados por sistemas computacionais, e a maioria dos produtos elétricos inclui um compu-
tador e um software que o controla. A manufatura e a distribuição industriais são totalmente 
informações possibilitam aos programas manipular informatizadas, assim como o sistema finan-
ceiro. A área de entretenimento, incluindo a indústria da música, jogos de computador, cinema 
e televisão, faz uso intensivo de software. Portanto, a engenharia de software é essencial para o 
funcionamento de sociedades nacionais e internacionais.
Pressman e Maxim (2016) trazem uma definição esclarecedora sobre software. Para eles, software consiste em:
• instruções (programas de computador) que, quando executadas, fornecem características, funções e 
desempenho desejados;
• estruturas de dados que possibilitam aos programas manipular informações adequadamente;
• informação descritiva, tanto na forma impressa como na virtual, descrevendo a operação e o uso de 
programas.
Podemos dizer também que o software pode extrapolar qualquer limite físico, ou seja, “eles não são restringidos 
pelas propriedades dos materiais, nem governados pelas leis da física ou pelos processos de manufatura” (PRES-
SMAN; MAXIM, 2016, p. 4). Para a engenharia de software, portanto, não há limites naturais para o potencial do 
software. Por outro lado, essa faltade restrições físicas torna os sistemas de software muito complexos, difíceis de 
entender e caros para alterar.
Continuando nossa linha de raciocínio sobre o software, podemos ainda analisar o seu processo de desenvol-
vimento. O software é desenvolvido por um processo de engenharia que é bem diferente da fabricação de um 
hardware e não deve ser gerido da mesma forma. Além disso, o software não se desgasta e é construído de forma 
personalizada.
Quais são as diferenças dos processos de fabricação de um software e de um hardware? Quais 
os cuidados que devemos ter ao adquirir um software? Será que são os mesmos requisitos 
para a compra de hardware? 
77
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
5.2 Tipos de Software
Stair (2015) classifica softwares em software de sistemas e software de aplicação. Já Pressman (2016) acrescenta as 
categorias software científico/de engenharia, software embutido, software para linha de produtos, aplicação para 
web e software de inteligência artificial. 
5.2.1 Software de Sistema
O software de sistema é uma categoria que compreende os softwares que operam tarefas fundamentais para o 
funcionamento do hardware. Nessa categoria, há sistemas operacionais, utilitários e ferramentas de desenvolvi-
mento de software. 
Um sistema operacional é um software cujo objetivo é dispor, para os usuários, uma forma de utilização do har-
dware que permita gerenciar o funcionamento do sistema do computador. Em resumo, podemos dizer que um 
sistema operacional é uma máquina virtual que permite acessar recursos de hardware sem que seja necessário 
possuir conhecimento detalhado de como os dispositivos funcionam.
Um sistema operacional desempenha as seguintes funções: 
• Gerenciador de processos: o sistema operacional é responsável por gerenciar a execução das tarefas em pro-
cessamento, fazendo a coordenação do compartilhamento dos recursos do sistema por meio dessas tarefas.
• Gerenciador de memória: conforme a CPU necessita de memória para executar os seus processos, o 
sistema operacional utiliza técnicas que otimizam a utilização dos recursos de memória. 
• Gerenciador de entrada e saída: o sistema operacional deve controlar o acesso aos dispositivos de 
entrada e saída; sendo assim, o sistema operacional gerencia as situações em que os processos precisam 
obter dados ou apresentar resultados para o usuário.
• Gerenciador de arquivos: nesse contexto, o sistema operacional deve organizar as unidades de memória 
secundária e a forma como os dados podem ser armazenados e acessados. 
Quanto aos utilitários, estes são softwares que realizam tarefas rotineiras, como antivírus, software de backup, 
segurança, entre outros. 
As ferramentas de desenvolvimento de software são usadas por profissionais da área para o desenvolvimento de 
sistemas/softwares. Nessa categoria, podemos citar linguagens de programação e sistemas de banco de dados. 
78
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
5.2.2 Software Aplicativo 
A categoria de software aplicativo refere-se àqueles que permitem usar a tecnologia para resolver problemas 
específicos. 
Figura 5.1 – Software aplicativo.
Legenda: A figura mostra alguns exemplos de softwares aplicativos.
Fonte: Plataforma Deduca (2018).
Os softwares aplicativos dividem-se em genéricos e personalizados: 
• Genéricos: sistemas gerenciadores de banco de dados, sistemas de gestão integrada (ERP – Enterprise 
Resource Planning), editores gráficos, editores de texto, entre outros de uso geral.
• Personalizados: desenvolvidos sob demanda para atender a necessidades específicas; por exemplo, um 
sistema desenvolvido para uma escola ou para uma oficina mecânica, entre outros. 
A tecnologia de sistemas operacionais é um ramo da ciência da computação que anda sem-
pre em evolução. Existem diversos produtos de software nessa categoria e a escolha do sis-
tema operacional mais adequado a cada caso depende da tecnologia de hardware que será 
utilizada e de quais aplicações serão disponibilizadas para o usuário. 
79
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
5.2.3 Software Científico e de Engenharia
Software Científico ou de Engrenharia tem como base a ciência e contribui para a evolução dela. É caracterizado 
por algoritmos de processamento de números, mas as novas aplicações dentro da área científica vêm afastando-
-se dos algoritmos numéricos convencionais, por exemplo, software de geoprocessamento.
O software de engenharia tem sido aplicado para projetar e calcular plantas de engenharia, o que tornou os gran-
des empreendimentos e projetos de engenharia mais rápidos, reduzindo em 50% o tempo de obras em grandes 
indústrias – tudo isso por conta da precisão de cálculo dessas ferramentas.
5.2.4 Software Embutido
São programas construídos para serem executados dentro de um produto específico. O software embutido é uti-
lizado para implementar e controlar características e funções para o usuário final e para o próprio sistema. Pode 
realizar funções muito limitadas e particulares, como as teclas digitais de um forno micro-ondas, controle de 
combustível para carros e outras.
Esse tipo de software é um sistema completamente incluído em um dispositivo ou sistema que ele controla. Dife-
rentemente de computadores de propósito geral, um sistema embutido realiza um conjunto de tarefas deter-
minadas geralmente com requisitos únicos. O sistema é dedicado a tarefas específicas, por isso pode otimizar o 
projeto, diminuindo recursos computacionais e custo do produto.
O software escrito para sistemas embutidos é muitas vezes chamado de firmware e armazenado em memória 
flash ou uma memória ROM ao invés de um disco rígido. Geralmente, esse sistema é executado com recursos 
computacionais mínimos, por exemplo, sem teclado ou sem tela. Todos esses fatores também contribuem para 
a redução do custo desse tipo de software. 
Firmware: Conjunto de regras operacionais programadas diretamente no hardware de um 
equipamento eletrônico. 
Glossário
5.2.5 Software para Linhas de Produtos 
Softwares para linhas de produtos são conhecidos como softwares de prateleiras e são projetados para fornecerem 
uma capacidade específica a ser usada por muitos clientes diferentes. Ou seja, não são criados de forma perso-
naliza para um problema específico, mas sim para o uso de um grande número de usuários. Processamento de 
texto, de planilhas e de multimídia são alguns dos exemplos desse tipo de software.
80
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
Figura 5.2 – Software para Linhas de Produtos.
Legenda: A figura mostra alguns exemplos de software para linhas de produtos.
Fonte: Plataforma Deduca (2018).
5.2.6 Software de Web ou Webapps
Software de web ou webapps são aplicativos executados via internet. É um termo usado para programas de software 
que rodam completamente dentro do seu navegador de internet (exemplos de navegadores: Chrome, Firefox ou 
Safari). As páginas da web acessadas por um browser concebem um software que incorpora comandos executáveis 
(CGI, HTML, Java) e dados. São, na verdade, sites que utilizam tecnologias de browsers modernos para rodarem de 
forma muito similar a apps completos. Como exemplo, podemos destacar os sites de compras on-line.
Atualmente os sites são capazes de rodar sistemas inteiros como “webapps”, por exemplo, o Chrome OS, do Goo-
gle, ou o Firefox OS, da Mozilla.
5.2.7 Software de Inteligência Artificial
Softwares de Inteligência Artificial fazem uso de algoritmos não numéricos para solucionarem problemas com-
plexos e que não podem ser analisados pela diretamente. Esse tipo software encaixa-se na robótica; atualmente 
a área de inteligência artificial, que vimos na Unidade 3, é a mais intensa em pesquisas e desenvolvimento e está 
relacionada aos sistemas especialistas baseados em conhecimento (SGC). Há outras aplicações para o software 
de inteligência artificial, como o conhecimentode padrões de imagem e voz. 
Nesse software, existe uma rede neural que simula a estrutura dos processos cerebrais, assim como a função dos 
neurônios humanos, e pode levar a uma nova classe de software que consegue reconhecer padrões complexos e 
armazenar seu aprendizado, construindo um aprendizado por experiência.
81
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
5.3 Engenharia de Software
Agora que entendemos todos os tipos de software, vamos conhecer os conceitos de engenharia de software. 
Segundo Sommerville (2010, p. 5), engenharia de software é:
Uma disciplina da engenharia que se ocupa de todos os aspectos da produção de software, desde 
os estágios iniciais de especificação do sistema até a manutenção desse sistema, depois que ele 
entrou em operação.
É importante destacar dois pontos nessa definição: “disciplina da engenharia”, que retrata a aplicação de teorias, 
métodos e ferramentas adequadas; e “todos os aspectos da produção de software”, o que esclarece que a enge-
nharia de software não é responsável somente pelos processos de desenvolvimento, mas também por todo o 
gerenciamento de projetos de software e pelo desenvolvimento de mecanismos de apoio à produção do software.
Pressman (2016, p. 30) define que engenharia de software é “a criação e a utilização de sólidos princípios de 
engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em 
máquinas reais”.
Como já sabemos, existem vários tipos de sistemas de software. Diferentes tipos de software exigem abordagens 
diferentes de métodos ou técnicas universais para a engenharia de software. Ainda existem muitos relatos e pro-
jetos de software que falharam. 
A engenharia de software é criticada por ser inadequada para o desenvolvimento moderno de software. No 
entanto, muitas dessas falhas são decorrentes de dois fatores apontados por Sommerville (2010):
• Aumento de demanda: conforme novas técnicas de engenharia de software nos auxiliam a construir sis-
temas maiores e mais complexos, as demandas mudam. Os sistemas têm que ser construídos e entregues 
mais rapidamente; sistemas maiores e até mais complexos são requeridos; sistemas devem ter novas 
capacidades que antes eram consideradas impossíveis. Como os métodos de engenharia de software 
existentes não conseguem lidar com isso, novas técnicas de engenharia de software precisam ser desen-
volvidas para atender a essas novas demandas.
• Expectativas baixas: é relativamente fácil escrever programas computacionais sem usar técnicas e 
métodos de engenharia de software. Muitas empresas foram forçadas a desenvolver softwares à medida 
que seus produtos e serviços evoluíram. Elas não usam métodos de engenharia de software no dia a dia. 
Consequentemente, seu software é frequentemente mais caro e menos confiável do que deveria ser. Pre-
cisamos de educação e treinamento em engenharia de software para solucionar esses problemas.
Na perspectiva Pressman (2016), a engenharia de software é tratada como uma “tecnologia em camadas”, cujo 
foco está na qualidade do software desenvolvido. Toda iniciativa de engenharia de software deve ser apoiada por 
um compromisso com a qualidade; e, acima da qualidade, encontram-se os processos; acima destes, os méto-
dos; e acima destes últimos, as ferramentas, como demonstrado na figura a seguir. 
82
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
Figura 5.3 - Camadas da Engenharia de Software.
Ferramentas
Métodos
Processo
Foco na qualidade
Legenda: Camadas da engenharia de software na perspectiva de Pressman.
Fonte: Pressman (2016, p. 39). 
5.3.1 Processo do Software
O processo de software é o conjunto de etapas que levam à produção de software. Na história da engenharia de 
software, apareceram ferramentas computadorizadas para auxiliar em seu desenvolvimento. Essas ações tiveram 
bastante progresso, mas ainda precisam da intervenção humana. Foram criados diversos modelos de processos 
de software, mas nenhum pode ser considerado o modelo único e ideal. 
O processo de software pode ser descrito em quatro atividades fundamentas, como você pode observar na figura 
a seguir.
Figura 5.4 - Processo de software.
Especificação
de software
Projeto e
implementação
de software
Validação
de software
Evolução
de software
Legenda: Quatro etapas básicas de processo de software.
Fonte: Elaborada pela autora (2018).
A especificação de software, chamada de engenharia de requisitos, tem como objetivo estabelecer as funções 
requeridas pelo sistema e também as restrições de operação e desenvolvimento do sistema. 
A implementação transforma a especificação em um sistema executável. Essa etapa envolve o projeto e a progra-
mação do software, sendo que o projeto é a definição da estrutura do software e dos dados que integram o sistema.
A atividade de validação, também chamada de verificação e validação, certifica que o sistema está conforme as espe-
cificações e dentro das expectativas. Essa etapa inclui revisões e inspeções em cada fase do processo de software.
Por fim, a evolução de software trata da necessidade de modificações no software, o que é comum, já que que as 
necessidades dos usuários mudam. O gerenciamento de projetos age como suporte ao processo de desenvolvi-
mento, sendo indispensável para garantir a qualidade do software. 
Vemos assim que que os processos de software são complexos e, como todos os processos intelectivos e inventi-
vos, dependem de pessoas para tomarem decisões e fazerem escolhas. Não existe um processo único e ideal para 
ser usado em qualquer contexto, por isso as empresas elaboram seus próprios processos de desenvolvimento 
83
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
de software, de maneira que que extraiam as capacidades das pessoas em uma organização e as características 
individuais do sistema em desenvolvimento. Em alguns sistemas, é importante um desenvolvimento bem estru-
turado; para outros, com requisitos que mudam rapidamente, provavelmente é mais eficaz um processo flexível 
– por essas razões, é relevante considerar o ambiente no qual o software estará inserido.
Vamos conhecer agora três modelos de processo de software. O primeiro é o modelo cascata, que considera as 
atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução, e que representa 
cada uma delas como fases separadas, como especificação de requisitos, projeto de software, implementação, 
teste e assim por diante, como representado na figura a seguir. 
Figura 5.5 – Modelo em Cascata.
Definição
de requisitos
Projeto de sistema
e software
Implementação
e teste unitário
Integração e teste
de sistema
Operação e
manutenção
Legenda: Modelo em cascata de processo de desenvolvimento de software.
Fonte: Sommerville (2010, p. 20).
Já o modelo de desenvolvimento incremental intervala as atividades de especificação, desenvolvimento e valida-
ção e é desenvolvido como uma sequência de versões (incrementos), de modo que cada versão acrescenta uma 
funcionalidade à anterior, como mostra a figura a seguir.
84
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
Figura 5.6 – Modelo de Desenvolvimento Incremental.
Descrição
do esboço
Especificação
Desenvolvimento
Validação
Versões
intermediárias
Versão inicial
Versão final
Atividade simultânea
Legenda: Modelo em cascata de processo de desenvolvimento de software.
Fonte: Sommerville (2010, p. 22).
O modelo de desenvolvimento de software orientado ao reuso é fundamentado na existência de um grande 
número de componentes reusáveis. Esse processo foca na integração desses componentes em um sistema já 
existente ao invés de desenvolver um sistema totalmente novo.
Figura 5.7 – Modelo Orientado a Reuso.
Especificação
de requisitos
Análise de
componentes
Alterações no
 requisitos
Projeto de sistema
com reuso
Desenvolvimento
e integração
Validação 
e sistema
Legenda:Modelo desenvolvimento de software orientado a reuso.
Fonte: Sommerville (2010, p. 23).
Esses modelos podem ser usados em conjunto, sobretudo quando se tratam de sistemas de grande porte, nos 
quais se combinam os modelos em cascata e incremental.
É essencial levantar as informações sobre os requisitos do sistema para projetar uma arquitetura de software que 
viabilize esses requisitos. 
Os subsistemas dentro de um sistema maior podem ser desenvolvidos com diferentes modelos. Vamos conhecer 
mais sobre a engenharia de requisitos na próxima unidade de estudo.
85
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
5.3.2 Engenharia de Software e a internet
A ampliação da internet teve efeito profundo em nossas vidas. No início, a internet era basicamente um arma-
zenamento de informações e não possuía muitos efeitos nos sistemas de software. Esses sistemas eram executa-
dos em computadores locais, sendo acessados somente dentro das empresas. Por volta do ano 2000, a internet 
começou a evoluir e mais recursos foram sendo adicionados aos navegadores, o que quer dizer que os sistemas 
web poderiam ser desenvolvidos e acessados por um navegador. Esse fato, consequentemente, levou ao desen-
volvimento de uma enorme quantidade de novos softwares acessados via internet. 
Veja o infográfico com a história da internet pelo link <https://www.teforgcmundo.com.br/
infografico/9847-a-historia-da-internet-pre-decada-de-60-ate-anos-80-infografico-.htm. 
Assim como esses produtos de software, o desenvolvimento de navegadores web capazes de executar pequenos 
programas e realizar algum processamento local possibilitou a evolução do software corporativo e organizacional.
Ao invés de escrever o software e instalá-lo ou atualizá-lo nos computadores dos usuários, ele é colocado em um 
servidor web, o que implica no barateamento de mudanças e atualizações desse software.
O estágio seguinte no desenvolvimento de sistemas web foi a noção de web services, que são partes de software 
acessadas pela internet e que oferecem uma função específica e útil. Recentemente, desenvolveu-se a ideia de 
“software como serviço”, em que o software não é executado em computadores locais, mas sim em “nuvens com-
putacionais” acessadas pela internet. Um bom exemplo desse tipo de serviço é o webmail.
O surgimento da internet trouxe uma mudança expressiva no modo como o software corporativo é organizado. 
Anteriormente, as aplicações corporativas eram programas isolados executando em computadores isolados ou 
em clusters de computadores. Agora, um software é repartido pelo mundo todo. As aplicações corporativas envol-
vem reuso extensivo de componentes e programas. Essa mudança na organização de software obviamente pro-
vocou alterações no modo como os sistemas web são projetados. 
A internet impactou não somente o desenvolvimento dos softwares, como também trouxe melhorias no arma-
zenamento de dados. É uma tendência atual o armazenamento de dados em nuvem. As empresas têm buscado 
como alternativa o armazenamento na nuvem e diminuindo o investimento em servidores locais, isso porque o 
armazenamento na nuvem é mais barato e ainda diminui a necessidade de investir em hardware.
5.3.3 Práticas de Engenharia de Software 
Em um livro clássico, How to Resolve It, escrito antes que os computadores existissem, George Polya (1945), citado 
como referência por Pressman (2010), esboçou a essência da solução de problemas e, consequentemente, a 
essência da prática de engenharia de software. Consiste em quatro etapas, sendo possível trazer perguntas, refle-
tir sobre as respostas e solucionar o problema:
https://www.teforgcmundo.com.br/infografico/9847-a-historia-da-internet-pre-decada-de-60-ate-anos-80
https://www.teforgcmundo.com.br/infografico/9847-a-historia-da-internet-pre-decada-de-60-ate-anos-80
86
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
1. Entenda o problema (comunicação e análise).
Quem tem interesse na solução do problema? Isto é, quem são os interessados? Quais são as incógnitas? Que 
dados, funções, características e comportamentos são necessários para resolver adequadamente o problema? O 
problema pode ser compartimentalizado? É possível representar problemas menores que podem ser mais fáceis 
de entender? O problema pode ser representado graficamente? Um modelo de análise pode ser criado?
2. Planeje uma solução (modelagem e projeto de software).
Você já viu problemas semelhantes? Existem padrões que são reconhecíveis em uma solução potencial? Há 
algum software que implemente dados, funções, características e comportamentos requeridos? Um problema 
semelhante foi resolvido? Em caso afirmativo, há elementos da solução reutilizáveis? Podem ser definidos sub-
problemas? Em caso afirmativo, há soluções prontamente aparentes para os subproblemas? Você pode repre-
sentar uma solução de modo que leve à implementação efetiva? Um modelo de projeto pode ser criado?
3. Execute o plano (geração de código).
A solução está de acordo com o plano? O código-fonte pode ser rastreado até o modelo de projeto? Cada com-
ponente parte da solução está provavelmente correto? O projeto e o código foram revisados, ou melhor, foram 
aplicadas provas de correção ao algoritmo?
4. Examine o resultado quanto à precisão (teste e garantia de qualidade).
É possível testar cada componente que é parte da solução? Foi implementada uma estratégia de teste razoável? 
A solução produz resultados que estão de acordo com dados, funções, características e comportamentos neces-
sários? O software foi validado com base em todos os requisitos dos interessados?
No contexto da engenharia de software, essas etapas de bom senso conduzem a uma série de questões essenciais.
Figura 5.8 – Boas Práticas.
Legenda: Questões essenciais para boas práticas em engenharia de software.
Fonte: Plataforma Deduca (2018).
http://jkolb.com.br/?p=9427
http://jkolb.com.br/?p=9431
http://jkolb.com.br/?p=9436
http://jkolb.com.br/?p=9439
87
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software 
Pressman (2010) traz ainda sete princípios baseados em David Hooker, que se concentram na prática da enge-
nharia de software como um todo. Confira a seguir a descrição desses princípios na íntegra:
1. Primeiro princípio: a razão de existir - um sistema de software existe por uma razão: gerar valor para seus 
usuários. As decisões devem ser tomadas com base nesse princípio. Ao pensar no requisito de um sis-
tema, indicar alguma funcionalidade e determinar as plataformas, pergunte a si mesmo: “Isso realmente 
agrega valor ao sistema?”. Os outros princípios apoiam-se nesse primeiro.
2. Segundo princípio: KISS (Keep It Simple, Stupid!, ou seja: não complique!) - o projeto de software não é um 
processo ao acaso. Ele deve ser o mais simples possível, mas não simplista; portanto, deve ser fácil de com-
preender e manter. Às vezes, são necessárias várias iterações para simplificar. 
3. Terceiro princípio: mantenha a visão - uma visão clara é importante para o sucesso. Sem uma integridade 
de conceito, o projeto corre o risco de se tornar uma colcha de retalhos inconciliáveis e ligados por para-
fusos impróprios, tornando a arquitetura frágil. 
4. Quarto princípio: o que um produz, outros consomem - um sistema de qualidade industrial é construído 
e utilizado de forma isolada. Portanto, especifique, projete e implemente ciente de que outros precisarão 
entender o que você está fazendo. O público para qualquer produto de desenvolvimento de software é 
potencialmente grande. Especifique com foco nos usuários e projete tendo em mente os implementado-
res. Busque facilitar o trabalho de todas essas 
5. Quinto princípio: esteja aberto para o futuro - um sistema com tempo de vida mais longo tem mais valor. 
Entretanto, os sistemas com “qualidade industrial” devem durar mais. Para atingir a expectativa, esses 
sistemas precisam estar prontos para ajustarem-se a mudanças. Sistemas de sucesso são aqueles queforam projetados nesse princípio. Não limite o sistema em seu projeto, sempre pergunte “e se” e prepare-
-se criar sistemas que resolvam o problema geral, não apenas o específico. Isso acarretara na reutilização 
de um sistema inteiro. 
6. Sexto princípio: planeje com antecedência, visando à reutilização - a reutilização poupa tempo e esforço. 
Atingir um alto grau de reutilização é uma meta difícil ao desenvolver um sistema.  A reutilização de 
código em projetos de software traz vantagem do uso de tecnologia orientada a objetos. As possibilidades 
de reutilização exigem planejamento e capacidade de fazer previsões. Planejar para a reutilização reduz o 
custo e aumenta o valor tanto dos componentes reutilizáveis quanto dos sistemas 
7. Sétimo princípio: pense! - esse princípio é o mais esquecido. Pensar certo e de forma precisa antes de 
tomar ação produz resultados melhores.  Uma consequência da análise é aprender a saber quando se 
desconhece algo e até que ponto poderá buscar o conhecimento. 
Aplicar os seis primeiros princípios exige intensa reflexão e as recompensas em potencial são enormes.
88
Considerações finais
Nesta unidade, vimos muitos conteúdos importantes em engenharia de 
software. Vamos retomar os pontos principais estudados até aqui.
• Os softwares podem ser classificados como software de sistemas e 
software de aplicação, software científico/de engenharia, software 
embutido, software para linha de produtos, aplicação para web e 
software de inteligência artificial. 
• Os processos de software são as atividades relacionadas à produ-
ção de um sistema de software. 
• Modelos de processos de software são exibições abstratas desses 
processos.
• Modelos gerais de processo descrevem a organização dos proces-
sos de software, como o modelo em cascata, o desenvolvimento 
incremental e o desenvolvimento orientado a reuso.
• As boas práticas de engenharia de software passam por quatro 
questões principais: entender o problema; planejar uma solução; 
executar o plano e examinar o resultado. 
• Sete princípios são importantes na prática de engenharia de sof-
tware que podem ser sintetizados da seguinte forma: 1 - software 
tem uma razão de existir; 2 - software deve ser simples; 3 - tenha 
uma visão clara do projeto;4 -o que um produz outro consome; 5- 
sistema deve estar aberto para o futuro; 6- foque na reutilização; 
7 - pense!
Referências bibliográficas
89
PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software - Uma 
Abordagem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968p. 
ISBN 9788580555332.
RESENDE, Denis Alcides; ABREU, Aline França de. Tecnologia da Infor-
mação Aplicada a Sistemas de Informação Empresariais. 9. ed. São 
Paulo: Editora Atlas, 2014. ISBN digital 9788522490455
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: A. Wesley 
publishing company, 2010. 552p
STAIR, R. M. Princípios de sistemas de informação. São Paulo: Cengage 
Learning, 2016.
91
6Unidade 6
Engenharia de Requisitos
Para iniciar seus estudos
Caro aluno, seja bem-vindo à sexta unidade do nosso curso!
Planejar e elaborar uma solução computacional é tão desafiador quanto 
divertido. Para 10 entre 10 desenvolvedores, a parte mais divertida (para 
não dizer a única divertida) é transformar em código, o mais rapida-
mente possível, tudo aquilo que imaginam ser a solução do problema. 
Essa pressa, infelizmente, caminha pari passu com a falta de cuidado pelas 
fases iniciais do processo de software, principalmente a de requisitos.
Justamente para que o delineamento inicial da solução mereça de sua 
parte o máximo zelo é que reservamos toda esta unidade para tratar 
somente dos requisitos de software. 
Em seu primeiro tópico, o texto aborda os conceitos fundamentais de 
requisitos, com ênfase para a classificação dos requisitos. Na sequência, 
as fases da engenharia de requisitos são conceituadas e, por meio da des-
crição de cada uma delas, entenderemos todo o processo que nos levará 
a requisitos corretamente registrados e validados. Essas fases incluem o 
estudo de viabilidade, o levantamento dos requisitos, a análise dos requi-
sitos, a especificação e, por fim, a validação dos requisitos.
Desejamos que a leitura deste conteúdo e a execução das demais ativida-
des propostas produzam ótimos frutos para sua vida profissional.
Sigamos adiante!
92
Objetivos de Aprendizagem
• Compreender sobre conceitos da análise de requisitos, identifi-
cação de envolvidos, cenários de uso, principais técnicas para o 
levantamento de requisitos, modelagem baseada em cenários.
Definitivamente, desenvolver uma solução computacional apta a atender 
a expectativas e necessidades de quem a demandou não é tarefa simples. 
A dificuldade de comunicação entre equipe de desenvolvimento e cliente, 
a adoção de procedimentos equivocados (ou a falta deles) e a dificuldade 
natural de criar um programa correto são condições que, consideradas de 
forma isolada ou combinada, podem culminar em expectativas frustradas 
e necessidades mal atendidas.
Mas será que não temos como mudar isso? Há uma saída; o aprimora-
mento das práticas de trabalho e a estruturação de metodologias efi-
cientes de desenvolvimento de software têm ajudado a reduzir os casos 
de insucesso nos projetos ou, na pior das hipóteses, a mitigar seus efeitos.
Uma das providências mais úteis que uma equipe pode adotar para 
aumentar suas chances de sucesso em um projeto de software é dispensar 
total atenção ao processo de requisitos, do levantamento à validação. E é 
justamente disso que trata esta unidade. Fique com a gente e prepare-se 
para conhecer o desafiador universo dos requisitos de software.
93
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
6.1 Conceitos fundamentais de requisitos de software
Conforme tratamos na Unidade 4, requisitos são as condições necessárias para que um evento aconteça. Con-
tudo, essa definição nos parece bastante genérica e convém contextualizá-la para o ambiente de Sistemas de 
Informação. Podemos entender os requisitos como as necessidades e as restrições que incidem em um produto 
de software. Sommerville (2010) torna ainda mais específico o conceito ao afirmar que os requisitos de um sis-
tema são as descrições dos serviços fornecidos pelo sistema e as suas restrições funcionais. Esses requisitos refle-
tem as necessidades dos clientes de um sistema que ajuda a resolver algum problema.
Ao analisarmos o conceito de requisito, podemos até nos sentir à vontade para afirmar que 
tudo o que for imaginado para o sistema deverá ser identificado como um requisito. Mas 
será mesmo que seremos capazes de conceber tudo (tudo mesmo) sobre o sistema antes de 
sequer iniciarmos seu desenvolvimento? 
Para que você possa entender o que se quer dizer com “serviços fornecidos” e com “restrições funcionais”, deve-
mos classificar os requisitos conforme alguns critérios. Vejamos:
Requisitos funcionais
São requisitos que descrevem as funções que o software irá executar. Por exemplo, emitir um relatório semanal 
de vendas ou permitir que o usuário edite um dado da produção. Os requisitos funcionais definem a funcionali-
dade que o software possuirá de forma a possibilitar que os usuários tenham êxito na realização das suas tarefas. 
Em outras palavras, os requisitos funcionais descrevem o comportamento planejado do sistema, podendo ser 
expressos como serviços, tarefas ou funções que o sistema irá executar.
É evidente que um bom levantamento e uma boa descrição (saberemos como fazê-los logo adiante) desses 
requisitos serão de fundamental importância para o sucesso do projeto. Em contrapartida, uma especificação 
falha das funções do sistema pode gerar ambiguidade no momento em que o projetista tiver de interpretá-la 
para desenhar a solução do problema.
Consideremos como exemplo um sistema bancário. Um dos requisitos funcionais expressa que o “sistema deverá 
prover relatórios gerenciais para acompanhamento das transações de clientes”. O termo “transaçõesde clientes” 
pode (e certamente irá) suscitar no desenvolvedor interpretação diversa daquela pretendida pelo engenheiro 
de requisitos. A verdadeira intenção desse requisito pode ter sido, por exemplo, a de prever que sejam relatadas 
apenas as transações mais significativas, cujo valor tenha excedido um limite estabelecido. 
Como essa intenção não está claramente expressa, um desenvolvedor sob pressão quanto ao prazo poderá pre-
ver apenas um relatório geral e alegar que o requisito está sendo cumprido. Conveniente, porém incorreto.
94
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Requisitos não funcionais
Requisitos não funcionais são aqueles que restringem a solução de um problema. Segundo Sommerville (2010), 
os requisitos funcionais, como o nome sugere, são aqueles não diretamente relacionados às funções específicas 
fornecidas pelo sistema. 
É comum que requisitos não funcionais se refiram de modo universal ao sistema e não a suas peculiaridades. Dessa 
forma, tornam-se, com frequência, mais importantes que requisitos funcionais analisados individualmente.
Se os requisitos funcionais nascem, basicamente, da necessidade expressa pelo usuário, quais seriam então as 
fontes dos não funcionais? De modo indireto, o usuário também poderá ser fonte de um requisito não funcional, 
mas suas principais origens incluem, por exemplo, necessidade de operação conjunta com outro sistema, res-
trições impostas pelo orçamento do projeto, políticas próprias da organização, restrições de armazenamento de 
dados, leis que incidem nos sistemas e muitas outras.
Os requisitos não funcionais podem ser classificados como:
• Requisitos de produto: especificam como o produto deve comportar-se em um modo específico. A 
velocidade de execução, a confiabilidade, a reusabilidade e a portabilidade são requisitos de produto.
• Requisitos organizacionais: requisitos que emanam da política e dos métodos adotados na organiza-
ção, tais como procedimentos padrão usados e linguagem de programação padrão na organização.
• Requisitos externos: nessa ampla classificação, encontram-se os requisitos de interoperabilidade com 
sistemas de outras organizações, requisitos legais e éticos.
Pela óptica de Sommerville (2010), essa classificação deve ser ampliada e incluir ainda outros tipos de requisitos 
não funcionais, conforme mostra a Figura 6.1.
Requisitos de usuários
Embora a separação de requisitos funcionais e não funcionais seja fundamental e constitua parte importante 
do processo de análise de requisitos (trataremos da análise de requisitos adiante), ela não inclui a totalidade de 
classificações úteis a serem feitas.
95
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Figura 6.1- Tipos de requisitos não funcionais.
Requisitos
não funcionais
Requisitos
de produto
Requisitos
organizacionais
Requisitos
de entrega
Requisitos de
implementação
Requisitos
de padrões
Requisitos
externos
Requisitos de
interoperabilidade
Requisitos
éticos
Requisitos
legais
Requisitos de
privacidade
Requisitos de 
egurança
Requisitos de
facilidade de uso
Requisitos
de eficiência
Requisitos de
desempenho
Requisitos
de espaço
Requisitos de
confiabilidade
Requisitos de
]portabilidade
Legenda: Os requisitos não funcionais desdobram-se em muitas 
classificações, mas não fazem parte diretamente das funcionalidades do sistema.
Fonte: Sommerville (2010, p. 82).
Os analistas costumam especificar requisitos de modo que os usuários ou, de modo amplo, os envolvidos não 
técnicos no projeto, possam compreendê-los. A esses requisitos, dá-se o nome de requisitos de usuário.
Sommerville (2010) defende que requisitos dirigidos ao usuário na especificação (esse documento será abor-
dado adiante) devem refletir apenas o comportamento externo do sistema e evitar detalhes do projeto, assunto 
normalmente fora do escopo do interesse do usuário comum. 
Deve-se evitar termos de natureza técnica e texto em excesso. Ao contrário, é aconselhado o uso de notações 
gráficas, tabelas, formulários e diagramas.
Parece-nos bastante conveniente expressar os requisitos dessa maneira. Mas será que o formato de especifica-
ção de requisitos dirigido a um usuário é suficientemente bom para definir por completo a solução do problema 
e ser base para o projeto do software?
96
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Requisitos de sistema
Para que a descrição dos requisitos seja de fato apta a orientar o desenho (ou projeto) do sistema, é necessário 
que ela encampe questões técnicas e definições detalhadas dos requisitos, o que não se espera em especifica-
ções voltadas ao usuário.
Essa demanda é suprida pela especificação dos requisitos de sistema. Sommerville (2010) trata os requisitos de 
sistema como versões expandidas dos requisitos de usuário e como ponto de partida para o projeto do sistema. 
Essa especificação pode ser feita usando linguagem natural, mas os cuidados na descrição devem ser tomados a 
fim de evitar ambiguidades e flexibilidade demasiada no entendimento. O engenheiro de requisitos pode descrever 
algo que o projetista interprete de modo distinto ao desejado e, então, estaremos diante de um mal-entendido 
nada desprezível.
Enfim, usando linguagem natural ou outro tipo de notação, os requisitos de sistema devem descrever o compor-
tamento do sistema e suas restrições de operação.
Feita esta introdução, a partir do próximo item do nosso conteúdo, trataremos da engenharia de requisitos e das 
etapas que nos levam a um documento que agrupa e detalha todos os requisitos do sistema. Adiante!
6.2 Engenharia de requisitos de software
É muito comum que as ações e práticas da Engenharia de Software sejam descritas por meio de etapas ou sequ-
ências de passos. Embora não prescritivas, essas sequências conferem alguma segurança e confiabilidade ao 
processo, já que servem de guia para quem as conduz.
As questões ligadas aos requisitos de software não fogem a essa regra. O processo geral de requisitos leva o nome 
de Engenharia de Requisitos e serve para descrever as etapas que culminam na criação de um documento que 
descreve os requisitos de modo consistente e confiável.
Não se pode esperar, contudo, que os requisitos não se alterem antes de tornarem-se realidade em um produto 
de software. Por isso, além do estudo de viabilidade, do levantamento, da análise, da especificação e da validação 
dos requisitos, a engenharia de requisitos reserva uma etapa que cuida apenas do gerenciamento das mudanças 
que certamente serão necessárias, seja pela mudança de pontos de vista em relação ao sistema, seja pela evolu-
ção do conhecimento do cliente sobre ele.
Começamos nosso estudo sobre Engenharia de Requisitos pela estruturação visual do tema. A Figura 6.2 ilustra 
as etapas do processo de engenharia de requisitos (nas formas elípticas) e os artefatos gerados em cada uma 
delas (nas formas retangulares), além do fluxo de comunicação existente entre eles.
97
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Figura 6.2 – Processo de Engenharia de Requisitos.
Estudo de
viabilidade
Relatório de
viabilidade
Elicitação e
análise de 
equisitos
Especificações
de requisitos
Validação
de requisitos
Modelos de
sistema
Requisitos de usuário
e de sistema
Documento
de requisitos
Legenda: O processo de Engenharia de Requisitos inclui etapas definidas que se estendem do 
estudo de viabilidade do sistema à elaboração de documento consistente de requisitos.
Fonte: Sommerville (2010, p. 96).
Na sequência, trataremos com detalhes das etapas da engenharia de requisitos, com destaque para o docu-
mento de especificação de requisitos.
Estudo de viabilidade
Imagine a cena: você é procurado por um conhecido e bem-sucedido empresário da sua cidade e, durante a con-
versa, você descobre que ele deseja um sistema totalmente inovador para gerenciar seu negócio. Entre uma reunião 
e outra, ele revela que seu orçamento é baixo,o prazo é bastante pequeno e que, embora o sistema faça brilhar seus 
olhos, a ideia de investir nele não foi recebida com simpatia em sua própria organização. Você deixa a reunião com 
uma pergunta bastante perturbadora em mente: “embora tentador, será mesmo que esse sistema é viável?”.
Em uma abordagem mais próxima da realidade das organizações, o estudo de viabilidade deve responder a três 
questões básicas, segundo Sommerville (2010):
1. O sistema contribui para os objetivos gerais da organização? É mais comum do que parece: um empresá-
rio, ao navegar pela internet, descobre um site muito atraente, aparentemente útil e recheado de opções 
interessantes. Para sua decepção, o site é do seu concorrente. Apressado, convoca toda sua equipe para 
construir algo parecido, sem dar-se conta que aquele tipo de site não contribui em nada para os objetivos 
da sua empresa. 
2. O sistema pode ser implementado com a tecnologia atual disponível e respeitando restrições de custo e 
prazo? O caso que relatamos no início deste tópico ilustra perfeitamente esta situação.
98
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
3. Será possível integrar o novo sistema a outros já existentes? É muito comum que sistemas não operem de 
forma isolada. Integrar sistemas novos a outros já existentes economiza recursos e, com frequência, ajuda 
a unificar as fontes dos dados.
A compilação das informações sobre a viabilidade de um sistema deve compor o que chamamos de relatório de 
viabilidade. Com o aval de pessoas com poder de decisão sobre a continuidade do processo, o fluxo segue em 
direção ao levantamento (ou à elicitação) dos requisitos.
Elicitação dos requisitos
No decorrer das unidades anteriores, apontamos certos itens do conteúdo que valiam muito a sua atenção. 
Registramos, inclusive, que dominar aquele assunto poderia ajudá-lo a ser referência na área. Pois bem, aqui 
estamos diante de mais um tema apto a ser eleito um divisor de águas. 
Dominar as técnicas de levantamento de requisitos ajuda não só a lhe tornar um ótimo profissional, mas a 
aumentar a qualidade do produto gerado nessa fase; simples assim.
Embora, em algum estágio do processo, possa ser auxiliado por uma ferramenta computacional, o levantamento 
de requisitos é atividade essencialmente humana, que requer habilidade em trabalhar com especialistas huma-
nos e com conhecimento tácito.
Conhecimento tácito: Aquele adquirido no decorrer da vida e pela atividade profissional do 
indivíduo. Por ser inerente, é difícil de ser explicado e formalizado. O conhecimento tácito, via 
de regra, é trivial para quem o possui. 
Glossário
Como as fontes dos requisitos são muitas e variadas, é natural que os meios para os obter também o sejam. Antes 
de abordá-las, convém registrar uma visão geral a respeito dos envolvidos no processo de requisitos, afinal, é 
deles que emanam as funcionalidades e é deles o interesse maior no sistema.
O termo stakeholder é usado comumente no meio que define os entes que, de alguma forma, participam ou têm 
interesse em um projeto. Pressman e Maxim (2016) definem stakeholder como qualquer pessoa que se beneficie 
de forma direta ou indireta do sistema que está sendo desenvolvido. Cada um com visões e interesses distintos, 
é nos gerentes, colaboradores, equipe de marketing, time de vendas e futuros usuários que reside o interesse no 
sistema; sobre eles, o engenheiro de requisitos deve dispensar atenção na busca pelos requisitos.
Isso posto, avancemos para dois dos principais meios de elicitação (ou levantamento) de requisitos.
99
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Entrevista
Antes da sua aplicação, a entrevista deve ser planejada. Seus objetivos devem ser fixados, seu local e roteiro 
definidos e os entrevistados criteriosamente escolhidos. O entrevistado é aquele que detém o conhecimento 
do negócio e o entrevistador é o engenheiro de requisitos. A conversa deve ser objetiva e, durante seu curso, o 
entrevistador deve tentar esclarecer conceitos e circunstâncias relacionados ao domínio do problema para então 
ter condições de propor ideias que integrarão o domínio da solução.
Três tipos de entrevistas são as mais comuns. A primeira é a entrevista tutorial; nela, o entrevistado assume o 
comando e procura explicar em detalhes aspectos daquele determinado procedimento. Na entrevista informal, 
não se segue roteiro previamente definido e a conversa flui conforme a natureza das perguntas. Por fim, nas 
entrevistas estruturadas, há um roteiro anteriormente definido de perguntas a serem feitas.
Na condição de profissional de requisitos, você deve avaliar o perfil do entrevistado e o tipo de informação que 
deseja dele para decidir pelo melhor formato de entrevista.
Aplicação de questionário
O questionário geralmente é aplicado em formulário distribuído para os futuros usuários do sistema. Seu ela-
borador deve utilizar questões diretas e objetivas, dispostas preferencialmente na mesma ordem para todos os 
participantes, e que consigam extrair respostas sobre o procedimento atual adotado.
Lembre-se: nem todos os futuros usuários se sentem à vontade ao responderem perguntas feitas pessoalmente, 
ainda mais em ocasiões em que outras pessoas estejam presentes. Nesse sentido, o questionário pode ser uma 
boa maneira de extrair informações dos envolvidos.
A observação do procedimento atual, as reuniões estruturadas e o levantamento de documentos são outros 
meios eficientes para elicitar requisitos. Utilizados de forma isolada ou em conjunto, esses métodos visam extrair 
todos os requisitos possíveis, de forma bruta e ainda não verificada. 
Etnografia é uma técnica de observação e sua inserção no contexto do levantamento dos 
requisitos pode ser uma ótima ideia. Assista ao vídeo disponível em <https://www.youtube.
com/watch?v=6bmFRAQDJEM> e saiba mais sobre esse interessante assunto. 
Será na próxima etapa que os requisitos serão classificados, analisados e preparados para fazerem parte do docu-
mento de requisitos.
https://www.youtube.com/watch?v=6bmFRAQDJEM
https://www.youtube.com/watch?v=6bmFRAQDJEM
100
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Análise dos requisitos
Concluída a elicitação, tem início a análise de requisitos. Essa etapa no processo de requisitos pode ser entendida 
também como uma avaliação da qualidade das descrições dos requisitos levantados. As medições dos requisitos 
fornecem retorno de informação (feedback) para um processo de decisão, que inicia alterações no processo de 
requisitos para melhorar o seu desempenho e o seu resultado.
Nessa etapa, os requisitos são classificados segundo os critérios descritos na introdução deste texto. Um requisito pode 
ser funcional, não funcional, de usuário ou de sistema. Outros critérios podem ser incluídos nessa classificação: 
• A prioridade do requisito: quanto mais alta a prioridade, mais essencial o requisito. Com efeito, pode-se 
classificar o requisito como obrigatório, altamente desejável, desejável ou opcional.
• Volatilidade/estabilidade: alguns requisitos irão mudar durante o ciclo de vida do software ou mesmo 
durante o processo de desenvolvimento. Pode ser bastante útil a estimativa de probabilidade de alteração 
de um requisito. Por exemplo, em um sistema bancário, os requisitos de funções que calculam os juros a 
serem pagos pelo devedor tendem a ser mais estáveis que requisitos que dão suporte a um certo tipo de 
conta livre de taxas.
Elaboração da Especificação dos Requisitos de Software (ERS)
Refere-se à produção de um documento contendo os requisitos levantados e analisados que podem ser sistema-
ticamente revistos, avaliados e aprovados.
Ele estabelece um contrato entre cliente e desenvolvedor. Geralmente, é escrito em linguagem natural, e forma 
uma base realista para estimativas de custos, riscos e cronograma. A IEEE padronizou o formato do ERS por meio 
da norma IEEE 830-1998.
Uma boa especificação de requisitosde software pode propiciar diversos benefícios a clientes, fornecedores e 
outros indivíduos envolvidos no projeto. Entre esses benefícios, destacam-se:
1. Estabelece a base para a concordância entre clientes e fornecedores sobre aquilo que o software deve 
produzir. A descrição completa das funções a serem realizadas pelo software especificada na ERS irá aju-
dar os usuários potenciais a determinar se o software especificado atende às suas necessidades ou como 
o software deve ser modificado para atendê-las.
2. Reduz o esforço para o desenvolvimento, pois a preparação de uma ERS força que os vários grupos pre-
ocupados com a organização (empresa, instituição de ensino etc.) considerem rigorosamente todos os 
requisitos antes que o projeto se inicie, reduzindo retrabalhos posteriores. Uma revisão cuidadosa dos 
requisitos na ERS pode trazer à tona omissões e falhas em fases iniciais no ciclo de desenvolvimento, 
quando esses problemas são mais fáceis de corrigir.
3. Fornece base para estimativa de custos e agendas, já que a descrição do produto a ser desenvolvido é 
uma base realista para a estimativa dos custos do projeto e pode ser usada como referência de preço do 
produto.
4. Fornece uma linha de base para validação e verificação. As organizações podem desenvolver seus planos 
de validação e verificação de forma muito mais produtiva a partir de uma boa ERS.
5. Serve como uma base para melhoramentos. A ERS trata o produto, mas não o projeto que o desenvolverá. 
Por conta disso, serve como uma base para melhorias posteriores do produto finalizado. A especificação 
em si não deve ser alterada, mas ela fornece um alicerce para a evolução contínua do produto.
101
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Algumas questões são de abordagem obrigatória no documento de especificação de requisitos de software:
Funcionalidade: o que se espera que o software faça?
Interfaces externas: como o software interage com as pessoas, com o hardware ou com outro software?
Desempenho: quais são a velocidade, a disponibilidade, o tempo de resposta, o tempo de recuperação?
Um documento de ERS deve incluir seção que contenha a descrição dos fatores gerais que afetam o produto e 
seus requisitos, sem, contudo, declará-los. Alguns desses fatores gerais incluem:
Perspectiva do produto: esta subseção deve colocar o produto na perspectiva de outros produtos relacionados. 
Se o produto é independente e totalmente autossuficiente, isso deve ser declarado aqui.
Funções do produto: aqui, deve-se fornecer um sumário (resumo) das principais funções que o software irá exe-
cutar. Por exemplo, uma ERS de um programa gerenciador de contas pode usar essa parte para abordar a manu-
tenção da conta do cliente e da preparação da fatura, sem mencionar a vasta quantidade de detalhes que cada 
uma dessas funções requer. Por uma questão de clareza, as funções devem ser organizadas de um modo que 
torne a lista de funções compreensível para o cliente ou para qualquer um que leia o documento pela primeira 
vez. Além disso, métodos textuais ou gráficos podem ser usados para mostrar diferentes funções e seus relacio-
namentos. Tal diagrama não deve ser usado com a intenção de mostrar o projeto do produto, mas simplesmente 
mostrar os relacionamentos lógicos existentes.
Características do usuário: devem ser descritas aquelas características gerais dos usuários em potencial do 
produto, incluindo nível de educação, experiência e especialidade técnica.
Restrições: esta subseção da ERS deve fornecer uma descrição geral de quaisquer outros ıtens que irão limitar 
as opções do desenvolvedor. Inclui, entre outros itens, limitações de hardware, consideração sobre segurança, 
requisitos de confiabilidade.
Bem, parece não haver dúvida de que o documento que especifica os requisitos deve ser cuidadosamente elabo-
rado e conter o máximo possível de informação pertinente. 
A última etapa da engenharia de requisitos é a da validação. De nada adiantaria fazermos a aquisição dos requi-
sitos, classificá-los, documentá-los e não os conferir. 
Validação dos requisitos
O documento de especificação deve ser alvo de verificação e validação. Por meio da validação, conseguiremos 
responder às seguintes perguntas: “aquilo que fiz é o que deveria ser feito? Aquilo que fiz corresponde aos requi-
sitos?”. Com a verificação, saberemos se “aquilo que fiz está correto?”.
A validação serve para assegurar que o engenheiro compreendeu os requisitos e se estes são consistentes e com-
pletos. Na validação, devem participar vários representantes de stakeholders. 
Imagine um cenário em que os responsáveis pelos requisitos não os submetem à validação de pessoas-chave no 
projeto ou sequer revisam o documento de especificação. Nessa situação, erros de interpretação dos requisitos do 
sistema serão propagados para as fases seguintes do processo, comprometendo projeto e codificação do produto.
102
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
O custo de correção de um problema relacionado a requisitos cresce na medida em que as 
etapas do processo avançam. Por isso, é providência salutar validar os requisitos com equipe 
e com usuário antes de prosseguir. Mesmo assim, é muito importante que pequenos trechos 
do produto sejam entregues ao cliente para que ele os valide antes de o sistema definitivo 
estar concluído. 
Algumas providências devem ser tomadas para que a confiabilidade do documento de requisitos seja mantida. 
Uma delas é a verificação de elementos contidos na ERS, tais como (SOMMERVILLE, 2010):
Consistência: deve-se verificar se não há conflito entre requisitos. Tomemos como exemplo uma hipotética situ-
ação em que o sistema é descrito como autônomo e, em outra parte da especificação, ele é descrito como um 
sistema que terá interface com outro programa para fins de obtenção de dados de entrada.
Completeza: deve-se verificar se todos os requisitos foram especificados na ERS antes de prosseguir.
Realismo: será mesmo que todos os requisitos especificados são factíveis? A equipe conseguirá implementá-los? 
Orçamento, prazo e recursos tecnológicos disponíveis devem ser considerados ao respondermos a essas questões.
Por mais inovadora e útil que pareça ser uma função especificada na ERS, ela deve possuir a característica de ser 
facilmente verificável. Em outras palavras, o analista deve ser capaz de escrever casos de teste para aferir se a 
função está correta de fato.
Antes de terminarmos nossa abordagem sobre requisitos, vale um registro sobre composição de cenários. Se é 
verdade que imagens dizem mais do que palavras, a criação de descrições visuais das funções e características 
pode ser ótima providência para o entendimento do futuro sistema.
Pressman e Maxim (2016) sustentam que desenvolvedores e usuários podem criar cenários que descrevam um 
roteiro de uso para o sistema. Casos de uso é o nome que se dá a esses cenários e eles serão discutidos em outra 
oportunidade.
Aí está o que queríamos tratar sobre requisitos. Como a maioria dos assuntos próprios do mundo da Tecnologia 
da Informação, as práticas relacionadas ao assunto não param de ser aperfeiçoadas. Adequar os conceitos e 
aprimorar os processos é condição obrigatória para que o profissional de sistemas permaneça atualizado e apto 
a desempenhar bem suas funções.
Continue perseverante e até a próxima unidade.
103
Considerações finais
Esta unidade tratou especificamente dos requisitos de software, com con-
teúdo que abrangeu desde conceitos iniciais até o documento final de 
especificação de requisitos. 
Conceitos fundamentais de requisitos de software
Em linhas gerais, requisitos são as condições necessárias para que um 
evento aconteça. Em termos mais próximos ao contexto da tecnologia da 
informação, os requisitos de um sistema são as descrições dos serviços 
fornecidos pelo sistema e as suas restrições funcionais. Esses requisitos 
refletem as necessidades dos clientes de um sistema que ajuda a resolveralgum problema.
As principais classificações dos requisitos incluem:
• Requisitos funcionais: são requisitos que descrevem as funções 
que o software irá executar. Por exemplo, emitir um relatório sema-
nal de vendas ou permitir que o usuário edite um dado da pro-
dução. Os requisitos funcionais definem a funcionalidade que o 
software deve prover a fim de capacitar os usuários a realizarem 
suas tarefas.
• Requisitos não funcionais: requisitos não funcionais são aqueles 
que restringem a solução de um problema. Como o nome sugere, 
são aqueles não diretamente relacionados às funções específicas 
fornecidas pelo sistema. 
Para fins de organização, vários tipos de requisitos funcionais 
foram classificados. Alguns dos mais importantes incluem requi-
sitos de produto, requisitos organizacionais e requisitos externos. 
• Requisitos de usuários: os analistas costumam especificar requi-
sitos de modo que os usuários – ou, de modo amplo, os envolvidos 
não técnicos no projeto – possam compreendê-los. A esses requi-
sitos, dá-se o nome de requisitos de usuário.
• Requisitos de sistema: para que a descrição dos requisitos seja 
de fato apta a orientar o desenho (ou projeto) do sistema, é neces-
104
sário que ela encampe questões técnicas e definições detalhadas 
dos requisitos, o que não se espera em especificações voltadas ao 
usuário. Essa demanda é suprida pela especificação dos requisitos 
de sistema.
Engenharia de requisitos de software
O processo geral de requisitos leva o nome de Engenharia de Requisitos 
e serve para descrever as etapas que culminam na criação de um docu-
mento que descreve os requisitos de modo consistente e confiável. As 
etapas da engenharia de requisitos são: 
• Estudo de viabilidade: o estudo de viabilidade deve responder 
a três questões básicas: (i) o sistema contribui para os objetivos 
gerais da organização?; (ii) o sistema pode ser implementado com 
a tecnologia atual disponível e respeitando restrições de custo e 
prazo?; (iii) será possível integrar o novo sistema a outros já exis-
tentes?
• Elicitação de requisitos: o levantamento de requisitos é ativi-
dade essencialmente humana, que requer habilidade em traba-
lhar com especialistas humanos e com o conhecimento tácito. 
Como as fontes dos requisitos são muitas e variadas, é natural que 
os meios para os obter também o sejam. As entrevistas, a aplica-
ção de questionários, as reuniões e a própria observação das ativi-
dades dos usuários estão entre os meios mais eficientes para que 
se possa levantar requisitos.
• Análise de requisitos: nesta etapa, os requisitos são classifica-
dos em funcional, não funcional, de usuário e de sistema. Outros 
critérios podem ser incluídos nessa classificação: a prioridade do 
requisito e sua volatilidade/estabilidade.
• Elaboração das Especificações dos Requisitos de Software: nesta 
etapa, é produzido um documento contendo os requisitos levanta-
dos e analisados e que podem ser sistematicamente revistos, avalia-
dos e aprovados.
105
Em situação ideal, ele deve estabelecer a base para a concordância entre 
clientes e fornecedores, reduzir o esforço para o desenvolvimento do 
produto, fornecer estimativa para custos e agendas e servir de base para 
futuros melhoramentos no sistema. As funções do produto, as caracte-
rísticas dos usuários e as restrições aplicadas ao produto são algumas das 
informações que devem constar do documento.
• Validação dos requisitos: o documento de especificação deve 
ser objeto de verificação e validação. A consistência, a completeza 
e o realismo devem ser verificados a fim de averiguar se os requi-
sitos são factíveis.
Referências bibliográficas
106
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software - Uma Aborda-
gem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968 p. ISBN 
9788580555332.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: A. Wesley 
Publishing Company, 2010. 552p.
108
7Unidade 7
Manutenção e Reengenharia 
Para iniciar seus estudos
Você está iniciando a sétima unidade da disciplina Fundamentos de Siste-
mas de Informação. Já passamos por uma série de conteúdos importan-
tes; agora, você vai conhecer sobre manutenção de software e reenge-
nharia. Vamos em frente!
Objetivos de Aprendizagem
• Conhecer sobre manutenção de software e suporte.
• Conceituar reengenharia de software e engenharia reversa.
• Entender os aspectos econômicos da reengenharia. 
109
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
7.1 Manutenção de Software 
A manutenção de software é o processo geral de mudança em um sistema logo após ser liberado para uso, ou 
seja, a manutenção começa quase que imediatamente, pois os usuários finais começam a operar o software e os 
relatos de problemas começam a chegar. 
A manutenção compreende as alterações feitas no software, as quais podem ser pequenas, apenas para correção 
de erros de codificação; ou mais complexas, para a correção de erros de projeto ou melhorias expressivas a fim de 
ajustar erros de especificação e ainda novos requisitos.
Não existe um consenso sobre os tipos de manutenção de software. Para Sommerville (2010), a manutenção de 
software engloba três atividades: manutenção corretiva, manutenção adaptativa e manutenção evolutiva. Press-
man e Maxim (2016) acrescentam um quarto tipo de manutenção: a manutenção preventiva, também chamada 
de reengenharia. Vamos ver detalhadamente os quatros tipos de manutenção.
Quadro 7.1 – Tipos de Manutenção de Software
TIPO DE MANUTENÇÃO DESCRIÇÃO
Manutenção corretiva Este tipo de manutenção acontece quando é necessário corrigir erros no 
software que não foram identificados na fase de testes e que podem ser 
solucionados por meio de simples reparos. Caso existam erros mais complexos 
e que necessitem de um reparo temporário para que o software voltar a 
executar suas funções básicas, é comum corrigi-los e disponibilizar uma nova 
versão. 
Erros de códigos são mais baratos de serem corrigidos; já os erros de projeto 
são mais caros e podem demandar a reescrita de vários componentes de 
programa. Por fim, os erros de requisitos são os mais caros para corrigir devido 
à necessidade de, muitas vezes, reprojetar o sistema.
Manutenção Adaptativa  Esse tipo de manutenção é imprescindível quando algum aspecto do ambiente 
do sistema sofre uma mudança, como por exemplo o hardware ou a plataforma 
do sistema operacional ou a integração com outro software de apoio. 
Manutenção Evolutiva 
 (ou perfectiva)
A manutenção evolutiva é indicada quando os requisitos de sistema são 
modificados por causa de uma mudança organizacional ou de negócio. 
A proporção de mudanças necessárias para o software é maior nesse 
tipo de manutenção quando comparada aos outros tipos. Ela pode ser 
uma manutenção crítica e o foco deve estar na melhoria da qualidade do 
software, muitas vezes acrescentando novas funcionalidades, melhorando e 
aprimorando seu desempenho, ou até mesmo alterando seu código-fonte 
a fim de alcançar melhor legibilidade ou adequação a alguns modelos de 
programação. 
Manutenção Preventiva 
(reengenharia)
A manutenção preventiva objetiva melhorar a estrutura de um software, 
reduzindo sua complexidade ou tornando-o mais compreensível. Essa 
manutenção antecipa a geração de um possível problema ou algum tipo 
de erro. As modificações que são feitas nessa manutenção melhoram a 
confiabilidade do software e a estrutura para futuras manutenções.
Legenda: O quadro apresenta os tipos de manutenção e suas caracteristicas. 
Fonte: Elaborado pelo autor (2018).
http://www.leandromtr.com/tecnologia-informacao/software-pressman/
http://www.leandromtr.com/tecnologia-informacao/software-pressman/
110
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Assista ao filme “A Rede Social” (2010) e observe quantas versões e manutenções do sof-
tware o programador necessitou executar. 
Agora que conhecemos os tipos de manutenção, é importante esclarecer três conceitos:manutenção de sof-
tware; arquitetura de software; e reengenharia de software.
• A manutenção de software trata-se, de modo geral, das mudanças que são feitas em resposta à modifi-
cação de requisitos; mas a estrutura fundamental permanece estável. 
• A arquitetura do software é modificada geralmente de uma arquitetura centralizada para uma arquite-
tura distribuída.
• Na reengenharia de software, nenhuma funcionalidade é adicionada ao sistema, mas ele é reestruturado 
e reorganizado para facilitar mudanças futuras.
No momento em que um software é inserido em um novo ambiente, é possível adicionar novas funcionalidades e 
aproveitar as novas características do ambiente. Os defeitos de software tornam-se evidentes quando o sistema 
é utilizado de formas inesperadas; por isso, adaptá-lo para acomodar o modo de trabalhar do usuário é a melhor 
forma de corrigir tais defeitos.
Figura 7.1 – Recall de software.
Legenda: Quando o software entra em operação, seus defeitos serão apontados pelo usuário, o que demandará correções.
Fonte: Plataforma Deduca (2018).
Como vimos, a manutenção do software é extremamente necessária. Ela é importante para que o software evo-
lua. No século XX, foram difundidas oito leis da evolução de software, de autoria de Meir Lehman. Segundo Pon-
tes (2012) Lehman nasceu na Alemanha e foi para a Inglaterra na década de 1930, tendo trabalhado na IBM entre 
1964 e 1972. Em 1974, publicou o que seria conhecido pelo mundo como as “Leis de Lehman”, que tratavam 
da evolução de software. Nessa época, a abordagem dessas leis era bastante técnica e não levava em conta 
111
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
as pessoas. Já no final do século XX, com a identificação por parte de empresas e profissionais de software da 
necessidade de uma abordagem mais humana, o software ganhou relevância estratégica em todas as empresas 
e difundiu-se em larga escala na vida das pessoas, demandando uma abordagem mais holística. 
Sobre as Leis de Lehman os autores Pontes (2012) e Sommerville (2010) citam estas leis com importantes para a 
manutenção de software. Veremos agora o que estes autores dizem a respeito destas leis.
A primeira lei de Lehman diz que a manutenção é irremediável; um programa deve ter uma mudança contínua e, 
se isso não ocorrer, ele se tornará insatisfatório com o tempo. O software, quando modificado, volta ao ambiente 
promovendo mais mudanças, de forma que o processo de evolução recomeça.
A segunda lei trata da complexidade crescente do software. Ela alega que, conforme um software é alterado, 
sua complexidade aumenta. Para evitar que isso ocorra, é imprescindível investir em manutenção preventiva. É 
importante haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.
A terceira lei aborda a autorregulação. A evolução de um software é um processo autorregulador, o que significa 
que sistemas de grande porte têm um movimento próprio, que é estabelecido no início do processo de desenvol-
vimento, e determina a tendência geral da manutenção de sistema e restringe o número de possíveis alterações.
A quarta lei de Lehman está relacionada à estabilidade organizacional. A mudança de recursos ou de pessoal não 
tem muito impacto na evolução do sistema, o que se traduz em equipes de desenvolvimento de software com 
baixa produtividade. 
 A quinta lei de Lehman fala sobre a familiaridade do software. Isso significa que, durante a vida do software a 
mudança incremental é constante e está relacionada ao quanto o time de desenvolvedores está familiarizado 
com o software. 
Já a sexta e a sétima leis tratam respectivamente de crescimento contínuo e de declínio de qualidade. Significa 
que devem ser oferecidas aos usuários novas funcionalidades, visto que o projeto inicial pode não incluir tudo o 
que é necessário e funcionalidades são adicionadas progressivamente. Em relação ao declínio de qualidade, esta 
diminui se o sistema não for modificado para refletir as mudanças no ambiente de operação. 
A oitava e última lei fala sobre feedback. Os processos de evolução e manutenção de um software refletem siste-
mas de feedback em vários níveis, o que torna o sistema mais significativo.
As leis de Lehman precisam ser consideradas no planejamento de manutenção. Sommerville (2010, p. 171) diz que:
A manutenção de software ocupa uma proporção maior dos orçamentos de TI que o desenvol-
vimento. A manutenção detém, aproximadamente, dois terços do orçamento, contra um terço 
para desenvolvimento, se gasta mais do orçamento de manutenção na implementação de novos 
requisitos do que na correção de bugs.
Nos dados indicados por Sommerville (2010), vemos a distribuição dos custos de manutenção.
112
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Gráfico 7.1 – Distribuição do Esforço de Manutenção.
Correção de 
defeitos 
(17%)
Adaptação 
de ambiente 
(18%)
Adição ou 
modificação de 
funcionalidade 
(65%)
Legenda: Gráfico que demonstra a ação de esforço de manutenção.
Fonte: Adaptado de Sommerville (2010, p. 172). 
Percebemos que a correção de defeitos de sistema é a atividade menos onerosa. Já a adição de funcionalidades 
consome mais da metade do esforço de manutenção. Podemos afirmar que os custos relacionados à manuten-
ção são equivalentes aos custos de desenvolvimento de sistema. Com isso, fica evidente a seriedade que deve-
mos ter ao investir um grande esforço no projeto e na implementação de um sistema para a redução de custos 
de mudanças futuras. Além disso, podemos elencar como artefatos que contribuem para a redução de custos de 
manutenção a descrição exata dos requisitos; o uso de desenvolvimento orientado a objetos; e o gerenciamento 
de configurações do software.
Quando o software não foi desenvolvido de forma organizada, de acordo com uma metodologia de desenvolvi-
mento e com requisitos claros e devidamente registrados, a manutenção não pode ser feita de forma estrutu-
rada. Uma manutenção estruturada é composta das etapas indicadas na figura a seguir.
Figura 7.2 – Etapas da Manutenção.
Avaliar a
documentação
existente
Planejar a
abordagem de
manutenção
Modificar
o projeto
Modificar
o código
Revisar e
efetuar testes 
Legenda: Figura que descreve a sequência das etapas de manutenção.
Fonte: Elaborada pelo autor (2018).
Avaliar a documentação existente de um software é a primeira ação para a manutenção. Muitas vezes, essa docu-
mentação não existe, é incompreensível ou está desatualizada. A documentação de software é um componente 
cujo intuito é comunicar a informação sobre o sistema de software ao qual ele pertence. É importante distinguir 
entre modelos, documentos, código-fonte; nesse sentido, a documentação de software é entendida aqui como 
documentos elaborados durante a execução do software e comentários de código-fonte. A documentação tem 
grande importância para a Engenharia de Software. 
113
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Atualmente, muitos estudos têm sido realizados para diminuir os problemas em torno da documentação de 
software. Entre os problemas, podemos citar documentação de baixa qualidade e desatualizada; processos de 
documentação caros e dispendiosos; excesso de documentação, mas sem relevância e finalidade; dificuldade de 
acesso etc.
A segunda etapa de manutenção é o planejamento do tipo de manutenção que será adotado. A partir da análise 
da documentação do software, será possível determinar qual será o tipo de manutenção a ser aplicado e a estra-
tégia de execução.
As modificações de projeto e de código estão relacionadas ao que se usará como estratégia de execução da fase 
anterior. A necessidade de alteração do projeto e do código tem grande impacto e alto custo, por isso, é impor-
tante estar alinhada com a estratégia e a necessidade da empresa em que o software está inserido. Softwares 
com grande volume de informações e histórico da empresa precisamser tratados com bastante atenção, pois 
contêm um volume de dados e informações históricas da empresa que precisam ser protegidos e mantidos. 
Por fim, tem-se a fase de revisão e testes do software. Na entrega para homologação, testes serão executados e os 
erros corrigidos. É uma boa prática ter um ambiente isolado do desenvolvimento para a realização desses testes 
funcionais. À medida que erros são detectados no teste, solicitações de modificações são registradas e executadas. 
O esforço de manutenção pode ser dividido em atividades produtivas, tais como análise, avaliação, modificação 
do projeto, codificação; e atividades lógicas, como entender a estrutura do sistema.
O custo de manutenção pode aumentar se a metodologia usada no desenvolvimento for ruim ou se o desenvol-
vedor do software não estiver disponível para realizar a manutenção. 
Figura 7.3 – Custo de manutenção do software.
Legenda: Para atender à sua finalidade, o software demanda um esforço 
de construção, o que implica em custos para a empresa.
Fonte: Plataforma Deduca (2018).
114
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Os problemas mais comuns relacionados à manutenção de software são:
• problema de rastrear o processo por meio do qual o software foi criado; 
• problema de rastrear o processo de evolução do software por causa de suas muitas versões;
• dificuldade de compreender o programa que outra pessoa fez;
• falta de disponibilidade da pessoa que desenvolveu o software;
• documentação do desenvolvimento do software inexistente ou muito ruim;
• software não projetado para receber mudanças.
Além desses problemas, temos ainda a pouca manutenibilidade do software. Entendemos aqui como manuteni-
bilidade de software a facilidade de um software ser entendido, corrigido, adaptado e/ou aumentado. 
Vamos ver os fatores que afetam a manutenibilidade do software:
• projeto, codificação e testes conduzidos de forma inadequada;
• configuração de software ruim;
• pessoal qualificado;
• facilidade de manusear o sistema;
• uso de linguagens de programação padronizadas;
• estruturas padronizadas de documentação;
• disponibilidade de um computador próprio para a manutenção;
• disponibilidade de pessoa ou grupo que desenvolveu o software.
É importante que haja um planejamento para a manutenção de software, portanto, é necessário aferir quais 
mudanças no sistema podem ser propostas e que partes do sistema são as mais difíceis de serem mantidas. 
Nesse planejamento, você precisa prever os custos de manutenção para um sistema em determinado período 
de tempo. A figura a seguir nos ajuda a esclarecer as previsões e as repostas que devemos ter para fazer esse 
planejamento de manutenção.
115
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Figura 7.4 – Previsão de Manutenção.
Previsão de 
manutenção
Quais partes do sistema serão 
mais caras para serem 
mantidas?
Previsão de custos 
de manutenção
Qual será o custo de manu-
tenção durante o tempo de 
vida desse sistema?
Quais serão os custos de 
manutenção desse sistema 
durante o próximo ano?
Previsão de 
mudanças de 
sistema
Quantas solicitações de
mudança podem ser esperadas?
Quais partes do sistema são mais 
suscetíveis de serem afetadas por 
solicitações de mudança?
Legenda: Questões importantes da previsão de manutenção.
Fonte: Adaptada de Soomerville (2011 p. 173).
A manutenção do software pode ser considerada um sucesso quando foi desenvolvida uma estratégia de manu-
tenção para gerenciar modificações feitas no software e a migração de dados, além de ter identificado o impacto 
das alterações feitas no sistema existente. Somado a isso, a documentação afetada deve ter sido atualizada; 
como vimos, a documentação é um item bastante crítico para futuras manutenções. Ademais, é preciso que a 
integridade dos dados tenha sido mantida e que os testes desenvolvidos tenham demonstrado que os requisi-
tos não foram comprometidos. O software já em produção deve ter sido migrado para o ambiente do cliente e 
a versão anterior retirada de maneira controlada, de forma que o usuário não tenha sido impactado. Por fim, as 
modificações devem ter sido informadas a todos os envolvidos. 
Se todos esses itens foram atendidos, saberemos que a manutenção foi efetiva e realizada com sucesso. 
7.2 Reengenharia de Software 
Como vimos, o processo de evolução de software envolve o entendimento do que deve ser mudado e, depois, a 
implementação dessas mudanças. Entretanto, sistemas, especialmente os legados, são difíceis de compreender 
e modificar. O programa pode ter sido melhorado depois de algum tempo e sua estrutura primitiva pode ter sido 
corrompida por uma série de mudanças.
Para fazer com que os sistemas legados de software sejam mais simples de serem mantidos, é preciso aplicar 
reengenharia nesses sistemas, objetivando a melhoria de sua estrutura e inteligibilidade. O termo reengenharia 
está relacionado com a reconstrução de algo independentemente de seu uso e objetiva buscar melhorias que 
consigam produzir algo de qualidade igual ou superior ao produto inicial. Ou seja, a reengenharia tem como prin-
cipal objetivo melhorar um sistema por meio de mudanças significantes, mas sem alterar suas funções.
116
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Inteligibilidade: Característica que se espera de um software; está relacionada à qualidade de 
ser inteligível, ou seja, de ser compreendido. 
Glossário
A reengenharia pode envolver:
A redocumentação de sistema, a refatoração da arquitetura de sistema, a mudança de linguagem 
de programação para uma linguagem moderna e modificações e atualizações da estrutura e dos 
dados de sistema. A funcionalidade de software não é alterada, e você geralmente deve evitar 
grandes mudanças na arquitetura de sistema (SOOMERVILLE, 2016, p. 174).
Segundo Pressman e Maxim (2016), a reengenharia recupera informações de projeto de um software existente 
e utiliza essas informações para modificar ou reconstituir o sistema, conservando as funções existentes e, ao 
mesmo tempo, acrescentando novas funções ao software, em um esforço para melhorar sua qualidade como um 
todo. Para Sommerville (2010), a reengenharia de software é descrita como a reorganização e a modificação de 
sistemas de software existentes, parcial ou totalmente, para tornar possível a manutenção.
As dificuldades de manutenção de sistemas legados devem-se ao fato de que esses sistemas não são simples 
de programar e desenvolver. Em geral, são compostos por diferentes programas que compartilham dados. Esses 
programas, ao longo dos anos, foram desenvolvidos por diferentes pessoas que, muitas vezes, já não fazem mais 
parte da empresa. Por vezes, o sistema de administração de banco de dados pode estar arcaico ou sujeito a dados 
armazenados em outros bancos de dados; por isso, informações estão duplicadas e representadas em diferentes 
formatos de arquivos. Essa duplicidade acontece devido à integração com as estruturas de dados dos programas. 
 Para diminuir os problemas causados por manutenções complicadas, muitas organizações estão escolhendo 
refazer seus sistemas, ou seja, as informações de projeto e a especificação são extraídas do código-fonte e, a par-
tir daí, reformula-se e reconstrói-se o software. Como resultado, é gerado um software de manutenção facilitada. 
Aplicando-se a reengenharia de software, o sistema pode ser redocumentado ou reestruturado, os programas 
podem ser convertidos para uma linguagem de programação mais atualizada e implementados em uma plata-
forma distribuída. 
A reengenharia de software, portanto, objetiva conceber sistemas flexíveis e fáceis de alterar ante mudanças de 
necessidades de usuários e empresas. Assim, ao invés de substituir sistemas, a reengenharia de software traz 
duas importantes vantagens: redução de risco e redução de custo. Sommerville (2010, p. 173) coloca que:
Existe um alto risco em desenvolvernovamente um software crítico de negócios. Podem ocorrer 
erros na especificação de sistema ou pode haver problemas de desenvolvimento. Atrasos no iní-
cio do novo software podem significar a perda do negócio e custos adicionais... O custo de reen-
genharia pode ser significativamente menor do que o de desenvolvimento de um novo software.
As atividades do processo de reengenharia estão representadas na figura a seguir. A entrada para o processo é 
um programa legado, enquanto que a saída é uma versão melhorada e reestruturada do mesmo programa, sem 
alteração de sua funcionalidade.
117
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Figura 7.5 – Processo de Reengenharia
Programa
original
Tradução
de código-fonte
Engenharia
reversa
Documentação
do programa
Programa
reconstruído
Dados
originais
Melhoria de
estrutura de
programa
Modularização
do programa
Programa
reestruturado
Reengenharia
de dados
Dados
reconstruídos
Legenda: A figura demonstra todas as etapas do processo de reengenharia.
Fonte: Adaptada de Sommerville (2010 p. 173).
Veja que existe uma distinção entre os objetivos da reengenharia e os da engenharia reversa. 
O objetivo da engenharia reversa é prover o projeto ou a especificação de um sistema par-
tindo do código-fonte. Já a reengenharia visa produzir um sistema com maior facilidade de 
manutenção, sendo a engenharia reversa uma parte desse processo, fornecendo o entendi-
mento do sistema a ser reconstruído. 
Como demonstrado na figura, a etapa de tradução de código-fonte é a conversão de uma linguagem de progra-
mação antiga para uma versão mais moderna ou a adoção de uma outra linguagem de programação. 
A documentação de software é revisada ou, em alguns casos, elaborada propriamente na engenharia reversa. 
Nesse momento, o software é analisado e as informações a respeito do seu código são extraídas. 
Na etapa de melhoria de estrutura de programa, a estrutura de controle do programa é analisada e modificada 
para simplificar a leitura e a compreensão entendimento do software. Em seguida, ocorre a modularização de 
programa, que resolve o problema de redundância e duplicidades do sistema, armazenando os dados em único 
repositório. 
Já na reengenharia de dados, há o processamento de dados, a redefinição dos esquemas de banco de dados e a 
conversão do banco de dados existente para a nova estrutura.
Agora, vamos pensar sobre o custo de todo esse processo. É importante saber quando trocar um software ou 
quando melhorá-lo. Existem vários fatores que devem ser levados em conta, como os riscos e o valor que será 
118
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
necessário investir em qualquer uma das opções. Os custos da reengenharia dependem da complexidade e da 
extensão do trabalho. 
Observe a figura a seguir.
Figura 7.6 – Abordagem de Reengenharia.
Aumento de custo
Reestruturação de programa 
automatizada
Reestruturação de
programa e dados
Conversão de código-fonte 
automatizada
Reestruturação automatizada 
com mudanças manuais
Reestruturação mais 
mudanças de arquitetura
Legenda: A figura demosntra os custos da reengenharia.
Fonte: Adaptada de Sommerville (2010 p. 173).
Sobre a relação entre engenharia reversa e reengenharia, é possível fazer uma reengenharia 
sem a engenharia reversa? 
Os custos aumentam da esquerda para a direita. A tradução de código-fonte é a opção mais barata. A reenge-
nharia como parte da migração da arquitetura é a mais cara. Sobre isso, Sommerville (2010, p. 175) nos diz que: 
O problema com a reengenharia de software é que existem limites práticos para o quanto você pode 
melhorar um sistema por meio da reengenharia. Não é possível, por exemplo, converter um sistema 
escrito por meio de uma abordagem funcional para um sistema orientado a objetos. As principais 
mudanças de arquitetura ou a reorganização radical do sistema de gerenciamento de dados não 
podem ser feitas automaticamente, pois são muito caras. Embora a reengenharia possa melhorar a 
manutenibilidade, o sistema reconstruído provavelmente não será tão manutenível como um novo 
sistema, desenvolvido por meio de métodos modernos de engenharia de software.
Pressman e Maxim (2016) afirmam que para a aplicação de um processo de reengenharia, é necessário avaliar 
o custo/benefício. Os autores citam o modelo de custo proposto por Sneed, que é composto pelos seguintes 
parâmetros:
119
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Figura 7.7 – Parâmetros do Custo de Reengenharia.
P1
Custo anual de manutenção da aplicação. 
P2
Custo anual de operação da aplicação. 
P3
Valor comercial anual da aplicação. 
P4
Previsão do custo anual de manutenção após reengenharia.
P5
Previsão do custo anual de operação após reengenharia.
P6
Valor comercial anual após reengenharia.
P7
Custo estimado para reengenharia. 
P8
Previsão de tempo para realizar reengenharia (em anos).
P9
Fator de risco da reengenharia (fator multiplicador; 
por exemplo, 1,25 indicará que os custos com reengenharia 
podem crescer em 25%). 
L Expectativa de vida do sistema (em anos). 
Legenda: A figura demonstra parâmetros para avaliação do custo de reengenharia.
Fonte: Adaptada de Pressman e Maxim (2016 p. 678).
Com base nesses parâmetros, o custo de manutenção contínua do sistema dá-se por: 
( )3 – 1 2CMC P P P L= +   ⋅
E o custo da reengenharia é: 
( ) ( ) ( )6 – 4 5 – 8 – 7 9CR P P P L P P P= + ⋅ ⋅   
Portanto, a diferença entre o custo de manutenção contínua e o da reengenharia deve ser analisada para a 
tomada de decisão. Vale lembrar que essa análise está relacionada somente aos custos, mas há outros aspectos 
precisam ser considerados.
Como vimos, o processo de reengenharia de software objetiva recuperar informações do sistema por meio da 
engenharia reversa e promover a reconstrução parcial ou total do sistema. As estratégias devem ser definidas na 
avaliação dos riscos.
120
Considerações finais
Vamos retomar os pontos principais estudados até aqui?
• A manutenção de software acontece logo depois de o sistema ser 
liberado para os usuários.
• A manutenção compreende as alterações feitas no software, as 
quais podem ser pequenas mudanças para a correção de erros de 
codificação; mudanças mais complexas para correção de erros de 
projeto; ou melhorias expressivas para ajustar erros de especifica-
ção e ainda novos requisitos
• A manutenção de software engloba quatro tipos:  manuten-
ção corretiva, manutenção adaptativa, manutenção evolutiva e 
manutenção preventiva.
• Os custos relativos de manutenção são equivalentes aos custos de 
desenvolvimento de sistema.
• O esforço de manutenção pode ser dividido em atividades produti-
vas, como análise, avaliação, modificação do projeto e codificação.
• A manutenibilidade de software é a facilidade com que um sof-
tware pode ser entendido, corrigido, adaptado e/ou aumentado.
• É importante que haja um planejamento para a manutenção de 
software.
• O processo de evolução de software envolve o entendimento do 
que necessita ser mudado e, depois, a implementação dessas 
mudanças.
• A reengenharia tem como principal objetivo melhorar um sistema 
por meio de mudanças significantes, mas sem alterar suas funções.
• Ao invés de substituir sistemas, a reengenharia de software traz dois 
importantes benefícios: a redução de risco e redução de custo.
• Para a aplicação de um processo de reengenharia, é de extrema 
importância avaliar o custo/benefício e os riscos envolvidos.
Referências bibliográficas
121
PONTES, D. P. N.  Evolução de software baseada em avaliação de arqui-
teturas. 2012. Dissertação (Mestrado em Sistemas Digitais) - Escola 
Politécnica, Universidade de São Paulo, São Paulo, 2012. Disponível em 
<http://www.teses.usp.br/teses/disponiveis/3/3141/tde-14092012-
122012/en.php> Acesso em: 27 fev. 2018.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma aborda-
gem profissional. 8. ed. Porto Alegre:Amgh, 2016.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: A. Wesley 
publishing company, 2010.
http://www.teses.usp.br/teses/disponiveis/3/3141/tde-14092012-122012/en.php
http://www.teses.usp.br/teses/disponiveis/3/3141/tde-14092012-122012/en.php
123
8Unidade 8
Conceitos de Projeto
Para iniciar seus estudos
Caro aluno, seja bem-vindo à oitava e última unidade do nosso curso!
Você certamente já teve a oportunidade de ver o projeto de uma casa ou 
de uma construção semelhante. Toda a estrutura do imóvel está lá repre-
sentada: as divisões dos cômodos, o posicionamento de portas e janelas, 
a escada e por aí vai. Em dias atuais, inclusive, é possível até passear pela 
casa usando a ferramenta computacional certa, sem que uma parede 
sequer tenha sido erguida.
O projeto é a base de tudo e sua elaboração é feita por profissionais pre-
parados. Sem ele em mãos, o executor da obra não terá parâmetros ade-
quados para cumprir seu trabalho, mesmo que tenha boa noção do que 
deverá ser construído.
Os pontos de semelhança da Engenharia Civil com os processos relacio-
nados aos Sistemas de Informação passam longe da mera coincidência. 
Tanto lá como cá, a criação do desenho da solução é condição fundamen-
tal para que ela se torne realidade e um projeto bem feito abre portas para 
a construção de um sistema de igual qualidade.
Não por acaso, dedicamos toda esta unidade ao estudo do projeto de sof-
tware, desde seus conceitos fundamentais até a geração do artefato que 
sintetiza os objetivos dessa fase tão importante da Engenharia de Software.
Fique conosco, bom estudo e parabéns por ter chegado até aqui.
124
Objetivos de Aprendizagem
O aluno será capaz de compreender sobre conceitos de projeto e modelo 
do projeto (dados, arquitetura, interface, componentes e implantação).
125
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Tópicos de estudo
Acreditamos que uma forma bastante eficiente de iniciar a compreensão de um novo tema é por meio da com-
paração com outro, já estudado e bem sedimentado. Afinal, aprender as coisas novas a partir das já sabidas faz 
tudo parecer mais familiar e fácil de entender.
Nesse sentido, um parâmetro bastante apropriado para nossa iniciação no mundo do projeto de software é o 
que já sabemos sobre requisitos. Se os requisitos revelam aos analistas “o que” deve ser feito para que se obtenha 
determinado produto, o projeto revela “como” ele deverá ser elaborado. Durante a fase de requisitos, o enge-
nheiro busca informações do cliente para delimitar funções e estabelecer comportamentos do futuro sistema. 
Diz-se, portanto, que ao final da fase de requisitos, já temos a solução pelo ponto de vista do cliente/usuário. 
É na fase de projeto, por sua vez, que se planeja a arquitetura do produto, além do estabelecimento das interfaces 
com outros sistemas e das estruturas de dados.
Há muito assunto interessante a ser abordado nesta unidade e sua dedicação não será em vão. Preparado? Ini-
ciemos então pelos conceitos fundamentais de projeto de software.
8.1 Conceitos fundamentais de projeto de software
Elaborar um projeto faz parte da primeira etapa de desenvolvimento de qualquer produto ou sistema de enge-
nharia. No universo dos Sistemas de Informação, é a etapa que se inicia após a validação dos requisitos e sua 
meta é produzir um modelo ou uma representação do produto a ser construído. Para atingir tal objetivo, o pro-
jetista deve lançar mão de sua experiência, intuição, de metodologias e heurística. Modelos ou representações 
podem ser analisados quanto à sua qualidade e são base para as etapas seguintes do ciclo de vida do produto, 
quais sejam, codificação, teste, validação e manutenção.
Conceitualmente, projeto é o processo pelo qual os requisitos são traduzidos em uma representação do software. 
Qualquer que seja a metodologia escolhida para a criação do produto, o projeto será desenvolvido.
Sommerville (2010) define projeto como a descrição da estrutura de software a ser implementada, dos dados que 
são parte do sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.
É comum o entendimento de que o nível de detalhamento da solução que se aplica em um projeto deve ser sufi-
cientemente elevado a ponto de permitir a realização física do produto. Refinamentos sucessivos levam a uma 
representação próxima ao código-fonte e estima-se que, quanto mais detalhado for o projeto, mais imediata 
será a transição para a efetiva solução do problema.
Se é verdade que quanto mais se detalha os itens de um projeto, mais fácil será a implemen-
tação do produto, qual seria o limite razoável para esse detalhamento? Haveria um ponto em 
que o tempo investido na pormenorização de uma função não compensaria seus benefícios? 
126
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Quando estudamos o Extreme Programming, ficamos conhecendo, entre outras coisas, os princípios da metodo-
logia, e os alçamos à condição de pilares de todas as práticas do modelo. Pois bem, a fase de projeto de software 
também tem suas bases e, embora muitos conceitos relacionados ao tema tenham evoluído, esses paradigmas 
têm resistido ao tempo. Fique ciente de que os conceitos que analisaremos na sequência nos servirão quando da 
abordagem do processo de projeto.
8.1.1 Abstração
A solução modular leva a vários níveis de abstração. Abstrair é concentrar-se em certos aspectos relevantes ao 
ambiente do problema. Cada passo da Engenharia de Software diminui o nível de abstração em direção à solução 
do problema. O nível mais baixo de abstração é o código-fonte.
Abstração procedimental: ensinam Pressman e Maxim (2016) que a abstração procedimental (ou procedural) 
refere-se a uma sequência de instruções que possui uma função específica e limitada. O nome de uma abstração 
procedural indica sua função, mas sem os detalhes específicos.
Tomemos o esboço de uma aplicação tipo CAD como exemplo e dela consideraremos três níveis de abstração 
procedimental:
Abstração 1 - Descrição geral do produto
O software terá uma interface gráfica que possibilitará acesso à função de desenhos de linhas retas e curvas. Os 
desenhos serão armazenados em uma pasta de desenhos.
Abstração 2 - Tarefas do software CAD
• início tarefa
• interação com o usuário
• criação de desenhos
• exibição de gráficos
• gerenciamento de arquivos de desenho
• fim tarefa
127
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Abstração 3 - Procedimento de criação de desenho bidimensional
repetir ate que <tarefa de criação termine>
enquanto <ocorrer interação > faça
tarefa de interface
determinar pedido de desenho
tarefa de desenho de linha
fim enquanto
fim repetir
Observe que, no nível de abstração mais baixo, o detalhamento da solução aumenta e torna-se mais próximo da 
realização do código-fonte.
Abstração de dados: trata-se da descrição de um objeto por meio dos seus dados. Aqui, podemos tomar como 
exemplo a composição de um contracheque – ou holerite, como também é conhecido. Embora possa haver 
pequenas variações, a descrição dos dados desse objeto deve incluir nome do beneficiado, quantia bruta, quan-
tia líquida, horas normais trabalhadas, horas extras trabalhadas, desconto de Imposto de Renda e de INSS, entre 
outros. Nesse caso, referencia-se o conjunto de dados pelo nome da abstração (contracheque).
Arquitetura de software
De acordo com que ensinam Pressman e Maxim (2016), arquitetura é a estrutura ou a organização dos com-
ponentes do programa, a maneira como esses componentes interagem e a estrutura de dados que são usados 
pelos componentes. 
De uma forma simples e objetiva, a arquitetura do sistema pode ser representada por um diagrama de blocos 
que ilustra a organização do sistema e as interfaces com outros sistemas. Observe a figura a seguir; ela mostra a 
arquitetura de um sistema (não trivial e de porte considerável)de controle de tráfego aéreo.
128
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Figura 8.1: Arquitetura de um sistema de tráfego aéreo.
Banco de dados
de planos de
Sistema de
simulação da
aeronave
Sistema de
mapa de clima
Sistema de
relatórios
Sistema de registro 
de atividades
Sistema de 
informações 
do controlador
Consoles do
controlador
Back-up do
processador de
comunicação
Processador 
de 
comunicação
Back-up do
processador
de posição
Processador 
de posição
Sistema 
de radar
Sistema de
transponder
Sistema de
comunicação
de dados
Sistema de
comunicação
da aeronave
Sistema
telefônico
Legenda: O sistema de controle de tráfego aéreo não se resume a uma única 
aplicação. O fluxo de informações entre os subsistemas é mostrado por setas.
Fonte: Sommerville (2010, p. 22).
Pressman e Maxim (2016) descrevem três motivos para que a arquitetura do software seja considerada absoluta-
mente indispensável em um projeto: 
• A arquitetura de software fornece uma representação que facilita a comunicação entre todos os envol-
vidos. Como as conexões entre módulos e demais elementos do produto estão esclarecidas, o entendi-
mento da interação entre os desenvolvedores dos módulos acaba ficando facilitado também. No mesmo 
sentido, as divisões de trabalho certamente serão realizadas com base real.
• Desde a fase de projeto, a arquitetura coloca em evidência aquelas decisões de projeto que terão um 
profundo impacto no trabalho de engenharia de software que se segue.
• Já que a modularização serve para dividir um problema grande em vários outros menores, a arquitetura 
constitui um modelo relativamente pequeno e intelectualmente compreensível de como o sistema é 
estruturado e de como seus componentes trabalham em conjunto.
Os mesmos autores destacam que, assim como na arquitetura convencional, aquela que representa um produto 
de software também tem seus estilos. Cada estilo descreve uma categoria de sistema e especializa-se em um 
aspecto seu, incluindo um conjunto de componentes (um banco de dados, por exemplo), um conjunto de conec-
tores que, por exemplo, possibilita a comunicação do sistema, as restrições que estabelecem como os compo-
nentes podem ser integrados e outros. Analisemos dois desses estilos:
129
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Arquiteturas centralizadas em dados: este estilo de arquitetura é fortemente baseado em um banco de dados 
ou arquivo. Os componentes que atualizam, incluem ou excluem dados nessa base também têm destaque na 
representação. A figura a seguir ilustra esse estilo.
Figura 8.2: Arquitetura centralizada em dados.
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Software
cliente
Armazenamento
de dados (repositório
ou “quadro-negro”)
Legenda: A representação de um repositório de dados em posição central e os 
componentes que acessam esse repositório caracterizam a arquitetura centralizada em dados.
Fonte: Pressman e Maxim (2016, p. 259).
Em alguns casos o repositório de dados é passivo, isto é, o software cliente acessa os dados mesmo que estes 
sofram alterações ou ações de outros softwares clientes. Uma variação dessa abordagem faz com o que o reposi-
tório se transforme em uma espécie de “quadro-negro”. Ele envia notificações ao software cliente quando ocor-
rem modificações nos dados que são do seu interesse.
Arquiteturas de chamadas e retornos: este estilo de representação permite uma adequada visualização da hie-
rarquia entre programas chamadores e subprogramas chamados. A figura a seguir ilustra o estilo de chamadas e 
retornos, especificamente as ocorridas entre programas e subprogramas.
130
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Figura 8.3: Arquitetura de chamadas e retornos.
Programa principal
Subprograma
controlador
Subprograma
controlador
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
de aplicação
Subprograma
controlador
Legenda: O estilo de chamadas e retornos permite a visualização 
da hierarquia entre os subprogramas que compõem o produto.
Fonte: Pressman e Maxim (2016, p. 260).
A literatura ainda nos oferece os estilos de arquiteturas de fluxos de dados, arquiteturas orientadas a objetos e 
arquiteturas em camadas.
Embora o termo “arquitetura” remeta à organização dos módulos do sistema, ele também está associado a inter-
faces com outros sistemas e a estrutura de dados, por exemplo. No item dedicado ao processo de projeto, trata-
remos desses assuntos em detalhes.
Modularidade
Por causa da comum complexidade dos sistemas atuais, não é possível conceber a solução de um problema de 
maneira monolítica, sem as devidas divisões. Modularizar um software é “quebrar” seu projeto em partes meno-
res, mais facilmente administráveis e de realização mais simples.
Nenhuma dúvida resta sobre a necessidade de modularizar um sistema em sua fase de concepção, já que a 
complexidade embutida nos controles do programa e na quantidade de variáveis tornaria o trabalho pratica-
mente impossível. No entanto, ainda nos resta uma reflexão: se a subdivisão do problema em módulos menores 
é mesmo necessária, em quantas partes devemos dividi-lo? A relação “mais divisões, menos complexidade” fun-
ciona sempre? 
Para respondermos a essas questões, devemos considerar o custo (ou esforço) para a construção do módulo e 
para sua integração com os demais. Observe o gráfico a seguir; ele nos revela que o custo da integração aumenta 
conforme aumenta a quantidade de módulos a serem construídos. Outro fato relevante é que o custo por módulo 
é reduzido conforme sua quantidade aumenta. Em outras palavras, um módulo grande e complexo custa mais 
para ser construído que um pequeno e que acomoda uma função apenas (trataremos de módulos com uma só 
função nas próximas linhas).
131
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
O gráfico então aponta para um ponto central, identificado como “M”, em que a quantidade de módulos e o 
custo para produzi-los equilibram-se mutuamente.
Gráfico 8.1: Modularidade e custo de integração
Região de
custo mínimo
Custo total do software
Custo de integração
Custo /módulo
Número de módulos
M
Legenda: O crescimento do número de módulos tende a tornar o projeto mais custoso, seja por 
causa da elaboração de mais módulos, seja pela necessidade de integrá-los todos.
Fonte: Pressman e Maxim (2016, p. 235).
A decisão sobre a quantidade de módulos sempre será influenciada também por decisões 
de projeto relacionadas a certas facilidades que se deseja conferir ao sistema. O grau de sim-
plicidade para absorver alterações e a facilidade para receber testes e manutenções futuras 
serão igualmente decisivos nessa escolha. 
Embora esse modelo nos auxilie a estabelecer parâmetros sobre quantos módulos construir, ele pouco nos diz 
sobre como construí-los. O conceito de independência funcional, explorado na sequência, lançará alguma luz 
sobre esta questão.
Independência funcional
Módulos construídos idealmente com uma só função e sem interações excessivas com outros módulos são fun-
cionalmente independentes. A busca por essa característica justifica-se pela facilidade com que se empreende o 
desenvolvimento e a manutenção do produto de software. 
Para compreender esse fato, imagine um módulo que tenha muitas dependências com outros módulos. O pla-
nejamento e a execução de testes nesse módulo seriam ações bastante trabalhosas. 
132
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
O mesmo raciocínio estende-se às ações de manutenção. Segundo Pressman e Maxim (2016), módulos inde-
pendentes são mais fáceis de serem mantidos e testados, já que possíveis consequênciasdas modificações no 
projeto serão limitadas e a propagação de erros será reduzida. Acrescente-se a esses benefícios a possibilidade 
de criação de módulos reutilizáveis, o que diminuirá o tempo de criação de programas futuros.
É possível avaliar a independência dos módulos por meio de dois critérios ligados à qualidade do processo: a 
coesão e o acoplamento. Um módulo coeso é aquele que acomoda uma função com um só propósito. Busca-se, 
portanto, módulos com alta coesão.
O acoplamento é a medida da dependência de um módulo em relação aos demais. Um módulo deve depender o 
menos possível de outro módulo, o que torna o baixo acoplamento o ideal a ser buscado pelo projetista.
A coesão que se busca durante a criação dos módulos leva o nome de coesão funcional. No entanto, alguns 
outros tipos de coesão também foram criados e colocados em uma hierarquia.
Como pior caso de coesão a ser considerado, temos a coesão coincidental. Aqui, não há nenhuma relação entre 
os elementos colocados no módulo, daí dizer que foram escolhidos por coincidência ou ao acaso.
Conforme já citado, o melhor caso de coesão é a funcional. Aqui, as operações descritas no módulo estão dispos-
tas, idealmente, em uma única frase, e ainda assim permanecem coerentes.
Entre esses dois tipos de coesão, temos a lógica, a temporal, a procedural, a de comunicação e a sequencial.
Uma visão bastante interessante e recheada de exemplos sobre acoplamento e coesão em 
módulos e funcionalidades pode ser obtida no texto disponível em <http://www.ateomo-
mento.com.br/acoplamento-e-coesao-em-modulos-e-funcionalidades/> (Acesso em: 3 
fev. 2018). Acesse também <https://www.devmedia.com.br/entendendo-coesao-e-aco-
plamento/18538> (Acesso em: 3 fev. 2018) e conheça aspectos práticos de coesão e aco-
plamento aplicados em programação orientada a objetos. 
Os conceitos e princípios de projeto não se limitam a esses que abordamos. Na literatura, é comum encontra-
mos, entre outras, menções a padrões aplicados aos projetos, refinamento gradual da solução e a aplicação de 
refatoração em projetos já prontos em parte ou no todo. Este texto, no entanto, deverá limitar-se ao estudo dos 
mais comuns e importantes deles. 
Nosso estudo segue agora com a abordagem do processo de um projeto, uma tentativa de estruturar e dar um 
método à atividade de projeto. Sigamos em frente!
http://www.ateomomento.com.br/acoplamento-e-coesao-em-modulos-e-funcionalidades/
http://www.ateomomento.com.br/acoplamento-e-coesao-em-modulos-e-funcionalidades/
https://www.devmedia.com.br/entendendo-coesao-e-acoplamento/18538
https://www.devmedia.com.br/entendendo-coesao-e-acoplamento/18538
133
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
8.2 O processo de projeto de software
Criar um projeto de software não é trabalho que se realiza em uma única etapa. O modelo final de projeto também 
não é fruto de uma única versão, sem prévio refinamento. Ao contrário, produzir um projeto é tarefa que envolve 
várias interações e a divisão do trabalho em vários subprojetos ou atividades específicas. No mesmo sentido, é 
comum que o processo de projeto acabe gerando inúmeros modelos do sistema, em níveis de abstração distintos.
A figura a seguir esclarece como um projeto segue seus passos até a composição final. Observe que as setas dia-
gonais tornam a saída de cada atividade uma especificação para o próximo estágio do processo. Não por acaso, a 
última etapa remete à especificação do algoritmo do sistema, artefato mais próximo da solução antes dela própria. 
Figura 8.4: Modelo geral do processo de projeto.
Especificação
de requisitos
Projeto de
arquitetura
Especificação
abstrata
Projeto de
interface
Projeto de
componente
Projeto de
estrutura de
dados
Projeto de
algoritmo
Arquitetura
de sistema
Especificação
de software
Especificação
de interface
Especificação
de componente
Especificação
de estrutura 
de dados
Especificação
de algoritmo
Atividades de projeto
Produtos de projeto
Legenda: As atividades próprias do processo de projeto usam as 
especificações geradas como subsídio de entrada para o próximo estágio.
Fonte: Sommerville (2010, p. 51).
Trataremos sucintamente de algumas das atividades do projeto nas próximas linhas e começaremos pelo projeto 
de dados.
8.2.1 Projeto de dados
Com base nos requisitos especificados, nesta etapa, busca-se criar um modelo de dados. Em um primeiro 
momento, esse modelo adota nível elevado de abstração para que o cliente ou usuário possa compreendê-lo. 
Depois, por meio de refinamentos sucessivos, o modelo torna-se mais adequado para a efetiva implementação 
dos dados em um programa. 
É natural imaginarmos que a arquitetura dos dados terá influência sobre o projeto de arquitetura do software.
134
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
8.2.2 Projeto de arquitetura
Esta etapa do processo funciona como uma forte ligação entre os processos de requisito e de projeto propria-
mente dito. Aqui, buscam-se o desenvolvimento e a manutenção de um framework básico em que estejam repre-
sentados os módulos do produto e as conexões entre eles.
Framework - Muitas são as definições que se aplicam ao termo framework. Em nosso contexto, 
podemos caracterizá-lo como um conjunto de símbolos, parâmetros e controles capaz de 
representar a arquitetura de um sistema. 
Glossário
Pressman e Maxim (2016) comparam o projeto de arquitetura com a planta baixa de uma casa. Ali, está disposta 
a distribuição dos cômodos e as ligações entre eles e, assim como a planta baixa nos fornece uma visão geral da 
casa, os elementos do projeto de arquitetura nos dão uma visão geral do software.
8.2.3 Projeto de interface
Ainda no contexto de comparação entre um projeto de software e um projeto de casa, o projeto da interface tem 
relação com portas, janelas e corredores de uma casa. Afinal, são esses elementos que explicitam os caminhos 
para entrar, sair e transitar pela casa.
O projeto de interfaces para software representa fluxos de informação que entram e saem de um sistema e como 
são transmitidos entre os componentes definidos como parte da arquitetura. Existem três elementos de projeto 
de interfaces: interface do usuário; interfaces externas para outros sistemas, dispositivos, redes ou outros produ-
tores ou consumidores de informação; e interfaces internas entre vários componentes do projeto (PRESSMAN; 
MAXIM, 2016).
8.2.4 Projeto de componentes
Podemos imaginar os componentes como a fiação, a localização de tomadas, interruptores, ralos, armários e 
vários outros detalhes associados a um cômodo.
No âmbito dos Sistemas de Informação, a comparação aproxima-se do conceito de uma peça de reposição.
Componente é um bloco construtivo modular para software de computador. Mais formalmente, 
a Especificação da Linguagem de Modelagem Unificada define componente como uma parte 
modular, possível de ser implantada e substituível de um sistema que encapsula implementação 
e expõe um conjunto de interfaces (PRESSMAN; MAXIM, 2016, p. 286).
135
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Por causa da variadade de aplicações e contextos em que é usado, o real significado do termo componente irá 
variar em função do ponto de vista do engenheiro que o utiliza. O que não muda é o fato de que os componentes 
situam-se no âmbito da arquitetura do software e devem comunicar-se e colaborar com outros componentes, 
quais sejam, pessoas, meios de armazenamento ou outros sistemas.
O projeto de componentes de software descreve completamente os detalhes internos de cada componente de 
software. Para tanto, o projeto no nível de componente define estruturas de dados para todos os objetos de 
dados locais e detalhes algorítmicos para todo o processamento que ocorre em um componente e uma interface 
que dá acesso a todas as operações de componentes (PRESSMAN; MAXIM, 2016).
Projeto de implantação
Implantar um software, namaioria das vezes, não significa apenas instalar o programa no servidor ou nas máqui-
nas que o executarão. É necessário também que se descreva como o sistema será alocado no que se chama de 
ambiente computacional em que ele atuará. Pode-se ter um produto, por exemplo, que deva ser configurado em 
um servidor local e alguns dos seus componentes em uma máquina remota.
Bem, era isso que tinhamos a compartilhar sobre projeto de software. Não tenha dúvida de que o assunto é vasto 
e a frequência com que as informações são atualizadas é bastante elevada. Por isso, mantenha-se antenado em 
artigos, reportagens e obras relacionadas ao tema e torne-se uma boa referência no assunto.
Boa sorte e até a próxima!
136
Considerações finais
Nesta unidade, tratamos do projeto de software, com abordagens espe-
cíficas de conceitos de projeto e processo de projeto. Em resumo, estuda-
mos os seguintes assuntos:
Conceitos fundamentais de projeto de software
Projeto é o processo pelo qual os requisitos são traduzidos em uma repre-
sentação do software. Qualquer que seja a metodologia escolhida para a 
criação do produto, o projeto será desenvolvido. O nível de detalhamento 
da solução que se aplica em um projeto deve ser suficientemente elevado 
a ponto de permitir a realização física do produto. 
Os principais fundamentos da fase de projeto incluem:
• Abstração: abstrair é concentrar-se em certos aspectos relevantes 
ao ambiente do problema. Cada passo da Engenharia de Software 
diminui o nível de abstração em direção à solução do problema. O 
nível mais baixo de abstração é o código-fonte.
• Arquitetura de software: é a estrutura ou a organização dos com-
ponentes do programa, a maneira como esses componentes inte-
ragem e a estrutura de dados que são usados pelos componentes.
• Modularidade: modularizar um software é “quebrar” seu projeto 
em partes menores, mais facilmente administráveis e de realiza-
ção mais simples. A correta modularização deve levar em conta 
o custo para desenvolver e integrar módulos pequenos. Construir 
poucos módulos, por sua vez, também poderá acarretar em difi-
culdades nos testes e na manutenção futura do sistema.
• Independência funcional: módulos construídos idealmente com 
uma só função e sem interações excessivas com outros módulos 
são funcionalmente independentes. A busca por essa caracterís-
tica justifica-se pela facilidade com que se empreende o desen-
volvimento e a manutenção do produto de software. 
137
O processo de projeto de software
Criar um projeto de software não é trabalho que se realiza em uma única 
etapa. Ao contrário, produzir um projeto é tarefa que envolve várias inte-
rações e a divisão do trabalho em vários subprojetos ou atividades espe-
cíficas. O processo de um projeto inclui as seguintes etapas:
• Projeto de dados: com base nos requisitos especificados, nesta 
etapa, busca-se criar um modelo de dados. De um nível elevado 
de abstração no início, o projeto tende a receber refinamentos 
sucessivos para chegar a uma forma próxima à implementação. 
• Projeto de arquitetura: aqui, buscam-se o desenvolvimento e a 
manutenção de um framework básico em que sejam representa-
dos os módulos do produto e as conexões entre eles.
• Projeto de interface: representa os fluxos de informação que 
entram e saem de um sistema e como são transmitidos entre os 
componentes definidos como parte da arquitetura.
• Projeto de componentes: descreve completamente os detalhes 
internos de cada componente de software.
• Projeto de implantação: trata-se da descrição de como o sistema 
será alocado no que se chama de ambiente computacional em 
que ele atuará.
Referências bibliográficas
138
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh, 2016.
SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: A. Wesley 
publishing company, 2010.
	Unidade 1
	Sistemas de Informação – Conceitos Iniciais 
	Unidade 2
	Tipos de Sistemas de Informação 
	Unidade 3
	Sistemas de Informação em Negócios 
	Unidade 4
	Desenvolvimento de Sistemas
	Unidade 5
	Engenharia de Software 
	Unidade 6
	Engenharia de Requisitos
	Unidade 7
	Manutenção e Reengenharia 
	Unidade 8
	Conceitos de Projeto
	_GoBack
	_GoBack
	_GoBack
	_GoBack
	__DdeLink__1441_743834162
	_Hlk505856755
	_Hlk505856893