Académique Documents
Professionnel Documents
Culture Documents
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
Objetivos de Aprendizagem
6
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
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
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
OBJETIVOS
Entradas Saídas
Processos de
Transformação
Controle e
avaliação
RETROALIMENTAÇÃO
Dados Informação
Processamento
(Entrada) (Saída)
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
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
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:
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
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
A informação pode ser definida como um conjunto de dados organizados e processados de forma que tenham
valor. Possibilita resolver problemas e também ajuda nas tomadas de decisões. De um modo geral, podemos dizer
que a informação é um conjunto de dados moldados e dotados de relevância e propósito e útil para as pessoas.
A informação apresenta as seguintes características:
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.
10
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
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.
11
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
or
ga
Usuários
as
Procedimentos
niz
sso
aç
pe
õe
Sistemas de
s
Informações
tecnologia
Hardware
Software
Bancos de dados
Comunicações
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
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
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.
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
Armazenamento secundário
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
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
• Área de armazenagem de registro: um registrador é uma área usada para armazenamento temporário de
instruções de programas e dados – antes, durante e depois da execução por parte da CPU.
• Unidade de controle: a unidade de controle é uma área que acessa instruções do programa, decodifi-
cando-as e coordenando o fluxo de entrada/saída de uma ALU e dos registradores.
• Armazenamento primário: refere-se ao tipo de armazenamento de dados que a CPU pode acessar dire-
tamente. O armazenamento primário pode ser:
»» Memória de acesso aleatório (RAM – Random Access Memory): tipo de memória que armazena dados
temporariamente. Esse é um tipo de memória volátil, ou seja, se o dispositivo for desligado, perdem-se
as informações.
»» Memória somente de leitura (ROM – Read Only Memory): não é volátil, ou seja, seus dados persistem
mesmo se o computador for desligado. A ROM armazena dados permanentemente.
»» Memória cache: é um tipo de memória de alta velocidade que um processador pode acessar de forma
mais rápida em comparação ao acesso à memória principal.
• Armazenamento secundário: armazenar dados é fundamental para manter bons sistemas em perfeito
funcionamento. Para a maior parte das organizações, a melhor solução para armazenar grande quanti-
dade de dados são as opções de armazenagem secundária, que podem ser disco rígido externo, unidade
USB (pen drive, cartucho de fita etc.). Esses dispositivos secundários podem guardar cópias de dados e
somente pessoas autorizadas podem ter acesso às informações contidas nesses dispositivos de armaze-
namento secundário.
• Dispositivos de entrada: são periféricos, como mouse, teclado, dispositivos touch screen, canetas de luz,
leitores ópticos, scanners, entre outros que enviam informações para “dentro” do computador.
• Dispositivos de saída: podem ser monitores, telas, impressoras, entre outros dispositivos/periféricos que
transmitem/imprimem informações para o usuário.
1.3.2 Software
Uma vez que os Sistemas de Informação passam a ser computadorizados, é necessário que a lógica de processos,
atividades ou rotinas sejam representada e executada. Esses comandos lógicos são organizados na forma de
programas de computador.
Segundo Resende e Abreu (2014), o software é uma sequência de instruções escritas para serem interpretadas
por um computador com o objetivo de executar tarefas específicas.
Sem o software, o hardware seria inerte. Na verdade, toda inteligência no funcionamento dos computadores está rela-
cionada a algum tipo de software. Este não é tangível e somente pode ser evidenciado pelas suas funcionalidades.
Stair (2015) classifica software em software de sistema e software de aplicação.
O software de sistema é uma categoria que compreende os softwares que operam tarefas fundamentais para o
funcionamento do hardware. Nessa categoria, há sistemas operacionais, utilitários e ferramentas de desenvolvi-
mento de software.
Um sistema operacional é um software cujo objetivo é dispor para os usuários uma forma de utilização do har-
dware, que permite gerenciar o funcionamento do sistema do computador.
14
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
Em resumo, podemos dizer que um sistema operacional é uma máquina virtual que permite acessar recursos de
hardware sem que seja necessário possuir o conhecimento detalhado de como os dispositivos funcionam.
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.
15
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
Um registro trata-se de uma coleção de campos de dados que estão relacionados entre si. Já um arquivo é uma
coleção de registros que podem relacionar-se entre si.
Os dados são recursos valiosos que uma organização possui. Ao preparar e manter um banco de dados, uma
empresa deve levar em consideração o seu conteúdo e a sua estrutura. Assim, um banco de dados bem geren-
ciado e bem projetado é uma ferramenta altamente valiosa para auxiliar a tomada de decisões.
16
Fundamentos de Sistemas de Informação | Unidade 1 - Sistemas de Informação – Conceitos Iniciais
A rede de computadores poder ser classificada em três categorias de acordo com sua abrangência: LAN, MAN e
WAN.
• Redes LAN (Local Area Network): são redes locais em que conectam computadores e dispositivos den-
tro de um mesmo ambiente, podendo atingir desde uma sala até um prédio ou um campus universitário.
• Redes MAN (Metropolitan Area Network): são redes metropolitanas com abrangência superior àquelas
possuídas pelas LANs. Por meio dessa estrutura de dados, conseguimos interconectar, por exemplo, filiais
de uma empresa em municípios distantes que compartilham essa estrutura para as suas atividades. Atra-
vés dela, podem trafegar voz e dados usando as linhas de transmissão de voz ou fibras ópticas disponíveis.
• Redes WAN (Wide Area Network): são redes de abrangência superior às MANs. São geograficamente
distribuídas e podem conectar países e continentes. Podem usar as estruturas de satélites ou mesmo de
cabos submarinos.
A partir do que vimos neste tópico, podemos notar que sem as redes de computador fica muito mais difícil a cir-
culação da informação em uma organização, já que elas reúnem os computadores, distribuindo as informações
e os recursos para todos de forma rápida e segura.
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
19
Unidade 2
Tipos de Sistemas de
Informação
2
Para iniciar seus estudos
Caro aluno, aqui estamos em mais uma unidade do nosso curso. Depois
de tomar contato com conceitos básicos relacionados aos Sistemas de
Informação, chegou a hora de você conhecer alguns dos seus tipos. Não
se trata, no entanto, de passarmos por todo o conteúdo da unidade clas-
sificando à exaustão todos os tipos e subtipos de sistemas. Ao invés disso,
discutiremos as principais características das ferramentas que o gestor de
uma empresa, por meio da sua indicação e orientação, poderá dispor para
gerenciar processos de modo assertivo.
Iniciaremos nossos estudos abordando os processos de negócios e situ-
ando-os como peças fundamentais na construção de um Sistema de
Informação. Discutimos também nesta fase inicial questões relativas à
vantagem competitiva e sua relação com a correta escolha de um SI. Na
sequência, as principais características de tipos de ferramentas de gestão
são exploradas de modo a habilitar você a escolher a mais adequada para
o caso real.
Leia com atenção todo conteúdo do e-book, aproveite bem suas indica-
ções de leitura e esmere-se na resolução dos exercícios. Assim, logo você
se tornará referência na disciplina. Sigamos adiante!
21
Objetivos de Aprendizagem
22
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
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
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
• Ameaça de novos concorrentes: a situação ideal para o surgimento de novos concorrentes dá-se em
setores cuja atividade apresenta custos baixos e para a qual a tecnologia é simples e amplamente dis-
ponível. Um pequeno bar pode ser o exemplo ideal para ilustrar essa situação: o início do negócio não
demanda grande investimento financeiro e os equipamentos e processos para condução do negócio são
disponíveis e conhecidos.
• 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
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
(ferramenta que automatiza processos de cotações entre fornecedores) poderia ajudar na busca pelas melhores
condições de compra.
Legenda: A coleta de dados é realizada em diversas bases de dados para análise e utilização, como na tomada de decisões.
Fonte: Plataforma Deduca (2018).
Bem, você já deve estar curioso para conhecer esses sistemas, não é? Agora, o texto segue com a descrição dos
principais Sistemas de Informação e, ao conhecê-los, esperamos que você adquira habilidade para decidir pela
ferramenta correta para o tipo de problema que se apresentará em sua vida profissional.
25
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Herbert Simon, economista americano agraciado com o prêmio Turing, em 1975, criou um modelo de três estágios
que expressa um processo típico de tomada de decisão. Os três estágios incluem informação, projeto e escolha.
Renomeado mais tarde para estágio da inteligência, essa primeira etapa do processo inclui a identificação de
potenciais problemas e oportunidades que advêm daquela decisão.
No estágio de projeto, o tomador da decisão pensa em soluções alternativas para o problema e pondera a viabili-
dade delas. Por fim, é no estágio da escolha que, de fato, a ação é definida. Seria tudo muito simples se a natureza
dos problemas não variasse tanto.
Stair e Reynolds (2015) concebem um Sistema de Informação Gerencial (SIG) como um organismo que não se
restringe apenas ao elemento tecnológico e que é decisivo na obtenção de vantagem competitiva.
Um sistema de informação gerencial (MIS, Management Information System) é um conjunto integrado
de pessoas, procedimentos, bancos de dados e dispositivos que fornece aos gestores e aos tomado-
res de decisão informações que ajudam a alcançar os objetivos organizacionais. Os MISs sempre dão
às empresas e a outras organizações uma vantagem competitiva, fornecendo as informações certas
para as pessoas certas em formato e tempo certos (STAIR; REYNOLDS, 2015, p. 443).
Como o próprio nome sugere, um SIG deve atender às necessidades dos gerentes (ou gestores) ao fornecer-lhes
informações atualizadas das operações regulares da organização.
Resende e Abreu (2014) sustentam que os SIGs operam com dados 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
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
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:
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
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.
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
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
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.
29
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
30
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Com base em regras “e se” para gerar cenários, o SAD é constituído por um conjunto de modelos
de gestão capaz de lidar com os dados da empresa por meio de simulações, cálculos, insights,
resolução de problemas matemáticos, entre outros cenários (RESENDE; ABREU, 2014, p. 191).
Apesar de existirem outras, a distinção mais clara entre um sistema gerencial e um de apoio à decisão é a pos-
sibilidade de o segundo oferecer simulações e construções de cenários. O que estudaremos na sequência serão
os Sistemas de Informação Executiva, mais comumente conhecidos pela sua sigla da língua inglesa. Avancemos!
31
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
do EIS. Imagine a situação em que o executivo, ao consultar seu EIS para a tomada de uma decisão importante,
descobre que os dados que o alimentam ainda não foram atualizados. Situação perigosa, para dizer o mínimo. A
mesma recomendação feita para o primeiro modo vale para o segundo.
Por fim, a terceira e mais indicada maneira é a de não criar base própria para o EIS, seja por digitação ou por
exportação de dados. Ao invés disso, os responsáveis pelo desenvolvimento e pela implementação do sistema
deverão criar um mecanismo para que os dados sejam buscados em uma base comum a todos os sistemas e
sejam processados e disponibilizados pelo EIS no formato conveniente.
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.
Fonte: Elaborada pelo autor (2018).
Aí está colocada a síntese do que precisamos saber para decidirmos pela adoção ou não de um Sistema de Infor-
mação Executiva. É natural que muitas variáveis devam ser consideradas e ponderadas na decisão, incluindo o
desejo do executivo. No entanto, sem esse conhecimento básico, não poderíamos sequer sugerir a adoção de um
Sistema de Informação desse tipo.
E por falar em tipos de SI, é necessário mencionar a existência de muitas (muitas mesmo) outras modalidades de
sistema. Utilizando critérios de uso em certos níveis organizacionais, em áreas funcionais e a aptidão em suportar
certos tipos de decisão, os SIs receberam numerosas classificações. Como temos mencionado, não é objetivo
desta unidade descrevê-las todas.
É necessário registrar, contudo, que sistemas de comércio eletrônico, de planejamento de recursos empresariais,
de relacionamento com clientes e de gestão do conhecimento, entre outros, compõem a miríade de recursos dos
quais dispõem as organizações para ajudá-las a gerir seu negócio e para dar suporte ao tomador de decisão com
informação de qualidade.
32
Fundamentos de Sistemas de Informação | Unidade 2 - Tipos de Sistemas de Informação
Embora a variedade de ferramentas seja importante no contexto, é a habilidade do gestor do sistema (entendido
em sentido amplo, pois gerir um sistema pode incluir desde ações de desenvolvimento até manutenção diária)
que será decisiva para o sucesso do investimento. E nunca é demais lembrar: esse gestor é você!
33
Considerações finais
Nesta unidade, foram abordados os Sistemas de Informação Gerencial,
Sistemas de Apoio à Decisão e os Sistemas de Informação Executiva, além
de aspectos relacionados a processos de negócios e vantagem competi-
tiva. Em resumo, você teve contato com os seguintes temas:
• Processos de negócios e vantagem competitiva: processo é
um conjunto de tarefas logicamente relacionadas realizadas para
alcançar um resultado definido. Em um ambiente empresarial, há
vários exemplos de processos de negócio: contabilidade, marke-
ting e recursos humanos são alguns deles. A diversidade de sis-
temas de informação deve suprir as necessidades específicas de
cada um deles.
As organizações usam os sistemas de informação para a obtenção
de vantagem competitiva. Alguns fatores explicam a necessidade
de obter-se tais vantagens: rivalidade entre os concorrentes que
já existem, ameaça de novos concorrentes, ameaça de produtos
e serviços substitutos, poder de barganha dos consumidores e
poder de barganha dos fornecedores.
• Sistemas de Informação Gerencial: um sistema de informação
gerencial (MIS, Management Information System) é um conjunto
integrado de pessoas, procedimentos, bancos de dados e disposi-
tivos que fornece aos gestores e aos tomadores de decisão infor-
mações que ajudam a alcançar os objetivos organizacionais. Os
dados de entrada podem originar-se de fontes internas e exter-
nas e as informações geradas servem como base decisória para
gerentes de todas as áreas funcionais da organização.
• Sistemas de Apoio à Decisão: a categoria de sistemas chamados
e entendidos como Sistemas de Apoio à Decisão (SAD) apresenta
algumas peculiaridades que a diferenciam dos outros sistemas.
Uma dessas características próprias é a possibilidades de esta-
belecer cenários e simulações de situações que poderiam ocorrer
em determinada circunstância da atividade da empresa. Algumas
particularidades caracterizam um SAD: acesso rápido às informa-
ções, operação com grandes volumes de dados de diferentes fon-
tes, flexibilidade e complexidade funcional.
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
Referências bibliográficas
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.
36
Unidade 3
Sistemas de Informação em
Negócios
3
Para iniciar seus estudos
Objetivos de Aprendizagem
38
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
Para pensarmos sobre essa função, podemos lançar perguntas como: os investimentos são aplicados de forma
certa? Os profissionais desenvolvem os programas certos? Os recursos são atuais?
O quadro a seguir, retirado do livro “Princípios de sistemas de informação” (STAIR; REYNOLDS, 2016), demonstra
como algumas empresas fazem uso da tecnologia para alcançarem vantagem competitiva.
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.
40
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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.
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
Em razão do grande número de possibilidades de análise, os usuários podem ficar um pouco confusos com os
dados contidos em um data warehouse. Nesse contexto, é necessária uma ferramenta que auxilie na análise dos
dados, e essa ferramenta é o data mining.
Veja agora as principais questões relacionadas a um data warehouse:
• Principal função: dispor informações para gerar novos conhecimentos que a empresa possa usar de
forma estratégica.
• O que se espera encontrar: informações sobre empresa e concorrentes.
• Tecnologias associadas a um data warehouse: Data Mining, OLAP (processo analítico), Banco de Dados
Multidimensional (MDD), OLTP (Processos de transações on-line), Data Mart, Repositório de Dados Ope-
racional (ODS).
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.
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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.
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.
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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.
45
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
A robótica é a área na qual as máquinas realizam tarefas complexas e rotineiras, por exemplo, a soldagem de
carros como parte das atividades de uma montadora de veículos. Já os sistemas de visão permitem que robôs e
outros equipamentos vejam, armazenem e processem imagens virtuais. O processamento de linguagem neural
envolve computadores capazes de entender e agir com comandos verbais ou escritos (seja inglês, português,
espanhol ou outros idiomas). Os sistemas de aprendizagem, por sua vez, possibilitam que os computadores
aprendam a partir de erros ou experiências passadas; exemplos: jogar games, tomar decisões empresariais. A
rede neural é um ramo da IA que permite que computadores reconheçam e atuem de acordo com tendências e
padrões. Algumas empresas usam as redes neurais para destacarem as tendências e otimizarem o retorno sobre
os seus investimentos.
Sistemas especialistas: fornecem ao computador capacidade de sugerir e atuar como alguém especiali-
zado em algum campo. O valor desses tipos de sistemas é permitirem às organizações capturarem e usa-
rem a sabedoria de especialistas/experts. Assim, anos de experiência e conhecimentos não são perdidos
quando um especialista vai a óbito ou transfere-se da empresa. A coleta de dados, os procedimentos e as
regras devem ser seguidos para a obtenção do resultado esperado. Esses dados coletados ficam contidos
na base de conhecimento do sistema especialista. Uma base de conhecimento é um conjunto de regras,
dados, procedimentos e relações que deve ser seguido para alcançar o valor esperado.
Para entender melhor o conceito de um sistema especialista, vamos imaginar um diagnóstico médico. Tal tarefa
exige conhecimento específico, dessa forma, são necessárias pessoas capacitadas para realizarem o diagnóstico
médico, ou seja, pessoas especialistas. Para que essas atividades sejam realizadas por outras pessoas que não
detêm tal conhecimento, é preciso que exista os sistemas especialistas. Esses sistemas têm o objetivo de substi-
tuir o homem na solução de problemas específicos, usando para isso o conceito de inteligência artificial, ou seja,
os sistemas especialistas (SE) são uma das técnicas da IA.
Um SE apresenta as seguintes vantagens:
• Melhora a produtividade, pois é mais rápido que pessoas.
• Otimiza a acessibilidade, pois torna o conhecimento acessível em diversos locais.
• Substitui especialistas, fazendo com que a informação permaneça indefinidamente, não importando se
a pessoa especialista está no local ou não.
Realidade virtual e multimídia: realidade virtual e multimídia são tipos de sistemas especializados usa-
dos por muitas organizações. A realidade virtual é uma simulação de um ambiente real ou imaginário
que possa ser vivido em três dimensões. Anteriormente, a realidade virtual referia-se à realidade virtual
imersiva, ou seja, aquela em que o usuário é imerso em um mundo 3D artificial, gerado pelo computador.
Porém, a realidade virtual também se refere às aplicações não imersas em sua totalidade, por exemplo,
navegação controlada por um mouse em um ambiente 3D sobre um monitor gráfico. Atualmente, uma
nova forma de realidade virtual é a realidade aumentada, que tem o potencial de sobrepor dados digitais
a imagens ou a fotos reais. Dispositivos de entrada, como luvas digitais e joysticks, permitem que o usuá-
rio possa navegar em um ambiente virtual e interagir com os objetos virtuais. A experiência é aprimorada
com o uso de sons, reconhecimento de voz e outras tecnologias.
Agora que conhecemos os sistemas especialistas, vamos ver como o processo de venda foi remodelado nos últi-
mos anos, transformando a experiência de compras presencial para uma compra on-line. Vamos conhecer sobre
o comercio eletrônico.
46
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
47
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
• Comércio eletrônico negócios a clientes (B2C - Business-to-consumer): é uma forma de comércio eletrô-
nico em que os clientes tratam diretamente com a empresa, sem intermediários. O B2C cresce cada vez
mais rápido e a razão para isso é que muitos bens e serviços são mais baratos quando são adquiridos pela
internet. Mais do que ferramenta para fazer pedidos, a internet é uma ótima forma de comparar preços e
características de diversos produtos e serviços.
• Comércio eletrônico cliente a cliente (C2C - Consumer-to-Consumer): é um subconjunto de comércio ele-
trônico que envolve transações eletrônicas entre clientes por meio de um terceiro que facilita esse processo.
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
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.
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.
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
• Aumento na precisão: quando se permite que compradores forneçam especificações e informações de seus
pedidos, permite-se eliminar erros humanos no processo de inserção de dados por parte do fornecedor.
• Melhora do serviço ao consumidor: o consumidor pode receber detalhes da sua compra, data de entrega
e nota fiscal por e-mail, o que ajuda a fidelizá-lo. Além disso, quando a empresa é pontual quanto às
datas de entregas, acaba eliminando o desejo do cliente de procurar por outras empresas, já que ele ficará
satisfeito com a fidelidade da empresa em que comprou seus produtos ou serviços.
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.
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
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
Os comerciantes devem criar estratégias que possam construir a confiança em seus clientes. As empresas devem
demonstrar para os seus clientes o desejo de construir um relacionamento forte, oferecendo programas de fide-
lidade. Pode-se também exibir, no site, todas as certificações de segurança que a empresa tiver.
O comércio eletrônico e móvel oferece muitas oportunidades e permite que as empresas possam vender em um
mercado global. As pessoas e as organizações podem adquirir produtos e serviços de todo o mundo, contudo,
essas oportunidades são acompanhadas de alguns obstáculos resultantes dessa dimensão global do comércio,
tais como:
• Desafios culturais: o site deve ser atraente e fácil de usar. Deve-se tomar cuidado para que o site não seja
ofensivo para as pessoas ao redor do mundo.
• Desafios de linguagem: as diferenças de linguagens podem ser barreiras para que alguns visitantes
entendam as informações do site.
• Desafios da moeda: o site deve conseguir estabelecer preços e aceitar pagamentos em diferentes moedas.
• Desafios da infraestrutura: o site deve permitir acesso para uma variedade de equipamentos e dispositivos.
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.
52
Fundamentos de Sistemas de Informação | Unidade 3 - Sistemas de Informação em Negócios
Na internet, os fabricantes podem formar um intercâmbio eletrônico, que, por sua vez, é um tipo de fórum em
que fornecedores, fabricantes e concorrentes realizam a compra e a venda de mercadorias e trocam informações
sobre o mercado.
Essa abordagem acelera a movimentação de matérias-primas e produtos entre os membros da comunidade do
negócio e reduz a quantidade de estoque a ser mantida.
Um exemplo de aplicativo usado nessa abordagem de fabricação é o Retail Link, intercâmbio eletrônico usado
pela Walmart para conectar os seus fornecedores (STAIR; REYNOLDS, 2016).
No aspecto do marketing, por meio da internet, as empresas podem reunir mais informações sobre o compor-
tamento e as preferências dos clientes. O recolhimento desses dados não é tarefa simples, pois cada visitante
de uma página oferece de forma voluntária os seus dados, ou seja, depende-se da boa vontade dos clientes em
fornecer informações.
Os anunciantes reúnem os dados que conseguem coletar para identificar partes específicas dos seus mercados.
Com isso, é possível direcionar mensagens publicitárias para determinado público, o que chamamos de segmen-
tação de mercado.
A segmentação de mercado resume-se a dividir o grupo de possíveis clientes em subgrupos (sexo, renda, estado
civil etc.) para enviar mensagens comerciais específicas para cada subgrupo.
A empresa americana Nielsen, por exemplo, realiza medição e análise de como os clientes fazem para conseguir
informações sobre o que desejam e sobre como eles compram mercadorias e serviços. A empresa usa um banco
de dados chamado Business Facts, que contém informações para mais de 12 milhões de empreendimentos. Com
os dados fornecidos, é possível estimar vendas para cada negócio e classificá-lo de acordo com os clientes.
É importante destacarmos ainda que muitas empresas disponibilizam aplicativos de celulares que permitem aos
compradores fazerem comparação de preços e produtos na internet. Um exemplo é o price check, da Amazon
(site de venda de livros digitais).
Ainda no sentido de diferenciarem-se no universo do comércio móvel e eletrônico, muitos fabricantes e varejistas
realizam o envio de cupons de desconto diretamente para os celulares dos seus clientes. Um exemplo dessa abor-
dagem é o Groupon, que permite que os clientes utilizem os códigos de cupons disponibilizados pelas empresas.
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
Considerações finais
Nesta unidade, aprendemos sobre os sistemas de informação para negó-
cios. Vamos retomar os pontos principais estudados até aqui?
• Uma organização utiliza o seu sistema de informação para buscar
vantagem competitiva.
• Uma empresa que obtém vantagem competitiva sempre se cer-
tifica de que o seu departamento de SI ofereça apoio às metas e
estratégias da organização.
• Business Intelligence (BI) pode ser traduzido como inteligência nos
negócios. A finalidade do BI é que o tomador de decisões tenha a
qualquer momento todas as informações relevantes para suportar
um processo de decisão.
• No BI, tudo começa com a coleção de dados contidos no data
warehouse. O data mining, por sua vez, “minera” os dados,
extraindo informações relevantes.
• O OLTP, do inglês “On-line Transaction Processing”, refere-se aos
sistemas transacionais.
• O OLAP, do inglês “On-line Analytical Processing”, refere-se à
capacidade de analisar grandes volumes de informações de dife-
rentes perspectivas dentro de um data warehouse.
• Um sistema de banco de dados multidimensional serve para a
modelagem de bancos de dados que auxiliam as consultas do
data warehouse nas mais diversas perspectivas.
• Os data marts são bancos de dados departamentais (por unida-
des de negócio) que podem mostrar visões relacionais ou multi-
dimensionais.
• SGC é um sistema de acompanhamento de programas de treina-
mento on-line e seu objetivo é agilizar o planejamento e o con-
trole sobre a transferência de conhecimento em projetos.
• Inteligência Artificial é o campo no qual um sistema adquire
características da inteligência humana.
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
Referências bibliográficas
STAIR, Ralph M.; REYNOLDS, George W. Princípios de Sistemas de
Informação. 11. ed. Cengage Learning Editores, 2016. ISBN Digital:
9788522124107.
57
Unidade 4
Desenvolvimento de Sistemas
Objetivos de Aprendizagem
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!
Glossário
Iniciamos nossa abordagem pela caracterização de processo. Pressman e Maxim (2016) ensinam que processo
é um conjunto de atividades, ações e tarefas realizadas na criação de algum artefato. Embora correta, essa defi-
nição nos parece bastante genérica e pode ser aplicada a quase a totalidade dos ramos de atividade humana. A
figura a seguir ilustra, como exemplo, o processo de montagem de um automóvel.
60
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
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
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
b. Prototipação: é uma versão inicial de um sistema de software usada para demonstrar conceitos, expe-
rimentar opções de projeto e, geralmente, conhecer mais sobre o problema e suas possíveis soluções
(SOMMERVILLE, 2010). O protótipo de uma interface de usuário, por exemplo, pode ser desenvolvido para
que o usuário tenha parâmetro para decidir sobre localização de campos e menus.
O desenvolvimento do protótipo deve ser rápido, a fim de não comprometer prazos. Ele pode ser usado na fase de
requisitos, para ajudar na descoberta e validação destes; na fase de projeto; e na fase de testes.
Por fim, é sempre importante alertar o cliente que o protótipo não corresponde à versão final do produto.
Essa abordagem de desenvolvimento coloca o cliente como figura ativa do processo de desenvolvimento e mini-
miza a ocorrência de mal-entendidos entre ele e a equipe de desenvolvimento. No entanto, a maior efetividade
desse paradigma em relação a outros (o modelo em cascata, por exemplo) também dá-se pelo fato de existirem
mais oportunidades para que o cliente mude de ideia em relação a determinada funcionalidade do sistema sem
que cause grande prejuízo financeiro e de tempo.
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
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
ele possa aprender sobre a solução que se desenha e registrar suas impressões para a equipe. A essa comunica-
ção em duas vias e em curtos períodos damos o nome de feedback.
Embora parte da literatura sobre o XP liste cinco valores fundamentais da metodologia, descreveremos quatro
deles.
• Feedback: baseia-se na comunicação entre cliente e equipe à medida que o sistema cresce em funciona-
lidades. Funciona assim:
(i) A equipe entrega ao cliente parte executável do sistema.
(ii) O cliente utiliza, revisa e eventualmente muda de ideia em relação a certas funcionalidades já imple-
mentadas.
(iii) De posse dessas informações, a equipe faz a devida readequação no sistema (ou na parte já imple-
mentada), inclui mais funcionalidades e retorna-o ao cliente, que repete a operação anterior.
• Comunicação: por meio de suas práticas, o XP visa promover a estreita comunicação entre membros da
equipe e entre a equipe e o cliente. O esforço para tornar o cliente parte efetiva da equipe procura evitar
que o desenvolvimento do projeto ou mesmo a implementação de funcionalidades sejam feitos de forma
especulativa. As reuniões diárias entre membros da equipe são, por exemplo, providência efetiva no esta-
belecimento da comunicação.
• Simplicidade: é comum entre profissionais de TI o raciocínio de que implementar funções que o cliente
não solicitou e tornar mais complexas as que ele, de fato, pediu, é um meio de causar boa impressão. O XP,
no entanto, prega que a simplicidade é elemento-chave para o desenvolvimento de sistemas eficientes,
objetivos e perfeitamente adequados às necessidades dos clientes.
• Coragem: uma das práticas do XP incentiva a permissão para que todos os membros da equipe tenham
acesso pleno e irrestrito ao código que está sendo construído. Outra prática estimula que o programa,
mesmo pronto e funcional, seja alterado para acomodar as regras de codificação da linguagem Java.
A implantação de uma nova metodologia de desenvolvimento, bem diferente da tradicional e baseada na intensa
interação entre cliente e equipe, pode gerar desconfiança no alto escalão da empresa. Bem, já temos argumen-
tos suficientes para entender que a coragem deve ser um dos fundamentos do XP, não acha?
63
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Essas bases do XP são elementos motivadores das práticas adotadas pela metodologia. Uma delas é a prática do
cliente presente. Ela assume o papel principal no processo de quebra de paradigmas proposto pelo XP. Afinal,
não era considerada como válida – sequer aconselhável – a presença efetiva do cliente durante o desenvolvi-
mento de um programa. Via de regra, a participação dele no projeto dava-se apenas no momento da coleta de
requisitos e na implantação do sistema.
O modelo ágil, no entanto, sugere que o cliente deve conduzir o desenvolvimento a partir da utilização do sis-
tema e que sua proximidade da equipe viabiliza essa condução. Essa prática nos revela que:
• O distanciamento é natural entre equipe e cliente.
• A proximidade fomenta o feedback, torna-o mais constante e evita mudanças bruscas na condução do
projeto.
• Cliente próximo evita trabalho especulativo.
• Quanto mais distante o cliente estiver, mais difícil será 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.
64
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Não se trata, contudo, de descrever e classificar exaustivamente cada uma das funções da área. Ao invés disso,
esta parte do nosso conteúdo deverá lhe servir como um delineador de perfis de pessoas que poderão fazer parte
do seu convívio profissional, seja como colega de trabalho, seja como alguém que temporariamente dividirá seu
tempo em um projeto específico.
Comecemos pela descrição de uma equipe de trabalho típica da metodologia Extreme Programming.
É bem verdade que as metodologias ágeis, de modo geral, estimulam a convivência de habilidades diversas em
sua equipe. Em outras palavras, elas buscam não promover a especialização como meio para o sucesso da equipe.
Mesmo assim, é preciso definir funções entre os participantes do projeto, inclusive para fins de organização da
equipe, como segue:
Gerente do projeto: tem a responsabilidade de conduzir as etapas do projeto, tratar diretamente com o cliente
e tratar dos assuntos administrativos. Embora o cliente idealmente faça parte da equipe de desenvolvimento, é
com esse gerente que ele terá contato com mais frequência.
Coach: compete a ele a escolha e a manutenção da tecnologia que será utilizada no desenvolvimento do pro-
duto. Deve ser experiente e conhecedor das habilidades técnicas da equipe para que a linguagem de programa-
ção seja de domínio comum na equipe.
Analista de teste: este profissional escreve os testes que serão realizados no produto (ou em parte dele) junto
com o cliente. Ele também é responsável por enviar ao pessoal de desenvolvimento os resultados dos testes
como meio de promover o feedback.
Redator técnico: documentar é preciso, mas esse processo não pode tornar-se motivo para morosidade do
desenvolvimento. É com a missão de livrar a equipe da documentação que o redator técnico entra em cena.
Desenvolvedor: antes chamado simplesmente de programador, este profissional é responsável, inclusive, por
levantar requisitos junto ao cliente, esboçar a solução e codificar o programa.
Tanto na condição de desenvolvedor quanto em qualquer outra que você esteja engajado no projeto do Sistema
de informação, será absolutamente comum o contato com o usuário e/ou o cliente. De tão importantes no con-
texto, esses perfis merecem desdobramentos.
Tipicamente, o cliente é o primeiro e mais importante componente do projeto. Para fins de conceituação, trata-
-se da pessoa ou do grupo de pessoas para quem o sistema é construído. É ele que define as características do
sistema e tem o direito de não pagar se não ficar satisfeito com o produto.
Sim, há grandes possibilidades de mal-entendidos entre o profissional que cuida do desenvolvimento do sistema
e o cliente. Problemas de comunicação são frequentes.
Outro elemento-chave no contexto é o usuário. A comunicação com ele é tão importante que se sugere que o
usuário seja membro da equipe de projeto. Caso não seja possível a comunicação direta com o usuário, deve-se
redobrar a atenção na documentação do sistema.
É fato que usuários têm perfis heterogêneos e que é um erro presumir que todos são iguais. Vejamos alguns dos
seus tipos:
• Usuários operativos: são funcionários burocratas, operacionais e até mesmo administradores que terão
contato diário com o sistema. Estão interessados em qual tipo de entrada terão que realizar ou como
reverter uma entrada incorreta. Tendem a ter uma visão local e conhecer apenas a tarefa específica que
executam. Podem ter dificuldades em explicar como suas atividades encaixam-se na organização ou qual
a finalidade da organização.
• Usuários supervisores: são funcionários em atividades de supervisão. Geralmente, chefiam um grupo
de usuários operativos, sendo responsáveis por seus desempenhos. Não raro, já foram usuários operati-
65
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
vos um dia e acabaram sendo promovidos. Por isso, conhecem o serviço do subordinado. Têm interesse
em aumentar o volume de trabalho realizado e reduzir custos e erros por meio do sistema. Esse perfil de
usuário pode considerar o sistema como um meio de reduzir a quantidade de usuários operativos ou de
evitar o aumento desse número quando o volume de trabalho crescer. Nesse contexto, o analista (você,
no caso) pode ser envolvido em disputas políticas.
• Usuários executivos: geralmente, não se envolvem diretamente com o projeto. É a autoridade financeira
para as necessidades do projeto e, na maioria dos casos, não foram usuários operativos ou esqueceram-
-se dessa experiência. Seu interesse no sistema gira em torno de aspectos estratégicos de lucros e per-
das a longo prazo, incluindo novos mercados, novos produtos e novas vantagens competitivas. Eles são
interessados na visão global do sistema e desprezam detalhes, principalmente aqueles relacionados à
execução do projeto.
Quanto mais elevado o nível do executivo, menos provável que conheça ou se interesse por tecnologia. Você deve
concentrar as discussões com ele nas características essenciais do sistema. As metas e prioridades da gerência
podem ser conflitantes com as dos usuários.
E lembre-se sempre: gerentes têm diferentes opiniões e visões e competem entre si. Alguns serão favoráveis,
outros serão contra ou omissos em relação ao novo sistema. As opiniões podem mudar ao longo do desenvolvi-
mento do projeto.
Embora a caracterização dos usuários por tipo de função já cubra a maioria dos perfis que poderemos encontrar,
outra classificação pode ser bastante útil: por nível de experiência.
• Usuário amador: sempre pronto a dizer: “Não entendo nada de computador!”. Normalmente, tem longa
experiência de trabalho e começou suas atividades antes do advento do computador. Pode até ser jovem,
mas 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
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
É muito provável que você já tenha tido contato com alguma outra nomenclatura de funções e cargos em TI.
Arquiteto de software, engenheiro de software, administrador de bancos de dados certamente são algumas des-
sas denominações que você já conhece. Vale a pena conhecê-las melhor.
Uma grande variedade de funções e especialidades surgiu nos últimos anos no mundo da
TI. Reportagem da Revista Exame, disponível em <https://exame.abril.com.br/carreira/os-7-
-profissionais-mais-disputados-na-area-de-ti/> (Acesso em: 23 jan. 2018) analisa algumas
das mais disputadas habilidades que um profissional de TI deve reunir para ter êxito para ser
bem-sucedido.
Assista ao vídeo disponibilizado pelo canal Olhar Digital, disponível em <https://www.you-
tube.com/watch?v=ZqkARSPXUJI> (Acesso em: 23 jan. 2018). As profissões do futuro são
resumidamente descritas em pouco menos de seis minutos.
Que tal uma olhada mais detida em um dos (ainda) principais modelos de desenvolvimento de software? Então,
sigamos com o ciclo de vida tradicional de um software.
67
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
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.
68
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
4.3.2 Projeto
Uma vez levantados, analisados, especificados e validados os requisitos, o processo deverá nos levar ao desenho
do produto. Se os requisitos nos mostram o que o sistema deverá fazer, o projeto deverá refletir como ele o fará.
Por meio do projeto, os requisitos são refinados de modo a tornarem-se aptos a serem transformados em pro-
grama. O trabalho principal de um projetista é o de decompor o produto em módulos, que podem ser conceitu-
ados como blocos de código que se comunicam com outros blocos por meio de interfaces.
4.3.3 Implementação
É na implementação que o produto se torna palpável e pode ser apresentado ao cliente. A correta tradução dos
requisitos mais uma vez estará sendo colocada em teste, já que as funcionalidades e restrições se tornam “visí-
veis” agora. Como estratégia de implementação, a equipe poderá dividir o trabalho de forma que cada progra-
mador (ou um pequeno grupo deles) fique responsável por um módulo do sistema. Idealmente, a documentação
gerada pela fase de projeto deve servir como principal embasamento para a codificação, o que não afasta a
necessidade de novas consultas ao cliente e à equipe de projetistas.
4.3.4 Testes
Aplicar testes significa executar um programa para que defeitos sejam descobertos. Embora não se trate de asse-
gurar que o código está perfeito, a confiança no produto aumenta bastante conforme a qualidade dos testes
aplicados. O processo inclui planejamento, elaboração de casos de teste, a efetiva execução do programa e a
análise dos resultados.
Em que pese a existência de outras igualmente importantes, é nas técnicas funcional e estrutural que os testa-
dores mais se apóiam. A primeira baseia-se nas funções do software para a geração dos requisitos de teste e a
segunda baseia-se no conhecimento da estrutura interna (ou implementação) do programa.
4.3.5 Manutenção
Com o produto implementado, testado e disponibilizado ao cliente, chega ao fim o trabalho da equipe, certo?
Ainda não!
Embora espere-se que o software inicialmente atenda aos requisitos colocados pelo usuário, o produto deverá
sofrer alterações e evoluir durante sua utilização. Defeitos não 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
Fundamentos de Sistemas de Informação | Unidade 4 - Desenvolvimento de Sistemas
Terminamos nosso estudo sobre processo de desenvolvimento de sistemas e nossa abordagem dos principais
perfis profissionais em um ambiente de criação de software. Esperamos que o conteúdo aqui tratado seja apro-
priado e útil em sua vida profissional. Bom senso e bom nível de percepção no trato com os usuários e clientes
certamente serão fundamentais para que você se torne uma boa referência nos projetos dos quais participar.
Esmere-se nas leituras adicionais, na resolução dos exercícios e até nosso próximo encontro!
70
Considerações finais
Nesta unidade, você teve contato com alguns dos principais processos de
desenvolvimento de sistemas e com o perfil de profissionais que atuam
no ramo. Em resumo, estudamos:
Conceitos fundamentais de desenvolvimento de sistemas: neste item,
tratamos do desenvolvimento de sistemas como a sequência de passos
que visam à produção e manutenção de um software e que se inter-rela-
cionam com recursos (humanos e materiais), padrões, entradas e saídas e
com a própria estrutura da organização.
Nesse contexto, focamos em dois métodos de desenvolvimento bas-
tante utilizados nos dias atuais, quais sejam, o processo evolucionário e
o Extreme Programming. O processo evolucionário, como o próprio nome
sugere, baseia-se na evolução de uma implementação inicial de um pro-
duto de software. A cada ciclo evolutivo, versões mais aprimoradas do sis-
tema são oferecidas ao usuário, até que o produto desejado e nas especi-
ficações corretas esteja pronto.
O Extreme Programming (XP) é uma metodologia ágil de desenvolvi-
mento, adequada para projetos que possuem requisitos que se alteram
constantemente, para equipes pequenas e para a construção de progra-
mas orientados a objetos. É indicado também para ocasiões em que se
deseja partes executáveis do programa logo no início do desenvolvimento
e que ganhem novas funcionalidades assim que o projeto avança.
O XP apoia-se em quatro pilares para atingir seus objetivos: feedback,
comunicação, simplicidade e coragem e duas das suas principais práticas
incluem o cliente presente e a programação em par.
Perfis profissionais em Sistemas de Informação: a grande variedade de
habilidades que se requer de um profissional acaba gerando uma miríade
de perfis desejados para atuação em TI. Neste item, tratamos de alguns
perfis de pessoas envolvidas em projetos, com ênfase em clientes/usuá-
rios. No entanto, começamos a abordagem do tema com a descrição dos
componentes de uma equipe típica do XP. Ela é composta por gerente do
projeto, coach, analista de teste, redator técnico e desenvolvedor.
A necessidade de estabelecer uma boa comunicação com usuários e
cliente será muito frequente em qualquer projeto. O cliente é peça funda-
mental na definição das características do sistema e tem o direito de não
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
Referências bibliográficas
PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software - Uma
Abordagem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968p.
ISBN 9788580555332.
73
Unidade 5
Engenharia de Software
Objetivos de Aprendizagem
75
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
76
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
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
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
A categoria de software aplicativo refere-se àqueles que permitem usar a tecnologia para resolver problemas
específicos.
78
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
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
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
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
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.
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
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
81
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
Ferramentas
Métodos
Processo
Foco na qualidade
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.
Projeto e
Especificação Validação Evolução
implementação
de software de software de software
de software
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
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
de software, de maneira que que extraiam as capacidades das pessoas em uma organização e as características
individuais do sistema em desenvolvimento. Em alguns sistemas, é importante um desenvolvimento bem estru-
turado; para outros, com requisitos que mudam rapidamente, provavelmente é mais eficaz um processo flexível
– por essas razões, é relevante considerar o ambiente no qual o software estará inserido.
Vamos conhecer agora três modelos de processo de software. O primeiro é o modelo cascata, que considera as
atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução, e que representa
cada uma delas como fases separadas, como especificação de requisitos, projeto de software, implementação,
teste e assim por diante, como representado na figura a seguir.
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
83
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
Atividade simultânea
Descrição Versões
Desenvolvimento intermediárias
do esboço
Desenvolvimento Validação
e integração e sistema
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
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
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.
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.
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
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
86
Fundamentos de Sistemas de Informação | Unidade 5 - Engenharia de Software
Pressman (2010) traz ainda sete princípios baseados em David Hooker, que se concentram na prática da enge-
nharia de software como um todo. Confira a seguir a descrição desses princípios na íntegra:
1. Primeiro princípio: a razão de existir - um sistema de software existe por uma razão: gerar valor para seus
usuários. As decisões devem ser tomadas com base nesse princípio. Ao pensar no requisito de um sis-
tema, indicar alguma funcionalidade e determinar as plataformas, pergunte a si mesmo: “Isso realmente
agrega valor ao sistema?”. Os outros princípios apoiam-se nesse primeiro.
2. Segundo princípio: KISS (Keep It Simple, Stupid!, ou seja: não complique!) - o projeto de software não é um
processo ao acaso. Ele deve ser o mais simples possível, mas não simplista; portanto, deve ser fácil de com-
preender e manter. Às vezes, são necessárias várias iterações para simplificar.
3. Terceiro princípio: mantenha a visão - uma visão clara é importante para o sucesso. Sem uma integridade
de conceito, o projeto corre o risco de se tornar uma colcha de retalhos inconciliáveis e ligados por para-
fusos impróprios, tornando a arquitetura frágil.
4. Quarto princípio: o que um produz, outros consomem - um sistema de qualidade industrial é construído
e utilizado de forma isolada. Portanto, especifique, projete e implemente ciente de que outros precisarão
entender o que você está fazendo. O público para qualquer produto de desenvolvimento de software é
potencialmente grande. Especifique com foco nos usuários e projete tendo em mente os implementado-
res. Busque facilitar o trabalho de todas essas
5. Quinto princípio: esteja aberto para o futuro - um sistema com tempo de vida mais longo tem mais valor.
Entretanto, os sistemas com “qualidade industrial” devem durar mais. Para atingir a expectativa, esses
sistemas precisam estar prontos para ajustarem-se a mudanças. Sistemas de sucesso são aqueles 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
Considerações finais
Nesta unidade, vimos muitos conteúdos importantes em engenharia de
software. Vamos retomar os pontos principais estudados até aqui.
• Os softwares podem ser classificados como software de sistemas e
software de aplicação, software científico/de engenharia, software
embutido, software para linha de produtos, aplicação para web e
software de inteligência artificial.
• Os processos de software são as atividades relacionadas à produ-
ção de um sistema de software.
• Modelos de processos de software são exibições abstratas desses
processos.
• Modelos gerais de processo descrevem a organização dos proces-
sos de software, como o modelo em cascata, o desenvolvimento
incremental e o desenvolvimento orientado a reuso.
• As boas práticas de engenharia de software passam por quatro
questões principais: entender o problema; planejar uma solução;
executar o plano e examinar o resultado.
• Sete princípios são importantes na prática de engenharia de sof-
tware que podem ser sintetizados da seguinte forma: 1 - software
tem uma razão de existir; 2 - software deve ser simples; 3 - tenha
uma visão clara do projeto;4 -o que um produz outro consome; 5-
sistema deve estar aberto para o futuro; 6- foque na reutilização;
7 - pense!
88
Referências bibliográficas
PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software - Uma
Abordagem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968p.
ISBN 9788580555332.
89
Unidade 6
Engenharia de Requisitos
91
Objetivos de Aprendizagem
92
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
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
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
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
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Requisitos
não funcionais
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
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Requisitos de sistema
Para que a descrição dos requisitos seja de fato apta a orientar o desenho (ou projeto) do sistema, é necessário
que ela encampe questões técnicas e definições detalhadas dos requisitos, o que não se espera em especifica-
ções voltadas ao usuário.
Essa demanda é suprida pela especificação dos requisitos de sistema. Sommerville (2010) trata os requisitos de
sistema como versões expandidas dos requisitos de usuário e como ponto de partida para o projeto do sistema.
Essa especificação pode ser feita usando linguagem natural, mas os cuidados na descrição devem ser tomados a
fim de evitar ambiguidades e flexibilidade demasiada no entendimento. O engenheiro de requisitos pode descrever
algo que o projetista interprete de modo distinto ao desejado e, então, estaremos diante de um mal-entendido
nada desprezível.
Enfim, usando linguagem natural ou outro tipo de notação, os requisitos de sistema devem descrever o compor-
tamento do sistema e suas restrições de operação.
Feita esta introdução, a partir do próximo item do nosso conteúdo, trataremos da engenharia de requisitos e das
etapas que nos levam a um documento que agrupa e detalha todos os requisitos do sistema. Adiante!
96
Fundamentos de Sistemas de Informação | Unidade 6 - 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
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
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
3. Será possível integrar o novo sistema a outros já existentes? É muito comum que sistemas não operem de
forma isolada. Integrar sistemas novos a outros já existentes economiza recursos e, com frequência, ajuda
a unificar as fontes dos dados.
A compilação das informações sobre a viabilidade de um sistema deve compor o que chamamos de relatório de
viabilidade. Com o aval de pessoas com poder de decisão sobre a continuidade do processo, o fluxo segue em
direção ao levantamento (ou à elicitação) dos requisitos.
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
Como as fontes dos requisitos são muitas e variadas, é natural que os meios para os obter também o sejam. Antes
de abordá-las, convém registrar uma visão geral a respeito dos envolvidos no processo de requisitos, afinal, é
deles que emanam as funcionalidades e é deles o interesse maior no sistema.
O termo stakeholder é usado comumente no meio que define os entes que, de alguma forma, participam ou têm
interesse em um projeto. Pressman e Maxim (2016) definem stakeholder como qualquer pessoa que se beneficie
de forma direta ou indireta do sistema que está sendo desenvolvido. Cada um com visões e interesses distintos,
é nos gerentes, colaboradores, equipe de marketing, time de vendas e futuros usuários que reside o interesse no
sistema; sobre eles, o engenheiro de requisitos deve dispensar atenção na busca pelos requisitos.
Isso posto, avancemos para dois dos principais meios de elicitação (ou levantamento) de requisitos.
98
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
Entrevista
Antes da sua aplicação, a entrevista deve ser planejada. Seus objetivos devem ser fixados, seu local e roteiro
definidos e os entrevistados criteriosamente escolhidos. O entrevistado é aquele que detém o conhecimento
do negócio e o entrevistador é o engenheiro de requisitos. A conversa deve ser objetiva e, durante seu curso, o
entrevistador deve tentar esclarecer conceitos e circunstâncias relacionados ao domínio do problema para então
ter condições de propor ideias que integrarão o domínio da solução.
Três tipos de entrevistas são as mais comuns. A primeira é a entrevista tutorial; nela, o entrevistado assume o
comando e procura explicar em detalhes aspectos daquele determinado procedimento. Na entrevista informal,
não se segue roteiro previamente definido e a conversa flui conforme a natureza das perguntas. Por fim, nas
entrevistas estruturadas, há um roteiro anteriormente definido de perguntas a serem feitas.
Na condição de profissional de requisitos, você deve avaliar o perfil do entrevistado e o tipo de informação que
deseja dele para decidir pelo melhor formato de entrevista.
Aplicação de questionário
O questionário geralmente é aplicado em formulário distribuído para os futuros usuários do sistema. Seu ela-
borador deve utilizar questões diretas e objetivas, dispostas preferencialmente na mesma ordem para todos os
participantes, e que consigam extrair respostas sobre o procedimento atual adotado.
Lembre-se: nem todos os futuros usuários se sentem à vontade ao responderem perguntas feitas pessoalmente,
ainda mais em ocasiões em que outras pessoas estejam presentes. Nesse sentido, o questionário pode ser uma
boa maneira de extrair informações dos envolvidos.
A observação do procedimento atual, as reuniões estruturadas e o levantamento de documentos são outros
meios eficientes para elicitar requisitos. Utilizados de forma isolada ou em conjunto, esses métodos visam extrair
todos os requisitos possíveis, de forma bruta e ainda não verificada.
Será na próxima etapa que os requisitos serão classificados, analisados e preparados para fazerem parte do docu-
mento de requisitos.
99
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de 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.
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
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de 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
Fundamentos de Sistemas de Informação | Unidade 6 - Engenharia de Requisitos
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
Considerações finais
Esta unidade tratou especificamente dos requisitos de software, com con-
teúdo que abrangeu desde conceitos iniciais até o documento final de
especificação de requisitos.
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.
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
Referências bibliográficas
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software - Uma Aborda-
gem Profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 968 p. ISBN
9788580555332.
106
Unidade 7
Manutenção e Reengenharia
Objetivos de Aprendizagem
108
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
109
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Assista ao filme “A Rede Social” (2010) e observe quantas versões e manutenções do sof-
tware o programador necessitou executar.
Agora que conhecemos os tipos de manutenção, é importante esclarecer três conceitos: manutenção de sof-
tware; arquitetura de software; e reengenharia de software.
• A manutenção de software trata-se, de modo geral, das mudanças que são feitas em resposta à modifi-
cação de requisitos; mas a estrutura fundamental permanece estável.
• A arquitetura do software é modificada geralmente de uma arquitetura centralizada para uma arquite-
tura distribuída.
• Na reengenharia de software, nenhuma funcionalidade é adicionada ao sistema, mas ele é reestruturado
e reorganizado para facilitar mudanças futuras.
No momento em que um software é inserido em um novo ambiente, é possível adicionar novas funcionalidades e
aproveitar as novas características do ambiente. Os defeitos de software tornam-se evidentes quando o sistema
é utilizado de formas inesperadas; por isso, adaptá-lo para acomodar o modo de trabalhar do usuário é a melhor
forma de corrigir tais defeitos.
Legenda: Quando o software entra em operação, seus defeitos serão apontados pelo usuário, o que demandará correções.
Fonte: Plataforma Deduca (2018).
Como vimos, a manutenção do software é extremamente necessária. Ela é importante para que o software evo-
lua. No século XX, foram difundidas oito leis da evolução de software, de autoria de Meir Lehman. Segundo Pon-
tes (2012) Lehman nasceu na Alemanha e foi para a Inglaterra na década de 1930, tendo trabalhado na IBM entre
1964 e 1972. Em 1974, publicou o que seria conhecido pelo mundo como as “Leis de Lehman”, que tratavam
da evolução de software. Nessa época, a abordagem dessas leis era bastante técnica e não levava em conta
110
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
as pessoas. Já no final do século XX, com a identificação por parte de empresas e profissionais de software da
necessidade de uma abordagem mais humana, o software ganhou relevância estratégica em todas as empresas
e difundiu-se em larga escala na vida das pessoas, demandando uma abordagem mais holística.
Sobre as Leis de Lehman os autores Pontes (2012) e Sommerville (2010) citam estas leis com importantes para a
manutenção de software. Veremos agora o que estes autores dizem a respeito destas leis.
A primeira lei de Lehman diz que a manutenção é irremediável; um programa deve ter uma mudança contínua e,
se isso não ocorrer, ele se tornará insatisfatório com o tempo. O software, quando modificado, volta ao ambiente
promovendo mais mudanças, de forma que o processo de evolução recomeça.
A segunda lei trata da complexidade crescente do software. Ela alega que, conforme um software é alterado,
sua complexidade aumenta. Para evitar que isso ocorra, é imprescindível investir em manutenção preventiva. É
importante haver um esforço para reduzir a complexidade final de um sistema enquanto este recebe alterações.
A terceira lei aborda a autorregulação. A evolução de um software é um processo autorregulador, o que significa
que sistemas de grande porte têm um movimento próprio, que é estabelecido no início do processo de desenvol-
vimento, e determina a tendência geral da manutenção de sistema e restringe o número de possíveis alterações.
A quarta lei de Lehman está relacionada à estabilidade organizacional. A mudança de recursos ou de pessoal não
tem muito impacto na evolução do sistema, o que se traduz em equipes de desenvolvimento de software com
baixa produtividade.
A quinta lei de Lehman fala sobre a familiaridade do software. Isso significa que, durante a vida do software a
mudança incremental é constante e está relacionada ao quanto o time de desenvolvedores está familiarizado
com o software.
Já a sexta e a sétima leis tratam respectivamente de crescimento contínuo e de declínio de qualidade. Significa
que devem ser oferecidas aos usuários novas funcionalidades, visto que o projeto inicial pode não incluir tudo o
que é necessário e funcionalidades são adicionadas progressivamente. Em relação ao declínio de qualidade, esta
diminui se o sistema não for modificado para refletir as mudanças no ambiente de operação.
A oitava e última lei fala sobre feedback. Os processos de evolução e manutenção de um software refletem siste-
mas de feedback em vários níveis, o que torna o sistema mais significativo.
As leis de Lehman precisam ser consideradas no planejamento de manutenção. Sommerville (2010, p. 171) diz que:
A manutenção de software ocupa uma proporção maior dos orçamentos de TI que o desenvol-
vimento. A manutenção detém, aproximadamente, dois terços do orçamento, contra um terço
para desenvolvimento, se gasta mais do orçamento de manutenção na implementação de novos
requisitos do que na correção de bugs.
Nos dados indicados por Sommerville (2010), vemos a distribuição dos custos de manutenção.
111
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Correção de
defeitos
(17%)
Adaptação Adição ou
de ambiente modificação de
(18%) funcionalidade
(65%)
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.
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
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Atualmente, muitos estudos têm sido realizados para diminuir os problemas em torno da documentação de
software. Entre os problemas, podemos citar documentação de baixa qualidade e desatualizada; processos de
documentação caros e dispendiosos; excesso de documentação, mas sem relevância e finalidade; dificuldade de
acesso etc.
A segunda etapa de manutenção é o planejamento do tipo de manutenção que será adotado. A partir da análise
da documentação do software, será possível determinar qual será o tipo de manutenção a ser aplicado e a estra-
tégia de execução.
As modificações de projeto e de código estão relacionadas ao que se usará como estratégia de execução da fase
anterior. A necessidade de alteração do projeto e do código tem grande impacto e alto custo, por isso, é impor-
tante estar alinhada com a estratégia e a necessidade da empresa em que o software está inserido. Softwares
com grande volume de informações e histórico da empresa 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.
113
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
114
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Previsão de
manutenção
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.
115
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
Glossário
116
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
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
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
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
necessário investir em qualquer uma das opções. Os custos da reengenharia dependem da complexidade e da
extensão do trabalho.
Observe a figura a seguir.
Aumento de custo
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
Fundamentos de Sistemas de Informação | Unidade 7 - Manutenção e Reengenharia
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
Considerações finais
Vamos retomar os pontos principais estudados até aqui?
• A manutenção de software acontece logo depois de o sistema ser
liberado para os usuários.
• A manutenção compreende as alterações feitas no software, as
quais podem ser pequenas mudanças para a correção de erros de
codificação; mudanças mais complexas para correção de erros de
projeto; ou melhorias expressivas para ajustar erros de especifica-
ção e ainda novos requisitos
• A manutenção de software engloba quatro tipos: manuten-
ção corretiva, manutenção adaptativa, manutenção evolutiva e
manutenção preventiva.
• Os custos relativos de manutenção são equivalentes aos custos de
desenvolvimento de sistema.
• O esforço de manutenção pode ser dividido em atividades produti-
vas, como análise, avaliação, modificação do projeto e codificação.
• A manutenibilidade de software é a facilidade com que um sof-
tware pode ser entendido, corrigido, adaptado e/ou aumentado.
• É importante que haja um planejamento para a manutenção de
software.
• O processo de evolução de software envolve o entendimento do
que necessita ser mudado e, depois, a implementação dessas
mudanças.
• A reengenharia tem como principal objetivo melhorar um sistema
por meio de mudanças significantes, mas sem alterar suas funções.
• Ao invés de substituir sistemas, a reengenharia de software traz dois
importantes benefícios: a redução de risco e redução de custo.
• Para a aplicação de um processo de reengenharia, é de extrema
importância avaliar o custo/benefício e os riscos envolvidos.
120
Referências bibliográficas
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.
121
Unidade 8
Conceitos de Projeto
123
Objetivos de Aprendizagem
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.
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
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Quando estudamos o Extreme Programming, ficamos conhecendo, entre outras coisas, os princípios da metodo-
logia, e os alçamos à condição de pilares de todas as práticas do modelo. Pois bem, a fase de projeto de software
também tem suas bases e, embora muitos conceitos relacionados ao tema tenham evoluído, esses paradigmas
têm resistido ao tempo. Fique ciente de que os conceitos que analisaremos na sequência nos servirão quando da
abordagem do processo de projeto.
8.1.1 Abstração
A solução modular leva a vários níveis de abstração. Abstrair é concentrar-se em certos aspectos relevantes ao
ambiente do problema. Cada passo da Engenharia de Software diminui o nível de abstração em direção à solução
do problema. O nível mais baixo de abstração é o código-fonte.
Abstração procedimental: ensinam Pressman e Maxim (2016) que a abstração procedimental (ou procedural)
refere-se a uma sequência de instruções que possui uma função específica e limitada. O nome de uma abstração
procedural indica sua função, mas sem os detalhes específicos.
Tomemos o esboço de uma aplicação tipo CAD como exemplo e dela consideraremos três níveis de abstração
procedimental:
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.
• 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
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Observe que, no nível de abstração mais baixo, o detalhamento da solução aumenta e torna-se mais próximo da
realização do código-fonte.
Abstração de dados: trata-se da descrição de um objeto por meio dos seus dados. Aqui, podemos tomar como
exemplo a composição de um contracheque – ou holerite, como também é conhecido. Embora possa haver
pequenas variações, a descrição dos dados desse objeto deve incluir nome do beneficiado, quantia bruta, quan-
tia líquida, horas normais trabalhadas, horas extras trabalhadas, desconto de Imposto de Renda e de INSS, entre
outros. Nesse caso, referencia-se o conjunto de dados pelo nome da abstração (contracheque).
Arquitetura de software
De acordo com que ensinam Pressman e Maxim (2016), arquitetura é a estrutura ou a organização dos com-
ponentes do programa, a maneira como esses componentes interagem e a estrutura de dados que são usados
pelos componentes.
De uma forma simples e objetiva, a arquitetura do sistema pode ser representada por um diagrama de blocos
que ilustra a organização do sistema e as interfaces com outros sistemas. Observe a figura a seguir; ela mostra a
arquitetura de um sistema (não trivial e de porte considerável) de controle de tráfego aéreo.
127
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Sistema de
mapa de clima
Sistema de Consoles do
Sistema de informações controlador
relatórios do controlador
Sistema de registro
de atividades
Pressman e Maxim (2016) descrevem três motivos para que a arquitetura do software seja considerada absoluta-
mente indispensável em um projeto:
• A arquitetura de software fornece uma representação que facilita a comunicação entre todos os envol-
vidos. Como as conexões entre módulos e demais elementos do produto estão esclarecidas, o entendi-
mento da interação entre os desenvolvedores dos módulos acaba ficando facilitado também. No mesmo
sentido, as divisões de trabalho certamente serão realizadas com base real.
• Desde a fase de projeto, a arquitetura coloca em evidência aquelas decisões de projeto que terão um
profundo impacto no trabalho de engenharia de software que se segue.
• Já que a modularização serve para dividir um problema grande em vários outros menores, a arquitetura
constitui um modelo relativamente pequeno e intelectualmente compreensível de como o sistema é
estruturado e de como seus componentes trabalham em conjunto.
Os mesmos autores destacam que, assim como na arquitetura convencional, aquela que representa um produto
de software também tem seus estilos. Cada estilo descreve uma categoria de sistema e especializa-se em um
aspecto seu, incluindo um conjunto de componentes (um banco de dados, por exemplo), um conjunto de conec-
tores que, por exemplo, possibilita a comunicação do sistema, as restrições que estabelecem como os compo-
nentes podem ser integrados e outros. Analisemos dois desses estilos:
128
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Arquiteturas centralizadas em dados: este estilo de arquitetura é fortemente baseado em um banco de dados
ou arquivo. Os componentes que atualizam, incluem ou excluem dados nessa base também têm destaque na
representação. A figura a seguir ilustra esse estilo.
Software Software
cliente cliente
Software Software
cliente cliente
Armazenamento
de dados (repositório Software
Software ou “quadro-negro”)
cliente
cliente
Software Software
cliente cliente
Em alguns casos o repositório de dados é passivo, isto é, o software cliente acessa os dados mesmo que estes
sofram alterações ou ações de outros softwares clientes. Uma variação dessa abordagem faz com o que o reposi-
tório se transforme em uma espécie de “quadro-negro”. Ele envia notificações ao software cliente quando ocor-
rem modificações nos dados que são do seu interesse.
Arquiteturas de chamadas e retornos: este estilo de representação permite uma adequada visualização da hie-
rarquia entre programas chamadores e subprogramas chamados. A figura a seguir ilustra o estilo de chamadas e
retornos, especificamente as ocorridas entre programas e subprogramas.
129
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Programa principal
Subprograma Subprograma
de aplicação de aplicação
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
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
O gráfico então aponta para um ponto central, identificado como “M”, em que a quantidade de módulos e o
custo para produzi-los equilibram-se mutuamente.
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.
Fonte: Pressman e Maxim (2016, p. 235).
A decisão sobre a quantidade de módulos sempre será influenciada também por decisões
de projeto relacionadas a certas facilidades que se deseja conferir ao sistema. O grau de sim-
plicidade para absorver alterações e a facilidade para receber testes e manutenções futuras
serão igualmente decisivos nessa escolha.
Embora esse modelo nos auxilie a estabelecer parâmetros sobre quantos módulos construir, ele pouco nos diz
sobre como construí-los. O conceito de independência funcional, explorado na sequência, lançará alguma luz
sobre esta questão.
Independência funcional
Módulos construídos idealmente com uma só função e sem interações excessivas com outros módulos são fun-
cionalmente independentes. A busca por essa característica justifica-se pela facilidade com que se empreende o
desenvolvimento e a manutenção do produto de software.
Para compreender esse fato, imagine um módulo que tenha muitas dependências com outros módulos. O pla-
nejamento e a execução de testes nesse módulo seriam ações bastante trabalhosas.
131
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
O mesmo raciocínio estende-se às ações de manutenção. Segundo Pressman e Maxim (2016), módulos inde-
pendentes são mais fáceis de serem mantidos e testados, já que possíveis consequências das modificações no
projeto serão limitadas e a propagação de erros será reduzida. Acrescente-se a esses benefícios a possibilidade
de criação de módulos reutilizáveis, o que diminuirá o tempo de criação de programas futuros.
É possível avaliar a independência dos módulos por meio de dois critérios ligados à qualidade do processo: a
coesão e o acoplamento. Um módulo coeso é aquele que acomoda uma função com um só propósito. Busca-se,
portanto, módulos com alta coesão.
O acoplamento é a medida da dependência de um módulo em relação aos demais. Um módulo deve depender o
menos possível de outro módulo, o que torna o baixo acoplamento o ideal a ser buscado pelo projetista.
A coesão que se busca durante a criação dos módulos leva o nome de coesão funcional. No entanto, alguns
outros tipos de coesão também foram criados e colocados em uma hierarquia.
Como pior caso de coesão a ser considerado, temos a coesão coincidental. Aqui, não há nenhuma relação entre
os elementos colocados no módulo, daí dizer que foram escolhidos por coincidência ou ao acaso.
Conforme já citado, o melhor caso de coesão é a funcional. Aqui, as operações descritas no módulo estão dispos-
tas, idealmente, em uma única frase, e ainda assim permanecem coerentes.
Entre esses dois tipos de coesão, temos a lógica, a temporal, a procedural, a de comunicação e a sequencial.
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
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Especificação
de requisitos
Atividades de projeto
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
Trataremos sucintamente de algumas das atividades do projeto nas próximas linhas e começaremos pelo 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
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
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.
Ainda no contexto de comparação entre um projeto de software e um projeto de casa, o projeto da interface tem
relação com portas, janelas e corredores de uma casa. Afinal, são esses elementos que explicitam os caminhos
para entrar, sair e transitar pela casa.
O projeto de interfaces para software representa fluxos de informação que entram e saem de um sistema e como
são transmitidos entre os componentes definidos como parte da arquitetura. Existem três elementos de projeto
de interfaces: interface do usuário; interfaces externas para outros sistemas, dispositivos, redes ou outros produ-
tores ou consumidores de informação; e interfaces internas entre vários componentes do projeto (PRESSMAN;
MAXIM, 2016).
Podemos imaginar os componentes como a fiação, a localização de tomadas, interruptores, ralos, armários e
vários outros detalhes associados a um cômodo.
No âmbito dos Sistemas de Informação, a comparação aproxima-se do conceito de uma peça de reposição.
Componente é um bloco construtivo modular para software de computador. Mais formalmente,
a Especificação da Linguagem de Modelagem Unificada define componente como uma parte
modular, possível de ser implantada e substituível de um sistema que encapsula implementação
e expõe um conjunto de interfaces (PRESSMAN; MAXIM, 2016, p. 286).
134
Fundamentos de Sistemas de Informação | Unidade 8 - Fundamentos de Sistemas de Informação
Por causa da variadade de aplicações e contextos em que é usado, o real significado do termo componente irá
variar em função do ponto de vista do engenheiro que o utiliza. O que não muda é o fato de que os componentes
situam-se no âmbito da arquitetura do software e devem comunicar-se e colaborar com outros componentes,
quais sejam, pessoas, meios de armazenamento ou outros sistemas.
O projeto de componentes de software descreve completamente os detalhes internos de cada componente de
software. Para tanto, o projeto no nível de componente define estruturas de dados para todos os objetos de
dados locais e detalhes algorítmicos para todo o processamento que ocorre em um componente e uma interface
que dá acesso a todas as operações de componentes (PRESSMAN; MAXIM, 2016).
Projeto de implantação
Implantar um software, 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
Considerações finais
Nesta unidade, tratamos do projeto de software, com abordagens espe-
cíficas de conceitos de projeto e processo de projeto. Em resumo, estuda-
mos os seguintes assuntos:
136
O processo de projeto de software
137
Referências bibliográficas
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem
profissional. 8. ed. Porto Alegre: Amgh, 2016.
138