Fundamentos SI - Conceitos Iniciais

Fundamentos
de Sistemas de
Informação
Fundamentos
de Sistemas de
Informação
1ª edição
2017
Presidente do Grupo Splice Antônio Roberto Beldi
Reitor João Paulo Barros Beldi
Diretor Administrativo Financeiro Claudio Geraldo Amorim de Souza
Diretora da Educação a Distância Jucimara Roesler
Gestor do Instituto de Ciências Sociais Aplicadas Henry Julio Kupty
Gestora do Instituto da Área da Saúde Marcela Unes Pereira Renno
Gestora do Instituto de Ciências Exatas Regiane Burger
Autoria Ana Araújo Stelle
Elaine Santos
Roque Maitino Neto
Parecerista Validador 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.
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
4
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á?!
5
Unidade 1
Sistemas de Informação –
Conceitos Iniciais
1
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.
6
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.
Glossário
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.
7
A figura a seguir representa os componentes de um sistema de forma genérica.
Figura 1.1 – Componentes de um sistema.
OBJETIVOS
Entradas Saídas
Processos de
Transformação
Controle e
avaliação
RETROALIMENTAÇÃO
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 Informação
Processamento
(Entrada) (Saída)
Legenda: Diagrama do processamento de dados por um sistema de informação.

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.
8
Segundo Resende e Abreu (2014), em geral, os sistemas procuram atuar como:

• instrumentos que 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.
9
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.
10
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).
Glossário
: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.
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.
11
Figura 1.4 – Representação gráfica de um Sistema de Informação.
or
ga
Usuários
as
Procedimentos
niz
sso
aç
pe
õe
Sistemas de
s
Informações
tecnologia
Hardware
Software
Bancos de dados
Comunicações
Legenda: Inter-relacionamentos existentes entre o Sistema de Informações e demais áreas.

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.
12
Glossário
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.
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 centrais de 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.
Equipamentos de comunicação
Equipamentos de processamento
Unidade de Unidade
controle aritmética/lógica
Dispositivos Dispositivos
de entrada Área de armazenagem de registro de saída
Memória (Armazenamento primário)
Armazenamento secundário
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.
13
• Á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.
14
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.
15
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 é um conjunto interligado de computadores que propicia o compartilhamento de

recursos e a melhoria do 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.

16
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.
17
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.
18
Referências bibliográficas
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.
19
Unidade 2
Tipos de Sistemas de
Informação
2
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!
21
• 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.
22
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, foquemos nos 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.
23
• 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 é alta, o desejo de buscar e man-

ter vantagem competitiva para dissuadir novos concorrentes é, 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
24
(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.
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).
25
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) é 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 agrupados das 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.
26
Glossário
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.
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.
Sistemas de
apoio à decisão
Extranet
corporativa
Funcionários
Intranet
corporativa
Bancos de
dados Bancos de
internos dados
corporativos externos
Sistemas de
apoio à
decisão
Cadeia de
fornecimento e Sistemas Sistemas de
Banco de Sistemas de
transações ERP e TPSs Banco de apoio às
dados com informação dados de
empresariais transações informações
aplicativos
válidas executivas
Sistemas de
informações
Inserção e especializadas
Relatórios detalhados
listas de erros
Banco de Relatórios de exceções
dados
operacional
Relatórios sollicitados
Relatórios sobre os
indicadores-chave
Relatórios agendados
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.
27 Fonte: Stair e Reynolds (2015, p. 444).
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:
28
• 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 à 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?
Glossário
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.
• 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.
29
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.
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.
30
Com base em regras “e se” para gerar cenários, o SAD é 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
31
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.
SAD e SIG
Gerencial
SAD e SIG - Gerencial
SPT - Operacional
SA - Automação
Legenda: Cada nível possui uma função importante e sua atuação está devidamente definida.
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.
32
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 para o sucesso do investimento. E nunca é demais lembrar: esse gestor é você!
33
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) é 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.
34
• 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.
35
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.
36
Unidade 3
Sistemas de Informação em
Negócios
3
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á!
• 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
38
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.
Glossário
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.
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.
39
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 Faz o uso de sistemas de comunicação por satélite,
medicamentos e desenvolvidos para conectarem as lojas locais com
conveniência 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.
40
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.
41
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.

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.
42
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:
43
Quadro 3. 2 - Comparativo de OLPT e OLAP.
OLTP OLAP
Foco Nível operacional da organização, Nível estratégico da organização,
objetiva a execução operacional objetiva a tomada de decisão e a
do negócio. análise empresarial.
Armazenamento O armazenamento é feito em É feito em estruturas do DW com

modelo relacional normalizado, otimização no desempenho de
otimizado para a utilização grandes volumes de dados. Os
transacional, sendo que os dados dados possuem altos níveis de
possuem altos níveis de detalhes. 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 São permitidas leitura, inserção, É permitido apenas inserir e ler
dados modificação e exclusão de dados. 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.
44
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).
45
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.
46
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.

47
• 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 Dezenas ou centenas Dezenas de dólares.
dólares. de dólares.
Duração do Dias para meses. Dias para semanas. Horas para dias.
processo de vendas.
Número de Diversas pessoas, até uma Uma ou duas. Uma ou duas.
tomadores de dúzia ou mais.
decisão envolvidos.
Uniformidade da Tipicamente uma oferta Oferta de produto Oferta de produto
oferta. uniforme de produto. mais customizado. simples, um de cada
tipo.
Complexidade Extremamente complexo, Relativamente Relativamente simples,
do processo de muito espaço para simples, discussão discussão limitada
compra. negociação sobre preço limitada sobre as sobre as opções de
pagamento, entrega, opções de preços, pagamento, entrega
quantidade, qualidade pagamento e e negociação de alto
opções e características. entrega. preço.
Motivação para a Acionado por uma decisão Acionado por Acionado por
venda. ou necessidade de uma necessidade uma necessidade
negócio. ou emoção do ou emoção do
consumidor consumidor individual.
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.
48
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.
49
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.

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.
50
• 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.

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á?
51
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.
52
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.

53
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ônico e 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.
54
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.
55
• 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.
56
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.
57
Unidade 4
Desenvolvimento de Sistemas

4
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!
• O aluno será capaz de compreender conceitos principais, profis-

sionais envolvidos, carreiras em Sistemas de Informação, ciclo de
vida do software.
59
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.
Glossário
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 é, a aplicação de engenharia ao
software. (2) O estudo de abordagens como definido em (1) (PRESSMAN; MAXIM, 2016).
Iniciamos nossa abordagem pela caracterização de processo. Pressman e Maxim (2016) ensinam que processo
é 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.
60
Figura 4.1 - Processo de montagem de um automóvel.
Legenda: Imagem com ilustração de uma linha de produção de automóveis.

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 conhecidos incluem:
• 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.
61
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
62
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/>
63
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á demonstrar o 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ê.
64
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-
65
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 acha o 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.
66
É 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.
67
Figura 4.2 - Representação das fases do modelo em cascata.
Requisitos
Projeto
Implementação
Testes
Manutenção
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.
68
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 detectados na 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.
69
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!
70
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
71
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.
72
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.
73
Unidade 5
Engenharia de Software

5
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!
• 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.
75
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 falta de 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?
76
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.
77
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.

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.
78
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.
Glossário
Firmware: Conjunto de regras operacionais programadas diretamente no hardware de um

equipamento eletrônico.
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.
79
Figura 5.2 – Software para Linhas de Produtos.
Legenda: A figura mostra alguns exemplos de software para linhas de produtos.

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 conhecimento de 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.
80
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.
81
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.
Projeto e
Especificação Validação Evolução
implementação
de software de software de software
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
82
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.
83
Figura 5.6 – Modelo de Desenvolvimento Incremental.
Atividade simultânea
Especificação Versão inicial
Descrição Versões
Desenvolvimento intermediárias
do esboço
Validação Versão final
Legenda: Modelo em cascata de processo de desenvolvimento de software.

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 Análise de Alterações no Projeto de sistema

de requisitos componentes requisitos com reuso
Desenvolvimento Validação
e integração e sistema
Legenda: Modelo desenvolvimento de software orientado a reuso.

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.
84
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:
85
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.

86
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 que
foram 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.
87
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!
88
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.
89
Unidade 6
Engenharia de Requisitos

6
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!
91
• 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.
92
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ções de 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.
93
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.
94
Figura 6.1- Tipos de requisitos não funcionais.
Requisitos
não funcionais
Requisitos Requisitos Requisitos

de produto organizacionais externos
Requisitos Requisitos de Requisitos de Requisitos de Requisitos

de eficiência confiabilidade ]portabilidade interoperabilidade éticos
Requisitos de Requisitos Requisitos de Requisitos Requisitos

facilidade de uso de entrega implementação de padrões legais
Requisitos de Requisitos Requisitos de Requisitos de

desempenho de espaço privacidade egurança
Legenda: Os requisitos não funcionais desdobram-se em muitas

classificações, mas não fazem parte diretamente das funcionalidades do sistema.
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?
95
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.
96
Figura 6.2 – Processo de Engenharia de Requisitos.
Elicitação e
Estudo de análise de
viabilidade equisitos
Especificações
de requisitos
Relatório de Validação
viabilidade 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.
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.
97
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.
Glossário
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.
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 está 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.
98
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.
99
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 requisitos de 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.
100
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.
101
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.
102
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 resolver
algum 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-
103
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.
104
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.
105
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.
106
Unidade 7
Manutenção e Reengenharia

7
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!
• Conhecer sobre manutenção de software e suporte.

• Conceituar reengenharia de software e engenharia reversa.
• Entender os aspectos econômicos da reengenharia.
108
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 A manutenção evolutiva é indicada quando os requisitos de sistema são
(ou perfectiva) 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 A manutenção preventiva objetiva melhorar a estrutura de um software,
(reengenharia) 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).
109
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.
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
110
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.
111
Gráfico 7.1 – Distribuição do Esforço de Manutenção.
Correção de
defeitos
(17%)
Adaptação Adição ou
de ambiente modificação de
(18%) 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 Planejar a Modificar Revisar e

Modificar
documentação abordagem de o código efetuar testes
o projeto
existente manutenção
Legenda: Figura que descreve a sequência das etapas de manutenção.

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.
112
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 precisam ser 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.
113
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.
114
Figura 7.4 – Previsão de Manutenção.
Quais partes do sistema serão

mais caras para serem
mantidas?
Previsão de
manutenção
Quais partes do sistema são mais Qual será o custo de manu-

suscetíveis de serem afetadas por tenção durante o tempo de
solicitações de mudança? Previsão de vida desse sistema?
Previsão de custos
mudanças de de manutenção
sistema
Quais serão os custos de
Quantas solicitações de
manutenção desse sistema
mudança podem ser esperadas?
durante o próximo ano?
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.
115
Glossário
Inteligibilidade: Característica que se espera de um software; está relacionada à qualidade de

ser inteligível, ou seja, de ser compreendido.
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 desenvolver novamente 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.
116
Figura 7.5 – Processo de Reengenharia
Programa Documentação Programa Dados

original do programa reconstruído originais
Engenharia
reversa
Reengenharia
Tradução Modularização de dados
de código-fonte do programa
Melhoria de
estrutura de
programa
Programa Dados
reestruturado 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á
117
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.
Reestruturação de programa Reestruturação de

automatizada programa e dados
Conversão de código-fonte Reestruturação automatizada Reestruturação mais

automatizada com mudanças manuais mudanças de arquitetura
Aumento de custo
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:
118
Figura 7.7 – Parâmetros do Custo de Reengenharia.
Custo anual de manutenção da aplicação.

P1
Custo anual de operação da aplicação.

P2
Valor comercial anual da aplicação.

P3
Previsão do custo anual de manutenção após reengenharia.

P4
Previsão do custo anual de operação após reengenharia.

P5
Valor comercial anual após reengenharia.

P6
Custo estimado para reengenharia.

P7
Previsão de tempo para realizar reengenharia (em anos).

P8
Fator de risco da reengenharia (fator multiplicador;
por exemplo, 1,25 indicará que os custos com reengenharia
P9 podem crescer em 25%).
Expectativa de vida do sistema (em anos).

L
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:
CMC  P3 – ( P1 + P 2 )  ⋅ L
=
E o custo da reengenharia é:
CR  P 6 – ( P 4 + P5 ) ⋅ ( L – P8 ) – ( P 7 ⋅ P9 ) 
=
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.
119
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.
120
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.
121
Unidade 8
Conceitos de Projeto

8
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.
123
O aluno será capaz de compreender sobre conceitos de projeto e modelo

do projeto (dados, arquitetura, interface, componentes e implantação).
124
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?
125
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
126
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 é 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.
127
Figura 8.1: Arquitetura de um sistema de tráfego aéreo.
Sistema Sistema de Sistema de Sistema de Sistema

de radar transponder comunicação comunicação telefônico
de dados da aeronave
Processador Back-up do Processador Back-up do

de posição processador de processador de
de posição comunicação comunicação
Sistema de Banco de dados

simulação da de planos de
aeronave
Sistema de
mapa de clima
Sistema de Consoles do
Sistema de informações controlador
relatórios do controlador
Sistema de registro
de atividades
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.
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 é
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:
128
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 Software
cliente cliente
Software Software
cliente cliente
Armazenamento
de dados (repositório Software
Software ou “quadro-negro”)
cliente
cliente
Software Software
cliente cliente
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 é 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.
129
Figura 8.3: Arquitetura de chamadas e retornos.
Programa principal
Subprograma Subprograma Subprograma

controlador controlador controlador
Subprograma Subprograma Subprograma Subprograma Subprograma

de aplicação de aplicação de aplicação de aplicação de aplicação
Subprograma Subprograma
de aplicação de aplicação
Legenda: O estilo de chamadas e retornos permite a visualização

da hierarquia entre os subprogramas que compõem o produto.
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).
130
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
Custo total do software
Custo de integração
Região de
custo mínimo
M
Custo /módulo
Número de módulos
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.
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.
131
O mesmo raciocínio estende-se às ações de manutenção. Segundo Pressman e Maxim (2016), módulos inde-
pendentes são mais fáceis de serem mantidos e testados, já que possíveis consequências das modificações no
projeto serão limitadas e a propagaçã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!
132
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
Atividades de projeto
Projeto de Especificação Projeto de Projeto de Projeto de Projeto de

arquitetura abstrata interface componente estrutura de algoritmo
dados
Especificação
Arquitetura Especificação Especificação Especificação Especificação
de estrutura
de sistema de software de interface de componente de algoritmo
de dados
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.
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.
133
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.
Glossário
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.
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
sã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 vá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 é um bloco construtivo modular para software de computador. Mais formalmente,
a Especificação da Linguagem de Modelagem Unificada define componente como uma parte
modular, possível de ser implantada e substituível de um sistema que encapsula implementação
e expõe um conjunto de interfaces (PRESSMAN; MAXIM, 2016, p. 286).
134
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 algorítmicos para todo o processamento que ocorre em um componente e uma interface
que dá acesso a todas as operações de componentes (PRESSMAN; MAXIM, 2016).
Projeto de implantação
Implantar um software, na maioria 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!
135
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: é 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.
136
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 informação que
entram e saem de um sistema e como sã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á.
137
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.
138

Fundamentos SI - Conceitos Iniciais

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Fundamentos SI - Conceitos Iniciais

Caricato da

Copyright:

Formati disponibili

Fundamentos

Você já parou para pensar em quantos Sistemas de Informação usou hoje?

• Compreender o conceito básico de Sistemas de Informação.

1.1 Conhecendo os Sistemas

A figura a seguir representa os componentes de um sistema de forma genérica.

Figura 1.1 – Componentes de um sistema.

Legenda: Demonstração do fluxo de um sistema.

1.2 Sistemas de Informação

Figura 1.2 – O Processamento de Dados.

Legenda: Diagrama do processamento de dados por um sistema de informação.

Segundo Resende e Abreu (2014), em geral, os sistemas procuram atuar como:

1.2.1 Dado, Informação e Conhecimento

Figura 1.3 – Convite para evento.

Legenda: Exemplo de convite para evento contendo informações básicas.

Quadro 1.1 – Características da informação.

O dado é o fato bruto, a informação é o dado dotado de relevância e propósito e o conheci-

Entendidos esses conceitos de dado, informação e conhecimento, percebemos a importância e as relações de

1.2.2 Dimensões dos Sistemas de Informação

2. Dimensão Organizacional: relaciona-se com processos (modelagem de negócio) e abordagens de gestão

1.3 Tecnologia da informação

Figura 1.4 – Representação gráfica de um Sistema de Informação.

Legenda: Inter-relacionamentos existentes entre o Sistema de Informações e demais áreas.

Os componentes de hardware de um sistema de computação incluem diferentes dispositivos de entrada e de

Figura 1.5 – Componentes de um hardware.

Memória (Armazenamento primário)

Legenda: Figura com esquema de funcionamento de um hardware.

Conheça a linha do tempo dos sistemas operacionais acessando <https://www.tecmundo.

1.3.3 Banco de dados

Os Sistemas de Informação, especialmente os desenvolvidos para o uso empresarial, dependem de estruturas de

1.3.4 Rede de Computadores

Uma rede de computadores é um conjunto interligado de computadores que propicia o compartilhamento de

Figura 1.6 - Rede de computadores.

Legenda: Representação de rede de computadores.

REZENDE, D. A. Planejamento de sistemas de informação e informá-

STAIR, R. M. Princípios de sistemas de informação. São Paulo: Cengage

• Discutir a relação entre vantagem competitiva e a escolha ade-

2.1 Processos de negócios e vantagem competitiva

Quando a ameaça de novos participantes no mercado é alta, o desejo de buscar e man-

Figura 2.1: Coleta de Dados para melhor Decisão Corporativa.

2.2 Sistemas de Informação Gerencial

Figura 2.2: Fontes das informações gerenciais.

Legenda: São diversas as fontes de informações em uma organização onde cada

2.3 Sistemas de Apoio à Decisão

• determinação do local mais adequado para instalação de um ponto de venda;

• flexível: oferece relatórios completos em formato gráfico e textual.

Figura 2.3 – Tomada de decisão.

Legenda: As decisões tomadas por uma organização devem levar em consideração as

Na lição de Resende e Abreu (2014), um SAD é geralmente composto pelo:

2.4 Sistemas de Informação Executiva

Figura 2.4 – Pirâmide de Sistemas de Informação em cada nível administrativo.

SAD e SIG - Gerencial

STAIR, R. M.; REYNOLDS, G. W. Princípios de Sistemas de Informação:

Você está iniciando o estudo da terceira unidade da disciplina Fundamen-

• Compreender sobre os sistemas de informação e as suas vanta-

3.1 A Informação e os Sistemas

3.2 Vantagem Competitiva

Quadro 3.1 – Exemplos de vantagem competitiva nas empresas.

Empresa Comercial O uso competitivo de sistemas de informação

3.3 Business Intelligence

As organizações tipicamente coletam informações com a finalidade de analisarem o ambiente empresarial,

Assista a um vídeo de 60 segundos que mostra uma ferramenta de BI em ação: <https://

3.3.1 Data Warehouse

Figura 3.1: Sistema data warehouse.