Engenharia de Software I

Prévia do material em texto

Autor: Prof. Ivanir Costa 
Colaboradores: Prof. Luciano Soares de Souza
 Prof. Marcelo Nogueira
Engenharia de Software I
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Professor conteudista: Ivanir Costa
Doutor em Engenharia de Produção pela Escola Politécnica da Universidade de São Paulo (USP); mestre em 
Engenharia de Produção pela Universidade Paulista (Unip); graduado em Física pela USP. 
É orientador de mestrado do Instituto de Pesquisas Tecnológicas (IPT), da USP, e professor-titular do programa 
de mestrado e doutorado da Unip. É consultor em Ciência da Computação, com ênfase em Engenharia de Software, e 
certificado em Design Instrucional para EAD pelo Instituto Brasileiro de Desenho Instrucional.
© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou 
quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem 
permissão escrita da Universidade Paulista.
Dados Internacionais de Catalogação na Publicação (CIP)
C837e Costa, Ivanir.
Engenharia de software. / Ivanir Costa. – São Paulo: Editora Sol, 2014.
168 p., il.
Nota: este volume está publicado nos Cadernos de Estudos e 
Pesquisas da UNIP, Série Didática, ano XIX, n. 2-061/14, ISSN 1517-9230..
1. Engenharia de software. 2. Modelos e métodos ágeis. 3. 
Práticas de modelagem. I. Título.
CDU 681.3
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Prof. Dr. João Carlos Di Genio
Reitor
Prof. Fábio Romeu de Carvalho
Vice-Reitor de Planejamento, Administração e Finanças
Profa. Melânia Dalla Torre
Vice-Reitora de Unidades Universitárias
Prof. Dr. Yugo Okida
Vice-Reitor de Pós-Graduação e Pesquisa
Profa. Dra. Marília Ancona-Lopez
Vice-Reitora de Graduação
Unip Interativa – EaD
Profa. Elisabete Brihy 
Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
 Material Didático – EaD
 Comissão editorial: 
 Dra. Angélica L. Carlini (UNIP)
 Dra. Divane Alves da Silva (UNIP)
 Dr. Ivan Dias da Motta (CESUMAR)
 Dra. Kátia Mosorov Alonso (UFMT)
 Dra. Valéria de Carvalho (UNIP)
 Apoio:
 Profa. Cláudia Regina Baptista – EaD
 Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos
 Projeto gráfico:
 Prof. Alexandre Ponzetto
 Revisão:
 Valéria Nagy
 Juliana Maria Mendes
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Sumário
Engenharia de Software I
APRESENTAÇÃO ......................................................................................................................................................7
INTRODUÇÃO ...........................................................................................................................................................7
Unidade I
1 FUNDAMENTOS DA ENGENHARIA DE SOFTWARE ................................................................................9
1.1 Conceitos preliminares ........................................................................................................................9
1.2 Conceitos e objetivos .......................................................................................................................... 11
1.3 Conceitos de processo e produto de software ......................................................................... 13
1.3.1 Processos de software ........................................................................................................................... 13
1.3.2 A dimensão do produto de software .............................................................................................. 15
1.4 A natureza mutável do software ................................................................................................... 15
2 TIPOS DE APLICAÇÕES DE SOFTWARE .................................................................................................... 19
2.1 Classificações de aplicações de software ................................................................................... 19
2.1.1 Sistemas de Processamento de Transações (SPT) ou Transaction Processing 
System (TPS) ......................................................................................................................................................... 20
2.1.2 Sistemas de Informações de Gestão (SIG) ou Management Information Systems (MIS) .....23
2.1.3 Sistemas de Apoio à Decisão (SAD) ou Decision Support Systems (DSS) ........................ 25
2.1.4 Sistemas de Informação Executiva (SIE) ou Executive Information Systems (EIS) ...... 30
2.1.5 SE (Sistemas Especialistas) ou ES (Expert Systems) .................................................................. 31
2.1.6 Sistemas de Automação de Escritório (SAE) ou Office Automation Systems (OAS) ...34
2.2 Problemas com prazo, planejamento e custos ....................................................................... 35
2.3 Qualidade de software ....................................................................................................................... 38
Unidade II
3 PROCESSO DE SOFTWARE ............................................................................................................................ 45
3.1 Conceitos preliminares ..................................................................................................................... 45
3.2 Etapas do processo de software ..................................................................................................... 48
3.3 Processo Pessoal de Software (PSP) .............................................................................................. 51
3.4 Processo para equipe de software (TSP) .................................................................................... 55
4 MODELOS DE CICLO DE VIDA DE SOFTWARE ....................................................................................... 62
4.1 Introdução a ciclo de vida de software ....................................................................................... 62
4.2 Os principais modelos de ciclo de vida de software .............................................................. 64
4.2.1 O modelo codifica-remenda............................................................................................................... 64
4.2.2 O modelo cascata (waterfall) ............................................................................................................. 64
4.2.3 O modelo incremental .......................................................................................................................... 65
4.2.4 O modelo Rapid Application Development (RAD) ..................................................................... 68
4.2.5 Os modelos evolucionários ................................................................................................................. 70
4.2.6 Os modelos especializados .................................................................................................................. 72
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
4.2.7 O Unified Process (UP) ......................................................................................................................... 74
4.2.8 O Rational Unified Process (RUP) ..................................................................................................... 77
4.2.9 O processo Praxis ....................................................................................................................................79
4.2.10 O processo cleanroom (sala limpa) ............................................................................................... 80
Unidade III
5 OS MODELOS E MÉTODOS ÁGEIS .............................................................................................................. 86
5.1 Considerações e conceitos .............................................................................................................. 86
5.2 O método ágil eXtremme Programming (XP) ........................................................................... 91
5.3 O método ágil Scrum .......................................................................................................................... 94
5.4 O método ágil Iconix ........................................................................................................................... 99
6 OUTROS MODELOS E MÉTODOS ÁGEIS ................................................................................................102
6.1 O método ágil Feature Driven Development (FDD) ..............................................................102
6.2 O método ágil Adaptative Sofware Development (ASD) ...................................................106
6.3 O método ágil Dynamic Systems Development Method (DSDM) ..................................107
6.4 O método ágil Crystal .......................................................................................................................109
6.5 método ágil Test Driven Development (TDD) ..........................................................................110
6.6 A modelagem ágil (MA) ...................................................................................................................112
Unidade IV
7 PRÁTICAS DA ENGENHARIA DE SOFTWARE .......................................................................................118
7.1 Conceitos preliminares .....................................................................................................................118
7.2 Princípios centrais ..............................................................................................................................118
7.3 Práticas de comunicação ................................................................................................................120
7.3.1 A técnica de reunião walkthrough ............................................................................................... 123
7.3.2 A técnica de reunião Joint Application Development/Design (JAD) ............................... 124
7.4 Práticas de planejamento ...............................................................................................................127
7.4.1 Plano de projetos ................................................................................................................................. 130
7.4.2 Estrutura Analítica do Projeto (EAP) ou Work Breakdown Structure (WBS) ................131
7.4.3 Recursos ................................................................................................................................................... 132
7.4.4 Responsabilidades ............................................................................................................................... 133
7.4.5 Cronogramas ......................................................................................................................................... 134
7.4.6 Gerenciamento de riscos .................................................................................................................. 134
8 PRÁTICAS DE MODELAGEM ......................................................................................................................135
8.1 Conceitos preliminares .....................................................................................................................135
8.2 Modelagem orientada a objetos ..................................................................................................138
8.3 Modelagem de sistemas com a linguagem unificada de modelos ou Unified 
Modeling Language (UML) .....................................................................................................................142
8.4 Modelagem de processos de negócio com Business Process Modeling 
Notation (BPMN) ............................................................................................................................................................. 145
8.5 Outras práticas de modelagem de software ...........................................................................146
8.6 Práticas de construção .....................................................................................................................148
8.6.1 Arquitetura baseada em componentes ....................................................................................... 149
8.6.2 Verificação da qualidade ................................................................................................................... 149
8.6.3 Controle de mudanças ....................................................................................................................... 150
8.7 Práticas de implantação ..................................................................................................................150
7
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
APRESENTAÇÃO
O objetivo da disciplina Engenharia de Software I é apresentar e avaliar os conceitos básicos da 
engenharia de software, do ponto de vista dos seus processos e produtos de software, mostrando de que 
modo a disciplina pode ser implantada nas organizações, visando a um mercado competitivo e exigente 
na atualidade.
A disciplina foi organizada com a apresentação dos conceitos e da fundamentação dos princípios da 
engenharia de software; avança no detalhamento e na introdução aos conceitos de processos e produtos 
de software, tanto sob o ponto de vista do profissional envolvido quanto da estrutura da organização. 
Essa preocupação com a engenharia de software passa por uma organização das estruturas, mudança 
de cultura e qualificação das pessoas de Tecnologia da Informação (TI) nas empresas.
Dessa forma, a disciplina proporciona ao aluno os conhecimentos em métodos e técnicas de análise 
e projeto que o habilitam a escolher, utilizar e definir quais modelos, técnicas e ferramentas auxiliam 
no processo de desenvolvimento de software de sua organização. Dentre os modelos mais utilizados, 
são apresentados os pessoais, para os times e para a organização, tais como PSP, TSP, cascata e modelos 
unificados. A disciplina se encerra com a apresentação dos métodos ágeis, destacando-se XP, Scrum, 
Iconix e os princípios da modelagem ágil.
No final, serão discutidas as práticas da engenharia de software e as envolvidas na comunicação, no 
planejamento, na modelagem, na construção e na implantação de produtos de software.
INTRODUÇÃO
Desde que os sistemas de informação ou aplicações de software foram introduzidos no mundo dos 
negócios, vêm adquirindo um papel cada vez mais estratégico para as empresas, e isso vem ocorrendo 
tanto com provedores de informações quanto de soluções de tecnologia e serviços, cujos objetivos visam, 
por meio da automação, a aumentar a produtividade e, consequentemente, os lucros experimentados 
por tais empresas, principalmente, na fidelização de seus clientes e parceiros.
Esse papel estratégico, todavia, alinhado à massificação crescente dos computadores pessoais e 
de sua mobilidade, leva a uma conexão cada vez maior de pessoas e da sociedade de modo geral. Isso 
ocorre tanto no trabalho quanto em casa, na locomoção, em todos os lugares. A informação instantânea 
e a comunicação estão presentes, trazendo grandes desafios às áreas de TI das organizações.Surgem, também, cada vez mais desafios na produção rápida de soluções automatizadas e de alta 
qualidade de seus produtos de software e dos serviços prestados à população.
Atualmente, a TI tem presença nas mais diferentes expressões de uma organização, não se restringindo 
mais à execução de transações repetitivas e à automação de processos industriais; exige-se das soluções 
de TI uma integração de todos os processos, produtos e meios, indo dos níveis mais simples até o apoio 
às decisões estratégicas e ao monitoramento de resultado de negócios.
8
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
O que se observa é que a abrangência da TI é um fato, mas a busca da qualidade e da produtividade 
em seus processos não tem acompanhado e atendido às demandas dentro das expectativas geradas 
pelo avanço tecnológico presente. Isso tem exigido grande esforço das organizações na busca de uma TI 
organizada, no uso de práticas e ferramentas da engenharia de software, que levem a um novo patamar 
na qualidade de seus produtos.
Dessa forma, adotar modelos reconhecidos nos mercados nacional e internacional, como o RUP, o 
Scrum e outros, é também importante para a obtenção do sucesso nessa empreitada organizacional.
Conforme diversos autores consagrados que serão abordados neste livro-texto, com tal esforço, os 
processos e os produtos de TI, com qualidade assegurada, estarão contribuindo para a realização do 
grande objetivo de se ter uma empresa competitiva e desafiadora no mercado.
9
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Unidade I
1 FUNDAMENTOS DA ENGENHARIA DE SOFTWARE
1.1 Conceitos preliminares 
Desde que a chamada crise do software foi detectada e apresentada nas décadas de 1960 e 1970, 
muito esforço e muitos estudos foram direcionados para encontrar as causas ou os sintomas dos 
problemas. Dentre esses esforços, destaca-se o surgimento da engenharia de software, em meados dos 
anos 1970.
 Saiba mais
No livro Engenharia de Software: Fundamentos, Métodos e Padrões, de 
Wilson de Pádua Paula Filho (2003), no capítulo I, item 1, “Natureza”, é 
apresentado um resumo fundamental para o entendimento do que pode 
ser considerado engenharia de software, constituindo uma fonte confiável 
na busca de conhecimento a respeito desse tema.
As propostas que surgiram tinham como foco a necessidade de dar um tratamento de engenharia 
ao desenvolvimento de softwares cada vez mais complexos, sistematizando-os e criando formas de 
controlá-los.
O que caracteriza um sistema de software complexo é o fato de que ele é constituído 
por um conjunto de componentes abstratos, isto é, possui estruturas de dados e algoritmos 
encapsulados na forma de procedimentos, funcionalidades, módulos, rotinas, objetos ou agentes 
interconectados, compondo a chamada arquitetura de software. O resultado é um conjunto de 
códigos ou programas que deverão ser executados em sistemas computacionais de todos os tipos 
e abrangências.
O embasamento científico para a engenharia de software envolve o uso de diversos modelos e 
metodologias, que, apesar de serem abstratos, são precisos e permitem ao engenheiro de software criar 
sistemas de informação de cunho geral ou mais específicos; é considerada uma área do conhecimento 
da informática voltada para o levantamento de informações, a especificação de soluções sistêmicas, o 
desenvolvimento e a manutenção, com a aplicação de tecnologias e práticas de Ciência da Computação, 
Sistemas de Informação, Gerência de Projetos, Processos de Qualidade e outras disciplinas, objetivando 
organização, produtividade e qualidade.
10
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
Atualmente, essas tecnologias e práticas englobam pessoas, linguagens de programação, bancos de 
dados, ferramentas, plataformas, bibliotecas, padrões, processos, conhecimento e qualidade de software. 
Dessa forma, a engenharia de software, desde sua aparição, tem tentado resolver os problemas do 
desenvolvimento de softwares, em todas as suas dificuldades, destacando-se, em especial, aqueles 
relacionados aos requisitos do software. 
O foco está em prevenir a insatisfação do cliente por meio de um melhor entendimento dos requisitos 
estabelecidos e derivados, e, então, utilizá-los no projeto do software. A engenharia possui diversas 
definições. No entanto, Fritz Bauer (apud PRESSMAN, 1995) definiu o conceito mais conhecido, na 
primeira conferência dedicada ao tema, em 1969, da seguinte forma:
Engenharia de software é o estabelecimento e o emprego de sólidos princípios 
de engenharia, de modo a obter software de maneira econômica, que seja 
confiável e funcione de forma eficiente em máquinas reais (PRESSMAN, 
1995, p. 31). 
O autor Ian Sommerville diz que a ciência da computação está voltada para as teorias e os métodos 
que são a base dos computadores e sistemas de software. Por outro lado, a engenharia de software 
está voltada para os problemas práticos da produção. Algum conhecimento da ciência da computação 
é essencial para os engenheiros de software, da mesma forma que algum conhecimento de Física é 
essencial aos engenheiros elétricos (SOMMERVILLE, 2007).
 Observação
Pode-se dizer que a Engenharia de Software é uma disciplina da 
engenharia dedicada ao tratamento de todos os aspectos envolvidos na 
produção de softwares.
Paula Filho (2003) apresenta algumas definições envolvidas com a engenharia de software que 
podem provocar algumas confusões no uso dos conceitos e que estão apresentados no quadro 1.
Quadro 1 – Definições de informática, ciência e engenharia 
Informática Ciência que visa ao tratamento da informação por meio do uso de equipamentos e procedimentos da área de processamento de dados.
Ciência
Conjunto organizado de conhecimentos relativos a um determinado objeto, 
especialmente, os obtidos mediante a observação, a experiência dos fatos e um 
método próprio.
Processamento 
de dados (TI na 
atualidade)
Tratamento dos dados por meio de máquinas, com o fim de obter resultados da 
informação representada pelos dados.
Engenharia
Arte de aplicar conhecimentos científicos e empíricos, bem como certas 
habilitações especificas, à criação de estruturas, dispositivos e processos que 
se utilizam para converter recursos naturais em formas adequadas para o 
atendimento das necessidades humanas.
Fonte: adaptado de Paula Filho (2003).
11
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
O autor afirma que a informática, dessa forma, é definida como uma ciência cujo assunto é o 
processamento de informações por meio de máquinas. A ciência, por sua vez, tem como foco a 
acumulação do conhecimento por meio do método científico, geralmente, baseado em experimentos e 
observações.
 Saiba mais
Para saber mais sobre as diferenças existentes entre a Engenharia de 
Software e a Ciência da Computação, pode ser acessado o site da IEEE 
Computer Society, disponível em: <http://www.swebok.org>, que traz farto 
material sobre o corpo de conhecimento da disciplina.
1.2 Conceitos e objetivos
A engenharia de software é composta de diversos conceitos fundamentais na área e abrange um 
conjunto de métodos ou práticas e diversas ferramentas que possibilitam aos profissionais desenvolverem 
softwares de alta qualidade. 
Fernandes (2003) afirma que a Engenharia de Software é a disciplina do conhecimento humano 
que tem por objetivo definir e exercitarprocessos (humanos atuando como máquinas), métodos 
(planos de processos), ferramentas e ambientes (máquinas apoiando processos e métodos) para a 
construção de softwares que satisfaçam necessidades de clientes e usuários dentro de prazos e 
custos previsíveis.
A primeira definição é a de software:
• muitas pessoas não sabem dizer realmente o que é um software;
• um software é um produto desenvolvido por profissionais que também dão suporte a ele, em longo 
prazo, e abrange programas executáveis em computadores de diversos portes ou arquiteturas, 
conteúdos que são apresentados quando programas são executados, informações descritivas em 
forma impressa ou virtual.
Outro conceito importante é o de software legado, que é um software bastante antigo, que 
tem sido continuamente modificado para adequar-se às mudanças dos requisitos de negócio ou 
às novas tecnologias e é considerado indispensável às funções de negócios fundamentais para a 
empresa.
A engenharia de software está fortemente relacionada ao software, na medida em que capacita os 
desenvolvedores para o desenvolvimento de sistemas complexos, dentro do prazo acordado e com alta 
qualidade, dois aspectos muito importantes para o sucesso de um projeto.
12
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
A criação de um software bem-sucedido se dá por meio de um processo que possa ser adaptável 
às diversas condições e projetos, da maneira mais ágil possível, que conduzirá a um resultado de alta 
qualidade, atendendo às necessidades dos clientes que, de fato, usarão o software.
 Observação
A camada de processos representa um conjunto de atividades, recursos e 
ferramentas que são necessários para se ter um processo de desenvolvimento 
coerente, integrado e gerenciado, aliado às melhores práticas, que resulta 
em produtos de alta qualidade e em clientes satisfeitos.
Outro conceito bastante importante na engenharia de software é o de artefato, que, do ponto 
de vista de um desenvolvedor de software consiste em um conjunto de documentos produzidos ao 
longo do projeto e programas de computador, bem como nos dados que formarão o conteúdo do 
sistema. Do ponto de vista do usuário ou do cliente, o artefato consiste em informações resultantes que 
tornam melhores as tarefas automatizadas pelo software, como documentação, help on-line, telas de 
navegação, gráficos apresentados etc.
A engenharia de software está fortemente ligada à noção de qualidade. A figura a seguir mostra 
suas camadas.
Ferramentas
Métodos
Processo
Foco na qualidade
Figura 1 – Camadas da engenharia de software 
A Figura 1 mostra que a camada Foco na qualidade dá sustentação a todas as outras camadas, 
já que a qualidade envolve a cultura de aperfeiçoamento contínuo de processos envolvidos com o 
desenvolvimento e a manutenção do software.
Para Pressman (2006), a camada de processos:
• é a responsável por manter as camadas de tecnologia coesas e possibilita o desenvolvimento de 
software de forma racional e dentro do prazo;
• o processo define uma metodologia, ou um conjunto de métodos, que deve ser estabelecida para 
que possamos ter uma entrega efetiva do software; 
13
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
• o processo também é a base para o controle do gerenciamento de projetos de software, pois permite 
aplicar métodos técnicos, bem como gerar diferentes produtos, como modelos, documentos, 
mudanças, além de estabelecer marcos, garantir qualidade e gerir mudanças de forma apropriada.
A camada de métodos:
• é responsável por fornecer informações técnicas para desenvolver produtos de software;
• os métodos envolvem diversas tarefas, como comunicação, análise de requisitos, modelagem de 
projeto, construção de software, testes e suporte.
Quanto à camada de ferramentas:
• as ferramentas são responsáveis por fornecer suporte automatizado ou semiautomatizado para o 
processo e os métodos;
• se as ferramentas utilizadas nos métodos e processos forem interligadas de forma que informações 
criadas por uma ferramenta são usadas por outra, serão denominadas de suítes de ferramentas.
Essas ferramentas são conhecidas como “engenharia de software com o auxílio do computador”, ou, 
em inglês, Computer-Aided Software Engineering (CASE).
 Observação
É importante ressaltar que somente as ferramentas não conseguem 
atender a todos os preceitos e exigências da engenharia de software. A 
participação de pessoal preparado e estimulado é um diferencial competitivo 
nas organizações de TI.
1.3 Conceitos de processo e produto de software
As normas e os modelos envolvidos com a engenharia de software definem, com clareza, que um 
processo de software é a forma de se obter um produto de software. Mas qual é a diferença entre 
processo e produto de software?
1.3.1 Processos de software
Para entendimento, apresenta-se a seguir um conjunto de definições de diversos autores consagrados 
na engenharia de software:
Para Paula Filho (2003, p. 4), “um processo de software é um conjunto de passos parcialmente 
ordenados, constituídos por atividades, métodos, práticas e transformações usados para atingir uma 
meta”.
14
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
De acordo com Pressman (2006, p. 16), “processo de software é como um arcabouço para as tarefas 
que são necessárias para construir software de alta qualidade. Um processo de software define a 
abordagem que é adotada quando o software é elaborado”.
Já para o autor Sommerville (2007, p. 64): “um processo de software é um conjunto de atividades e 
resultados associados que levam à produção de um produto de software”.
A partir dessas definições, é possível entender que o processo é a forma pela qual os engenheiros de 
software irão produzir um produto de software, e o processo são os passos ou as atividades necessárias 
para se construir um software que, junto aos seus modelos e documentos, denomina-se produto de 
software.
Ainda para os autores Paula Filho (2003), Pressman (2006) e Sommerville (2007), existem quatro 
atividades fundamentais que são comuns para todos os processos de software:
• Especificação do software:
— em que os clientes e os engenheiros definem o software a ser produzido e as restrições para 
a sua operação. As especificações ou descrições são feitas por meio de diversas técnicas de 
levantamento de informações, modelagem e descrições;
— também é útil o uso de ferramentas de prototipagem para apoiar o entendimento do que o 
software deverá fazer e apresentar ao usuário, quando em produção.
• Desenvolvimento do software:
— em que o software é desenhado e programado;
— o desenvolvimento envolve diversas tarefas, como conhecimentos e especializações diversos, 
tanto para a montagem da arquitetura da solução quanto para as escolhas das soluções de 
tecnologia de banco de dados e de desenvolvimento (como linguagens de programação, uso 
de frameworks etc.).
• Validação do software:
— em que o software é verificado para garantir que está de acordo com os requisitos do cliente;
— a validação ocorre durante a entrega do produto final ao usuário ou cliente, que deverá validar 
se o produto executa as funcionalidades para o qual foi contratado.
• Evolução do software:
— em que o software é modificado para adaptá-lo a mudanças do cliente requisitadas pelo 
mercado;
15
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4ENGENHARIA DE SOFTWARE I
— todo produto de software sofre, ao longo do tempo, alterações, tanto para corrigi-lo quanto 
para promover sua evolução quanto às suas regras atuais ou novas tecnologias.
Ainda para o autor Sommerville (2007), têm-se tipos diferentes de sistemas de informação 
ou software que necessitam de diferentes processos de desenvolvimento, por exemplo: software 
de tempo real para uso em aviões tem de ser especificado antes de começar o desenvolvimento, 
em razão do seu alto risco e das garantias de que ele não falhará em uso; já em um sistema de 
e-commerce, a especificação e a programação podem ocorrer juntas, em virtude da sua baixa 
taxa de risco.
Consequentemente, essas atividades genéricas de desenvolvimento podem ser organizadas de 
diferentes maneiras e descritas em diversos níveis de detalhes, para diferentes tipos de software. 
Contudo, é certo que usar um processo de software inadequado reduz a qualidade ou a utilidade do 
produto e aumenta os custos do desenvolvimento.
1.3.2 A dimensão do produto de software
Para entendimento do conceito de produto de software, pode-se apresentar a definição contida na 
norma internacional ABNT NBR ISO/IEC 12207 (2000), em que produto de software é um conjunto de 
programas de computador, procedimentos e dados, e documentação associada.
De acordo com Fernandes (2003), tem-se:
O software é um produto do trabalho humano cada vez mais presente 
na sociedade. Qualquer discussão sobre a prática de software deve se 
fundamentar na compreensão da real natureza do que é software e no 
relacionamento que ele provoca entre pessoas. O software é um artefato 
criado pelo homem que não se enquadra em definições convencionais 
encontradas no dicionário, pois, além de ser uma entidade de natureza 
mecânica, é uma entidade descritiva, complexamente hierarquizada, 
cognitiva-linguística e histórica, concebida através de esforços coletivos 
durante um considerável período de tempo (FERNANDES, 2003, p. 29). 
1.4 A natureza mutável do software
De acordo com autores consagrados da disciplina, o software é um produto diferenciado dos demais 
de manufatura, possuindo características que lhe dão natureza própria e específica. Conhecer essas 
características é o primeiro passo para compreender os problemas enfrentados por todos os envolvidos 
no processo de software e tentar lançar uma luz sobre as razões da existência da tão comentada “crise 
do software”.
De acordo com Capovilla (1999), existem diferenças importantes entre produtos de software e 
produtos manufaturados que não podem deixar de ser notadas. 
16
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
• Complexidade: normalmente um produto de software tem muitas regras a serem cumpridas; 
muitas linhas de código a serem implementadas; e diversos desenvolvedores, que têm ideias 
diferentes e, algumas vezes, divergentes, mas que podem levar à mesma solução.
— Softwares nascem das necessidades do cliente e das áreas de negócio e, dessa forma, 
devem representar modelos do mundo real. Cada detalhe presente no ambiente ou cada 
problema que o software deverá resolver transforma-se num elemento a mais na aplicação 
ou no sistema de informação que está sendo desenvolvido. Isso gera complexidade no 
processo de desenvolvimento, que se torna maior à medida que a quantidade desses 
elementos aumenta e à medida que estes possuem diversas interações. Dessa forma, o 
esforço não é somente o de construir a nova funcionalidade, mas envolve, também, a 
necessidade de integrá-la com as demais.
— Como o software possui diversas camadas de funcionalidades, umas chamando as outras 
e vice-versa, a complexidade resultante poderá se estender a outros níveis ou camadas, 
se levarmos em consideração o elevado número de possíveis estados que o software pode 
alcançar. Os desenvolvedores têm grandes dificuldades em lidar com grandes sistemas ou 
sistemas complexos, além de o tempo mostrar que o simples acréscimo de mais pessoas em 
uma equipe de desenvolvimento não torna o trabalho mais fácil. 
• Invisibilidade e intangibilidade: o software é invisível para o usuário ou cliente. O que se vê são 
as consequências da execução, diferentemente de um produto manufaturado oriundo de outras 
engenharias, como um prédio (da engenharia civil) ou um carro (da engenharia mecânica ou da 
automotiva).
— Ao contrário de outros produtos, o software não pode ser desenhado ou projetado de uma 
maneira que corresponda ao mundo real em toda a sua plenitude. Ele não possui natureza 
física, não possui formato nem dimensões e não pode ser definido geometricamente. 
— O software é um produto que não pode ser visto nem tocado pelo homem. Mesmo os modelos 
ou diagramas criados para representá-lo, na verdade, não descrevem o software em si, mas 
representam os fluxos de controle, de dados ou padrões de dependência. Isso dificulta o 
trabalho dos desenvolvedores, que deve ser baseado apenas em representações abstratas e 
grandes volumes de textos descritivos.
— Também a comunicação durante o projeto fica prejudicada, uma vez que é difícil falar sobre 
um item abstrato, e fica muito dependente de conhecimentos dos envolvidos no problema e 
nas tecnologias de solução. Dessa forma, parte do conhecimento sobre o projeto fica retida 
na mente de membros específicos da equipe, haja vista que esse conhecimento não pode 
ser representado de forma satisfatória; mesmo que os desenvolvedores utilizem modelos 
para representar o sistema de software, essa intangibilidade causa grandes dificuldades de 
comunicação, tanto entre os elementos da equipe de desenvolvimento quanto entre a equipe 
e o cliente, podendo acarretar problemas no produto.
17
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
• Conformidade e modificabilidade: o software é a interface entre diversas entidades do meio no 
qual é utilizado.
— Sistemas de software não costumam existir em conformidade com princípios básicos e 
imutáveis, já que um ambiente de negócio normalmente vive em mutação. Ao contrário 
da engenharia tradicional, na engenharia de software é praticamente impossível formar 
uma base sólida de conhecimento, em razão da rapidez de sua evolução. Essa inexistência 
de princípios básicos faz que os padrões de software costumem se basear apenas em boas 
práticas.
— A maior parte da literatura, das normas e dos modelos da engenharia de software é formada 
na base das boas práticas existentes na área.
— Além dessa característica dinâmica dos sistemas representados pelo software, a rápida evolução 
tecnológica gera mais uma incerteza: as próprias técnicas de desenvolvimento e ferramentas 
mudam em velocidade acelerada, e as equipes precisam estar sempre em treinamento para 
acompanhar esse ritmo de mudanças e para se adequarem às recentes tecnologias.
— À medida que uma equipe de desenvolvimento começa a se atualizar, passa a buscar 
novos desafios – nem sempre disponíveis –, e as empresas enfrentam outro problema: 
lidar com os sistemas legados, que, em sua maioria, usam tecnologias de dez ou vinte anos 
atrás e que hoje são consideradas obsoletas. Existe grande dificuldade de se encontrar 
profissionais para mantê-las nos sistemas ainda em uso. O bug do ano 2000 (ou bug do 
milênio) é um exemplo clássico, bem como os sistemas desenvolvidos durante mais de 
trinta anos na linguagem Cobol.
• Produção sob medida (taylormade): para software, não existe produção em série, cada usuário é 
um cliente que usa o software à sua maneira, com ênfase em partes diferentes.
— Diferentemente da produção em série da indústria de manufatura (carros, aparelhos domésticos 
etc.), cada produtode software possui características específicas e determinadas pelo negócio, 
pela cultura da empresa e pelos interesses de usuários e clientes. Essa característica intrínseca 
dificulta a criação de softwares padronizados e de prateleira, apesar de existir uma indústria 
crescente de ERPs. Mesmo estes ainda necessitam de customizações e adaptações específicas 
para cada empresa adquirente.
— Não se desgasta com o uso: em software, os componentes lógicos são duráveis. A falha resulta 
de erros humanos cometidos durante o processo de desenvolvimento; alguns softwares foram 
desenvolvidos há mais de trinta anos e continuam operando dentro de grandes empresas. 
— Normalmente, com o tempo, aumenta o número de usuários e são acrescentadas novas 
funcionalidades, mas as básicas continuam as mesmas e, se não forem necessárias mudanças 
específicas, os códigos continuarão os mesmos ao longo do tempo.
18
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
• Não tem prazo de validade: o software não é sensível a problemas ambientais, nem sofre nenhum tipo 
de defeito em razão do uso cumulativo (aumento de usuários e execução em máquinas diferentes).
— O custo final do software é, basicamente, o custo do projeto e do desenvolvimento. O maior 
gasto encontra-se na mão de obra, em todos os níveis do processo, tais como analistas de 
sistemas, arquitetos, DBAs, programadores, testadores etc.
— O software é o único produto em que, quando há defeito, o cliente paga pela correção, exceto 
no caso de erros ou defeitos apresentados durante o tempo da garantia.
• Ilusão de maleabilidade (fácil de mudar): o software possui uma ilusão de maleabilidade 
extremamente elevada, em razão da sua natureza abstrata ou não física. As pessoas o notam 
como algo de fácil adaptação. 
— Em geral, os usuários e, principalmente, os clientes o consideram extremamente maleável e 
creem que qualquer mudança terá baixo custo e prazo curto para ser feita. 
— É bastante comum o cliente mudar o escopo do projeto enquanto este se encontra em 
andamento, sem atentar para as implicações que isso acarreta nos compromissos de prazo, 
custo e recursos envolvidos.
— De acordo com Kruchten (2002), o software é, por definição, fácil de mudar; então, naturalmente, 
as organizações querem tirar vantagem dessa característica. Pressionam por mudanças no 
software durante todo o seu desenvolvimento, até mesmo quando são liberados. Na construção 
de uma ponte, por exemplo, não existe esse tipo de flexibilidade, o cliente não pode dizer: “Agora 
que eu já vejo os pilares, eu gostaria que essa ponte fosse colocada dois quilômetros rio acima”. 
— Na engenharia civil, qualquer um teria a clara percepção do esforço monumental de mover 
uma ponte de um lugar para outro, mas, no caso do software, sua invisibilidade como produto 
cria a ilusão de que é extremamente fácil realizar uma mudança, levando o usuário a solicitá-la 
com mais frequência.
As qualidades de um produto de software podem ser divididas entre aquelas que são diretamente 
visíveis para o cliente e aquelas que afetam principalmente o desenvolvimento desse produto; a 
confiabilidade é diretamente visível pelo cliente, já sua capacidade de manutenção afeta basicamente 
a área de desenvolvimento, embora suas consequências possam atingir o cliente de forma indireta, 
aumentando o tempo entre as liberações de novas versões, por exemplo. 
Propriedades que são diretamente visíveis pelos usuários do produto de software, tais 
como confiança, latência, usabilidade e taxa de atendimento, são chamadas de propriedades 
externas; as que não são diretamente visíveis por usuários finais, tais como manutenibilidade, 
reusabilidade e rastreabilidade, são chamadas internas, mesmo quando seu impacto no processo 
de desenvolvimento e evolução do software pode afetar os usuários indiretamente (PEZZÉ; 
YOUNG, 2008).
19
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
 Saiba mais
É possível conhecer mais sobre a natureza do software e dos sistemas, a 
diferença fundamental entre engenharia de software e outras engenharias, 
e se um sistema de computador é uma máquina e apresenta a tríade da 
prática do software no seguinte material: 
FERNANDES, J. H. C. Natureza do software e dos sistemas. Disponível em: 
<http://www.cic.unb.br/~jhcf/MyBooks/iess/Intro/NaturezadoSoftware 
eSistemas.pdf>. Acesso em: 12 fev. 2014. 
2 TIPOS DE APLICAÇÕES DE SOFTWARE
2.1 Classificações de aplicações de software
Para atender às necessidades das organizações e da própria sociedade, foram surgindo, ao longo do 
tempo, diversos tipos de aplicações de software ou sistemas de informação que abrangem praticamente 
todas as atividades comerciais, industriais e pessoais da sociedade atual.
Os autores da área, usando formas ou classificações diferentes, definem seis tipos básicos de 
aplicações de software ou sistemas de informação:
• Sistemas de Processamento de Transações (SPT) ou Transaction Processing Systems (TPS); 
• Sistemas de Informações de Gestão (SIG) ou Management Information Systems (MIS); 
• Sistemas de Apoio à Decisão (SAD) ou Decision Support Systems (DSS);
• Sistemas de Informação Executiva (SIE) ou Executive Information Systems (EIS); 
• Sistemas Especialistas (SE) ou Expert Systems (ES);
• Sistemas de Automação de Escritório (SAE) ou Office Automation Systems (OAS).
Esses aplicativos de software (ou sistemas de informação), em virtude de sua importância, serão 
detalhados a seguir.
20
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
 Saiba mais
Vale a pena ler o seguinte artigo, que discute o papel do administrador 
de uma empresa diante dos sistemas de informação, principalmente, dos 
que são necessários para apoiar a tomada de decisões nos diversos níveis e 
funções organizacionais: 
FIGUEIREDO, I. L. Tipos de sistemas de informação na empresa. Oficina 
da Net, Santa Cruz do Sul, 7 fev. 2008. Disponível em: <http://www.
oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informacao_na_
empresa>. 
2.1.1 Sistemas de Processamento de Transações (SPT) ou Transaction Processing System 
(TPS)
Constituem um tipo de sistema de informação ou aplicação de software transacional. Coletam, 
guardam, modificam e recuperam as transações (operações das áreas de negócio) de uma organização.
Uma transação é um acordo, uma comunicação, um movimento ou algo realizado entre entidades 
diferentes ou objetos, muitas vezes, envolvendo a troca de itens de valor, tais como informações, bens, 
serviços e dinheiro. Além disso, caso a troca seja de mercadorias, de um lado, por dinheiro, do outro, 
será conhecida como transação de duas partes: uma parte está dando o dinheiro, e a outra parte está 
recebendo a mercadoria.
São exemplos de transações: financeira, imobiliária, custo de transação, de banco de dados, 
processamento de transações etc.
Outra definição indica que uma transação é um evento que gera ou modifica dados que são, 
eventualmente, armazenados em um sistema de informação ou aplicação de software.
Para ser considerado um SPT ou TPS, um sistema de informação deve passar pelo teste de Atomicidade, 
Consistência, Isolamento e Durabilidade (ACID). Em ciência da computação, ACID é um conjunto de 
propriedades que garante que as operações de bancos de dados sejam processadas de forma confiável. 
No contexto de bancos de dados, uma única operação lógica sobre os dados é chamada de transação. 
 Lembrete
Uma transferência de fundos de uma conta bancária para outra, apesar 
de envolvervárias alterações (como uma conta de débito e outra de crédito), 
é uma transação única.
21
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
A essência de um programa transacional é que ele gerencia os dados que devem ser deixados 
em um estado consistente. Um exemplo: se um pagamento eletrônico for feito em um sistema 
bancário, o montante deverá ser retirado de uma conta e adicionado a outra. Se o sistema 
ou a aplicação não puder completar apenas um desses passos, deixará a transação bancária 
inconsistente.
Sistemas desse tipo são integrados e atendem ao nível operacional, bem como computadorizados, 
realizando transações rotineiras, como folha de pagamento, pedidos etc.
De acordo com Figueiredo (2011), os recursos são predefinidos e estruturados, e por meio deles 
os gerentes monitoram operações internas e externas da empresa. Dessa forma, são críticos, pois, se 
deixarem de funcionar, poderão causar danos à própria empresa e a outras. Para o autor, atendem a 
quatro categorias funcionais: vendas/marketing, fabricação/produção, finanças/contabilidade e recursos 
humanos.
No caso de a conclusão da transação falhar, como prevenção, esta deve ser parcialmente “revertida” 
pelo TPS. Embora esse tipo de integridade deva ser fornecido, também, para o processamento de 
transações em lote (batch), para processamento on-line, essa garantia é mais importante, em razão dos 
acessos simultâneos de diversos usuários.
 Observação
Como exemplo de falta de integridade de um sistema ou de uma 
aplicação de software, tem-se: em uma companhia aérea, o sistema de 
reserva de assento é acessado por vários operadores ao mesmo tempo. Após 
uma solicitação de lugar vazio, os dados da reserva de assento devem ser 
bloqueados até que a reserva seja efetuada; caso contrário, outro usuário 
pode ter a impressão de que o lugar ainda está livre, quando, na realidade, 
ele está sendo reservado naquele momento.
Funções de monitoramento de transações incluem detecção e resolução de impasses (deadlock) e 
podem ser inevitáveis em certos casos de dependência cruzada de dados. 
Os TPS devem ter um log (registro) de transações, para recuperação em caso de falhas. O 
processamento de transações não se limita a programas de aplicação. O sistema de arquivos (journaled 
file system) fornecido com o sistema operacional Unix AIX, da IBM, utiliza técnicas similares para manter 
a integridade dos arquivos do sistema, incluindo um diário.
22
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
 Saiba mais
Vale a pena estudar o conceito de deadlock em banco de dados, que é a 
situação em que duas ou mais ações ou transações competem no acesso a 
um banco de dados para atualização e cada uma delas fica esperando que 
a outra termine, o que nunca acontece. 
Esse conceito se encontra em vários livros sobre banco de dados 
existentes nas bibliotecas, por exemplo: 
KROENKE, D. M. Banco de dados: fundamentos, projetos e implementação. 
Rio de Janeiro: LTC, 1998.
Sistemas ou aplicações TPS apresentam as características descritas a seguir. 
• Resposta rápida (rapid response): alto desempenho com tempo de resposta rápido é uma 
característica essencial. As empresas não podem ter clientes à espera de um TPS para responder 
às suas transações. O tempo de resposta a partir da entrada da transação, para processá-la e gerar 
a saída, deve ser de alguns segundos ou menos. 
• Confiablidade (reliability): muitas organizações dependem fortemente de seus sistemas 
TPS – um colapso irá interromper as operações ou mesmo parar o negócio. Para um TPS 
ser considerado eficaz, sua taxa de falha deve ser muito baixa. Se um TPS falhar, então a 
recuperação rápida e precisa deverá ser permitida. Isso é feito com procedimentos de backup 
e recuperação do essencial. 
• Inflexibilidade (inflexibility): para um sistema TPS, cada transação deve ser processada da mesma 
maneira, independentemente do usuário, do cliente ou da hora do dia. Se um TPS for flexível, 
haverá muitas oportunidades para a execução de operações não padrão. Por exemplo, uma linha 
aérea comercial precisa, constantemente, aceitar reservas de passagens aéreas a partir de uma 
variedade de agentes de viagens; aceitar dados diferentes de operações distintas de agentes seria 
um problema. 
• Processamento controlado (controlled processing): o processamento de um TPS deve dar 
suporte às operações de uma organização. Por exemplo, caso uma organização atribua funções 
e responsabilidades aos funcionários em particular, o TPS deve aplicar e manter essa exigência 
(segurança). 
• Armazenamento e recuperação de informações nos TPS: armazenar e recuperar informações em 
um TPS deve ser eficiente e eficaz. 
23
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Os dados são armazenados em bases de dados, e o sistema deve ser projetado corretamente, com 
procedimentos de backup e recuperação. O armazenamento e a recuperação dos dados devem ser 
precisos, uma vez que estes são usados muitas vezes ao longo do dia.
Um banco de dados é uma coleção de dados bem-organizados, que armazena os registros contábeis 
e operacionais na base de dados; é sempre o protetor de dados delicados das organizações, permitindo, 
geralmente, uma visão restrita quanto aos seus acessos; é projetado dentro de determinadas estruturas 
de BDs existentes comercialmente: estrutura hierárquica, estrutura em rede, estrutura relacional e 
estrutura orientada a objetos.
Como as organizações empresariais têm-se tornado muito dependentes dos aplicativos ou sistemas 
do tipo TPS, um colapso nesses sistemas pode parar rotinas regulares do negócio e, assim, interromper o 
seu funcionamento por um determinado período de tempo. A fim de evitar perda de dados e minimizar 
as interrupções quando um TPS falha, um bom backup e procedimentos de recuperação são colocados 
em uso. O processo de recuperação pode reconstruir o sistema ou a aplicação quando ocorre uma falha.
2.1.2 Sistemas de Informações de Gestão (SIG) ou Management Information Systems 
(MIS)
São sistemas ou aplicativos que fornecem as informações necessárias para gerenciar efetivamente 
as organizações. Esses sistemas envolvem três recursos primários: tecnologia, informações e pessoas.
É importante reconhecer que, embora todos os três recursos sejam componentes-chave, quando se 
estudam SIGs ou MIS, o recurso mais importante são as pessoas envolvidas. 
De acordo com Figueiredo (2011), SIGs englobam o estudo dos sistemas de informação nas empresas 
e na administração; dão suporte ao nível gerencial por meio de relatórios, processos correntes e históricos 
por meio de acessos on-line orientados a eventos internos, apoiando o planejamento, o controle e a 
decisão; e dependem dos aplicativos TPS para aquisição de dados, resumindo e apresentando operações 
e dados básicos periodicamente.
Os SIGs são distintos dos TPS, já que estes são usados para analisar outros sistemas de informação 
aplicados às atividades operacionais da organização. Academicamente, o termo é usado com frequência 
para referir-se ao grupo de métodos de gestão de informação ligado à automação ou ao apoio à tomada 
de decisão humana, por exemplo, Sistemas de Apoio à Decisão (SADs), ou sistemas especialistas.
A sigla SIG (ou MIS) surgiu para descrever esses tipos de aplicação de software, que foram 
desenvolvidos para fornecer, aos gestores, informações sobre vendas, estoques e outros dados que 
ajudam na gestão da empresa. 
A sigla SIG, hoje, é utilizada amplamente em umasérie de contextos e inclui, entre outros:
• Sistemas de Apoio a Decisão (SADs); 
24
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
• Recursos e aplicações de gestão de pessoas;
• Sistemas Integrados de Gestão Empresarial (ERP – Enterprise Resource Planning);
• Gestão do Desempenho Empresarial (EPM – Enterprise Performance Management);
• Gerenciamento da Cadeia de Suprimentos (SCM – Supply Chain Management);
• Gestão do Relacionamento com o Clientes (CRM – Customer Relationship Management);
• Gestão de projetos e aplicações de recuperação de banco de dados. 
Os SIGs ou MIS são sistemas planejados de coleta, processamento, armazenamento e divulgação 
de dados na forma de informações necessárias para apoiar as pessoas a desempenharem as funções de 
gestão. 
A sigla MIS e a expressão sistema de informação, muitas vezes, são confundidos. Sistemas de 
informação incluem aqueles que não se destinam à tomada de decisão. A área de estudo chamada MIS 
refere-se, em sentido restrito, à gestão de tecnologia da informação. Essa área de estudo não deve ser 
confundida com ciência da computação. Gestão de serviços é uma disciplina profissional focada; MIS 
tem, também, algumas diferenças em relação a ERP, que incorpora elementos não necessariamente 
focados na decisão.
Um sistema MIS de sucesso deve dar suporte a um plano de negócios de cinco anos ou equivalente. 
Deve fornecer relatórios baseados em análise de desempenho em áreas críticas desse plano, com 
feedback constante, que permita o controle de cada aspecto do negócio, incluindo o recrutamento e os 
regimes de treinamento. Com efeito, o MIS deve não apenas indicar como está o andamento do negócio, 
mas também por que este não vai tão bem como planejado, quando for o caso.
Alguns benefícios que podem ser apresentados para diferentes tipos de sistemas de gestão da 
informação:
• a empresa é capaz de destacar suas forças e fraquezas, em razão da presença de relatórios de 
receita, registros de desempenho do empregado etc.;
• a identificação desses aspectos pode ajudar a empresa a melhorar seus processos de negócios e 
operações;
• a disponibilidade dos dados do cliente e o feedback podem ajudar a empresa a alinhar seus 
processos de negócio com as necessidades dos clientes;
• a gestão eficaz de dados de clientes pode ajudar a empresa a realizar atividades de marketing 
direto e a fazer promoções diferenciadas;
25
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
• a informação é considerada um ativo importante para qualquer empresa no mundo moderno 
competitivo;
• as tendências de compra do consumidor e os comportamentos deste podem ser previstos pela 
análise dos relatórios de vendas e das receitas de cada região de operação da empresa. 
 Observação
Exemplo de sistemas SIG ou MIS:
ERP – Enterprise Resource Planning ou Sistemas Integrados de Gestão 
Empresarial: planejamento de recursos empresariais que fornece uma 
interface de usuário para toda a organização, a fim de gerenciar processos 
de negócios. Isso pode incluir gerenciamento de projetos, contabilidade, 
pessoal, produção e distribuição.
SCM – Supply Chain Management ou Gerenciamento da Cadeia de 
Suprimentos: sistemas que permitem uma gestão mais eficiente da cadeia de 
abastecimento, integrando os elos de uma cadeia de suprimentos. Isso pode 
incluir fornecedores, fabricantes, atacadistas, varejistas e consumidores finais.
CRM – Customer Relationship Management ou Gestão do 
Relacionamento com Clientes: sistemas de apoio às empresas na gerência 
e nos relacionamentos com clientes potenciais e atuais, e com parceiros de 
negócios em marketing, vendas e serviços.
KMS – Knowledge Management Systems ou Sistemas de Gestão de 
Conhecimento: ajudam as organizações a facilitarem a recolha, o registro, 
a organização, a recuperação e a disseminação do conhecimento. Isso pode 
incluir documentos, registros contábeis, dados sem registro e procedimentos, 
práticas e habilidades. 
2.1.3 Sistemas de Apoio à Decisão (SAD) ou Decision Support Systems (DSS)
Referem-se, simplesmente, a um modelo genérico de tomada de decisão que analisa um grande 
número de variáveis para que seja possível o posicionamento quanto a uma determinada questão.
Decisão é uma escolha dentre as alternativas existentes por meio de estimativas dos pesos destas. Apoio 
à decisão significa auxiliar nessa escolha, gerando tais estimativas evolução ou comparação e escolha. 
As expressões sistema de apoio à decisão ou aplicação de apoio à decisão têm sido utilizados de 
diferentes formas (após a década de 1980) e têm recebido diferentes definições, de acordo com o ponto 
de vista de cada autor.
26
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
Finlay (1994) e outros autores definem o SAD, de modo geral, como um sistema computacional 
que auxilia no processo de tomada de decisão. Turban (1995) define-o mais especificamente como um 
sistema de informação interativo, flexível e adaptável, especialmente desenvolvido para apoiar a solução 
de um problema gerencial não estruturado, a fim de aperfeiçoar a tomada de decisão, que utiliza dados, 
provê interface amigável e permite ao tomador de decisão ter sua própria percepção.
Para Keen (1980), um SAD concilia os recursos intelectuais individuais com a capacidade do 
computador de melhorar a qualidade da decisão. Ainda de acordo com o autor, os sistemas do tipo SAD 
são sistemas computacionais que apoiam os gerentes tomadores de decisão e que são direcionados para 
os problemas semiestruturados.
Para Sprague e Carlson (1982), SADs correspondem a sistemas computacionais interativos que 
auxiliam os tomadores de decisão a utilizarem dados e modelos solucionados de problemas não 
estruturados. De acordo com Figueiredo (2011), SADs atendem, também, ao nível de gerência, ajudando 
a tomar decisões não usuais com rapidez e antecedência, a fim de solucionar problemas não definidos; 
além disso, usam informações internas, obtidas dos TPS e dos SIGs, e externas, como preços de produtos 
concorrentes etc. 
Os aplicativos do tipo SAD têm maior poder analítico que os outros sistemas, construídos em diversos 
modelos, para analisar e armazenar dados, bem como para apoiar a tomada de decisões diárias, por isso 
devem possuir uma interface de fácil acesso e atendimento ao usuário; são interativos, podendo-se 
alterar e incluir dados por meio de menus que facilitam a entrada destes e a obtenção de informações 
processadas.
Em contrapartida, Keen (1980) diz que é impossível dar uma definição precisa incluindo todas as 
facetas do aplicativo SAD. Com a ausência de uma definição de total abrangência, pode-se ter maior 
entendimento sobre SAD por meio do seu histórico:
• os conceitos de apoio à tomada de decisão envolvem duas grandes áreas de pesquisa: o estudo 
teórico das tomadas de decisões nas organizações, realizado no Instituto de Tecnologia de Carnegie, 
no fim dos anos 1950 e início dos anos 1960, e os trabalhos técnicos em sistemas computacionais 
interativos realizados pelo MIT (Instituto de Tecnologia de Massachusetts),na década de 1960;
• o conceito de SAD tornou-se uma área de pesquisa em meados dos anos 1970, sendo estudado 
intensamente antes do início dos anos 1980;
• em meados e no final dos anos 1980, iniciou-se o estudo dos sistemas de informação executiva, 
dos sistemas de apoio à decisão em grupo e dos sistemas de apoio à decisão organizacional, 
envolvendo um único usuário e o SAD orientado à modelagem;
• no início dos anos 1990,começaram a surgir, a partir do SAD, os conceitos de data warehouse 
(DW) e processamento analítico on-line (OLAP). Com a virada do milênio se aproximando, novas 
aplicações analíticas baseadas na web foram introduzidas. 
27
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
Considera-se que um aplicativo do tipo SAD pertence a um ambiente com fundamentos 
multidisciplinares, incluindo pesquisas de banco de dados, inteligência artificial, interação homem-
máquina, métodos de simulação, engenharia de software e telecomunicações, mas não se restringindo 
a estas. 
 Observação
Os sistemas SAD também têm uma conexão com o paradigma de 
interface do tipo hipertexto. 
O Prosecutor’s Management Information System (PROMIS), da 
Universidade de Vermont, para tomada de decisões médicas, e o sistema de 
Hipertexto ZOG/KMS (sistema ZOG para KMS – Knowledge Management 
System), da Universidade de Carnegie, para tomada de decisões militares e 
comerciais, eram sistemas de apoio à decisão com maior aprofundamento 
de pesquisa em interface com o usuário. 
Os autores possuem propostas diversas de classificação para sistemas ou aplicativos do tipo SAD. 
Seguem alguns critérios de classificação desses aplicativos. 
• Relacionamento com o usuário – pode-se diferenciar o SAD em passivo, ativo e cooperativo, de 
modo que:
— um SAD passivo é um sistema que auxilia o processo de tomada de decisão, mas não traz, 
explicitamente, sugestões ou soluções;
— um SAD ativo pode trazer sugestões ou soluções para o problema apresentado;
— um SAD cooperativo apresenta, para o tomador de decisão (que atua como um conselheiro), as 
opções de modificar, completar ou refinar as sugestões apresentadas por outros colaboradores, 
para que sejam validadas;
— o sistema realizará a validação das sugestões até que uma solução consolidada seja gerada. 
• Modo de assistência ou apoio – nesse critério, pode-se classificar o SAD como:
— model-driven, que enfatiza acesso e manipulação estatísticos, financeiros, otimizados ou em 
modelo de simulação; utiliza-se de dados e parâmetros providos pelos usuários para assistir 
a tomada de decisão, analisando uma situação; não há necessidade de um grande volume de 
dados;
— communication-driven, que auxilia mais de uma pessoa trabalhando em tarefas compartilhadas;
28
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
— data-driven, que gerencia, recupera e manipula informações não estruturadas em uma 
variedade de formatos de armazenamento; 
— knowledge-driven, que provê especialização na solução do problema por meio de conhecimentos 
armazenados, como fatos, regras, procedimentos ou estruturas similares;
— tradeoff-driven, que é um sistema de apoio à decisão (possivelmente colaborativo) que provê 
a tomada de decisão envolvendo tradeoffs entre diferentes vantagens e desvantagens, usando 
o conhecimento armazenado. 
• Escopo do aplicativo ou sistema – podem-se classificar os SAD como:
— empresarial, que é ligado a um grande data-warehouse e a servidores de muitos gerentes em 
uma organização; 
— desktop, um sistema pequeno que roda para um gerente em um personal computer (PC), ou 
computador pessoal.
Com relação à arquitetura dos sistemas de informação SAD, os vários autores identificam diversos 
componentes. 
Haag e Donovan (2000) identificam três componentes fundamentais de um SAD:
• o Sistema Gerenciador de Banco de Dados (SGBD) ou Data Base Management System (DBMS) 
armazena a informação (que pode ser um repositório organizacional tradicional ou remoto, com 
a utilização da internet para acesso, ou personalizado para cada usuário;
• o Sistema Gerenciador de Modelagem Básica (SGMB) ou Basic Modeling Management System 
(BMMS) faz a representação de eventos, fatos ou situações usando vários tipos de modelos, por 
exemplo: modelos de otimização e modelos goal-seeking;
• o Sistema de Geração de Diálogo e Gerenciamento (SGDG) ou Dialog Generation Management 
System (DGMS), ou Gerenciador de Interface, melhora a interatividade do usuário com o sistema. 
Power (2000) afirma que se tem estudado a construção de um SAD com quatro componentes: 
interface com o usuário; banco de dados; modelagem e ferramentas analíticas; arquitetura e rede de 
trabalho de SAD.
Hättenschwiler (1999) identifica cinco componentes de um SAD:
• usuários com diferentes regras de negócio e funções no processo de tomada de decisão;
• contexto de decisão específico e definido;
• sistema objetivo descrevendo as preferências principais;
29
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
• base de conhecimento composta de informações, programas administrativos e sistemas geradores 
de relatórios;
• trabalho de preparação do ambiente, análise e documentação das alternativas de decisão.
Marakas (1999) propõe uma arquitetura generalizada que também é composta por cinco partes 
distintas:
• um sistema gerenciador de banco de dados;
• um sistema gerenciador de modelagem;
• uma engenharia de conhecimento;
• uma interface com o usuário;
• o usuário.
A figura a seguir mostra a visão de Marakas (1999), com as cinco partes distintas da arquitetura de 
um SAD.
Interface 
do usuário
Engenharia do 
conhecimento
Sistema 
Gerenciador 
de BD (SGBD)
Sistema 
Gerenciador de 
Modelagem (SGM)
Usuário
Figura 2 – Arquitetura de um SAD
 Observação
Dentre os mais famosos aplicativos do tipo SAD, podem-se citar o 
Sistema de Apoio à Decisão para Diagnósticos Médicos (SADDM), bem como 
a aplicação de sistemas SAD à área de produção agrícola, comercialização 
e sustentabilidade do desenvolvimento agrícola.
O pacote de tomada de decisão para produção agrícola (DSSAT4 – 
Decision Support Systems AT4), por exemplo, que desenvolveu e financiou 
o USAID (United States Agency for International Development) durante os 
anos 1980 e 1990, tem aumentado a qualidade em sistemas de produção 
agrícola em todo o mundo, facilitando a tomada de decisão em fazendas. 
Outro exemplo é o sistema nacional de ferrovias do Canadá, com testes nos 
equipamentos utilizando o SAD.
30
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
Um problema encontrado em qualquer ferrovia está no desencaixe ou 
em defeitos nos trilhos que podem causar centenas de descarrilamentos 
por ano. Com um SAD, verificou-se a redução dos incidentes de 
descarrilamentos, no mesmo período em que outras companhias tiveram 
um expressivo aumento.
De acordo com Vieira (2011):
Os sistemas SAD têm muitas aplicações que ainda podem ser descobertas, 
portanto podem ser utilizados em qualquer campo de uma organização, 
como para auxiliar a tomada de decisão em estoques ou decidir qual fatia de 
mercado uma linha de produtos deve seguir (VIEIRA, 2011, p. 23). 
2.1.4 Sistemas de Informação Executiva (SIE) ou Executive Information Systems (EIS)
Tarata-se de um tipo de sistema de informações gerenciais destinado a facilitar e apoiar a informação 
e a tomada de decisão dos altos executivos, proporcionando acesso fácil a informações internas e 
externas relevantes, para atingir os objetivos estratégicos da organização.
São comumente considerados como uma forma especializada de SAD, todavia a ênfase dos EIS está 
em apresentar os resultados em telas gráficas e fáceis de usar, como interfaces de usuário. O sistema 
oferece relatórios sofisticados e tem capacidade drilldown.
Em geral, os EIS estão em toda a empresa, nos SADs que ajudam os executivos de alto nível a analisar 
e comparar tendências, e dão destaque a variáveis importantes para que estes possam monitorar o 
desempenho e identificar oportunidades e problemas. Os EIS e as tecnologias de armazenamento de 
dados estão convergindo no mercado, e, nos últimos anos, o termo perdeu popularidade para o Business 
Intelligence (BI), com as subáreas de relatórios analíticos e painéis digitais (dashboards).
Conforme Figueiredo (2011), os SIE ou EIS atendem ao nível gerencial sênior, que tem pouca ou 
nenhuma experiência com computadores; servem para ajudar a tomar decisões não rotineiras que exigem 
bom senso, avaliação e percepção; e criam um ambiente generalizado de computação e comunicação, 
em vez de aplicações fixas e capacidades específicas. Projetados para incorporar dados externos, como 
leis e novos concorrentes, também adquirem informações dos SIGs e dos SADs, a fim de obter dados 
resumidos e úteis aos executivos, não só sob a forma de textos, mas também como gráficos projetados 
para solucionar problemas específicos que se alteram seguidamente, por meio de modelos menos 
analíticos. São formados por estações de trabalho, menus gráficos, dados históricos e de concorrentes e 
bancos de dados externos, sendo de fácil comunicação e interface amigável.
A literatura mostra que os SIEs possuem uma série de vantagens, mas apresentam, também, um 
conjunto de desvantagens.
• Vantagens: fáceis de serem usados por altos executivos; não exigem muita experiência com o 
computador; fornecem informações resumidas para a empresa, no tempo necessário; a informação 
31
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
que é fornecida é mais bem-compreendida; possuem filtros de dados para a gestão; melhoram as 
informações de rastreamento; e oferecem eficiência aos tomadores de decisão.
• Desvantagens: funcionalidade limitada pelo projeto; sobrecarga de informações para alguns 
gestores; benefícios difíceis de quantificar; altos custos de implementação; podem ficar lentos, 
grandes e difíceis de gerir; precisam de um processo interno de gerenciamento de dados; e podem 
levar a dados menos confiáveis e menos seguros.
 Observação
Os SIE ou IES não serão mais vinculados a sistemas de computador 
de grande porte (mainframe). Essa tendência permite aos executivos 
evitar a necessidade do aprendizado de diferentes sistemas operacionais 
de computadores e reduzir substancialmente os custos de implementação 
para as empresas. 
Utilizando as aplicações nessa tendência, os executivos também vão 
eliminar a necessidade de aprender uma nova linguagem para utilizar um 
pacote de SIE. Os sistemas de informação, além de fornecer um suporte às 
necessidades dos altos executivos, também vão atender às necessidades de 
informação dos gerentes de nível médio. Serão diversificados, em virtude 
da integração de novas aplicações em potencial e tecnologia nos sistemas, 
tais como a incorporação de inteligência artificial (AI) e a integração de 
características multimídia e tecnologia Integrated Services for Digital 
Network (ISDN) em um SIE.
2.1.5 SE (Sistemas Especialistas) ou ES (Expert Systems)
Um aplicativo de software ou sistema de informação do tipo SE pode ser entendido como um 
programa de computador inteligente que usa conhecimentos e procedimentos de inferência para resolver 
problemas que têm um grau de dificuldade suficiente para necessitar de especialistas no assunto ou na 
matéria para que possam ser resolvidos:
Em outras palavras, são um programa ou conjunto de programas de computador que busca emular 
(e não simular) a capacidade de decisão de um especialista humano (nesse contexto, emular significa 
agir em tudo como um humano) (BARR; FEIGENBAUM, 1981). 
Engelmore e Feigenbaum (1993) afirmam que os SEs são programas de computador derivados 
de um ramo da pesquisa em computação chamado Inteligência Artificial (IA). O objetivo científico 
dessa área é entender tal inteligência por meio da construção de programas de computador que 
exibem um comportamento inteligente); preocupa-se com os conceitos e métodos de inferência 
simbólicos – ou raciocínio – usados por um computador e com a forma pela qual o conhecimento 
utilizado para fazer essas inferências será representado no interior da máquina.
32
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
Unidade I
A inteligência abrange muitas habilidades cognitivas, incluindo a capacidade de resolver 
problemas, bem como de aprender e entender a linguagem. O campo de IA aborda todas essas, 
mas a maioria dos progressos na área, até o momento, tem sido feita em resolução de problemas 
– conceitos e métodos para a construção de programas que raciocinam sobre problemas, em vez 
de calcular soluções. 
Assim, de modo potencial, todo e qualquer problema que possa ser resolvido usando um programa 
de computador e que envolva capacidade de tomar decisões pode ser solucionado por meio de um ES. 
Diz-se de um modo potencial porque nem sempre isso acontece. 
Como exemplo, um ES pode ser empregado para realizar diagnósticos sobre os sistemas (mecânicos, 
elétricos etc.) de um automóvel. Contudo, é praticamente impossível implementar um ES que aja do 
mesmo modo que um ser humano numa situação tão frequente como ultrapassar um carro e, de repente, 
vir um carro pela frente em sentido contrário. 
O mesmo ser humano pode ter reações diferentes. Com isso, pretende-se dizer que os ES 
funcionam bem, mas apenas num domínio restrito. Ambas as situações referidas retratam momentos 
que exigem tomadas de decisões, contudo a segunda não é passível de ser resolvida usando-se um 
sistema desse tipo. 
Um SE ou ES define-se em duas palavras: 
• sistema: conjunto de elementos, materiais ou ideais entre os quais se pode encontrar ou definir 
alguma relação;
• especialista: pessoa que se destaca com particular interesse e cuidado em certo estudo; conhecedor, 
perito.
Os SEs são uma classe de programas de computador desenvolvida por pesquisadores de IA 
durante os anos 1970 e aplicada comercialmente durante os anos 1980. Em síntese, são programas 
constituídos por uma série de regras que analisam informações (normalmente fornecidas pelo 
usuário do sistema) sobre uma classe específica de problema (ou domínio de problema); são 
desenvolvidos a partir da necessidade de se processar informações não numéricas e capazes de 
apresentar conclusões sobre determinado tema, desde que devidamente orientados e “alimentados”; 
são uma forma de sistema baseada no conhecimento especialmente projetado para emular a 
especialização humana de algum domínio específico; possuem uma base de conhecimento 
formada de fatos e regras sobre o domínio, tal como um especialista humano faria, e devem ser 
capazes de oferecer sugestões e conselhos.
Muitas são as vantagens que apresentam, dentre as quais se destacam: 
• disponibilidade: o conhecimento especializado estará disponível em qualquer máquina na qual 
possa ser instalado um ES; por meio da disseminação, um ES torna-se uma espécie de massificação 
de conhecimento;
33
AD
S 
- 
Re
vi
sã
o:
 V
al
ér
ia
/J
ul
ia
na
 -
 D
ia
gr
am
aç
ão
: F
ab
io
 -
 2
5/
04
/2
01
4
ENGENHARIA DE SOFTWARE I
• custo reduzido: por uma quantia irrisória ou gratuita (caso o acesso ao sistema ou o uso deste seja 
permitido), qualquer pessoa pode ter acesso a conhecimentos especializados sobre determinada 
área ou certo assunto;
• perigo reduzido: um ES pode ser usado para operar uma máquina em ambientes hostis ao homem; 
o programa que controla