Livro-Texto - Unidade I

Engenharia de Software I
Autor: Prof. Ivanir Costa

Colaboradores: Prof. Luciano Soares de Souza
Prof. Marcelo Nogueira
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.
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
© 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.
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
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
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
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.
7
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.
8
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.
9
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.
Conjunto organizado de conhecimentos relativos a um determinado objeto,
Ciência especialmente, os obtidos mediante a observação, a experiência dos fatos e um
método próprio.
Processamento
de dados (TI na Tratamento dos dados por meio de máquinas, com o fim de obter resultados da
atualidade) informação representada pelos dados.
Arte de aplicar conhecimentos científicos e empíricos, bem como certas

Engenharia 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).
10
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 exercitar processos (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.
11
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;
12
• 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”.
13
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;
14
— 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.
15
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.
16
• 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 produto de 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.
17
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).
18
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.
19
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 envolver várias alterações (como uma conta de débito e outra de crédito),
é uma transação única.
20
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.
21
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.
22
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 uma série de contextos e inclui, entre outros:
• Sistemas de Apoio a Decisão (SADs);
23
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;
24
• 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.
25
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.
26
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;
27
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;
28
• 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.
Engenharia do
Usuário conhecimento
Sistema
Gerenciador de
Modelagem (SGM)
Sistema
Gerenciador
Interface de BD (SGBD)
do 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.
29
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 drill down.
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
30
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.
31
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;
32
• 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 o sistema de navegação implementado no veículo de exploração enviado
a Marte, por exemplo, pode ser um ES;
• imortalidade: o conhecimento de um ES tem uma duração indefinida, o que pode ultrapassar

muito a disponibilidade de conhecimento que qualquer humano possa proporcionar;
• múltiplos conhecimentos especializados: uma máquina está, geralmente, em funcionamento

24 horas por dia, o que implica que pode trabalhar num problema específico durante todo
esse período, além de ser possível concentrar numa só máquina os conhecimentos de vários
especialistas;
• aumento do nível de confiança: o uso dos ES pode reforçar a ideia de que foi tomada a decisão
correta, oferecendo uma segunda opinião, ou “desempatando”, no caso de vários especialistas
estarem em desacordo quanto a um assunto;
• explicação: em qualquer altura, um ES está disponível para descrever, explicitamente, como se

chegou a uma determinada conclusão;
• resposta rápida: uma vez que corre numa máquina, para situações em que o tempo é um fator de
máxima importância, um ES pode ser, efetivamente, mais rápido que um humano.
Uma vez que o conhecimento de um perito humano tem de ser posto numa forma explícita para
poder ser introduzido no ES, o desenvolvimento deste traz vantagens indiretas, porque o conhecimento
(estando explícito) pode ser examinado no que se refere a consistência, coerência etc.
Saiba mais
Leia o seguinte trabalho, que apresenta a base de conhecimento dos

SEs, bem como discute e mostra como um sistema especialista funciona e
quais são seus embasamentos para tal:
BARRETO, L. R.; PREZOTO, M. G. Introdução a sistemas especialistas

2010. Monografia para conclusão de matéria (Mestrado em Tecnologia para
Sistemas e Fenômenos Complexos) – Faculdade de Tecnologia, Universidade
Estadual de Campinas, Campinas, 2010. Disponível em: <http://www.
ft.unicamp.br/liag/wp/monografias/monografias/2010_IA_FT_UNICAMP_
sistemasEspecialistas.pdf>. Acesso em: 15 abr. 2014.
33
Unidade I
2.1.6 Sistemas de Automação de Escritório (SAE) ou Office Automation Systems (OAS)
De acordo com Perottoni et al. (2001), até a década de 1970, todas as atividades efetuadas nos
escritórios das empresas eram realizadas de forma manual, tornando difícil obter-se uma posição
atualizada das tarefas realizadas, bem como a coleta de dados para reunião sobre determinado assunto
em um dado momento.
Como não existia um modo informatizado de arquivar os relatórios gerados pelas aplicações da
época, formavam-se pilhas de papéis nas mesas dos funcionários, gerando altos custos com material de
escritório, além de desperdícios e retrabalho.
No início dos anos 1970, segundo Turban, McLean e Wetherbe (2004), foram desenvolvidas aplicações
com o objetivo de automatizar as operações realizadas nos escritórios, melhorando e agilizando as
atividades ali desempenhadas. Esses sistemas de automação de escritório tinham como propósito
aumentar a produtividade, reduzir custos e oferecer melhores resultados. Conforme Laudon e Laudon
(2004), disponibilizam diversas funções, tais como processadores de textos, agendas eletrônicas, editores
de imagens e gerenciamento de diversos tipos de projetos.
Após a automação das atividades realizadas nos escritórios, a organização das informações tornou-
se mais rápida e mais confiável. O foco passou para a busca e comparação de diversas alternativas do
mesmo problema, auxiliando o tomador de decisões.
Dentre os diversos conceitos e definições existentes, pode-se afirmar que automação de escritório
envolve o uso de equipamentos de informática e softwares para criar, coletar, armazenar, manipular
e retransmitir digitalmente informações necessárias para a realização de tarefas e o cumprimento de
objetivos em um escritório ou local de trabalho.
Armazenamento de dados brutos, transferências eletrônicas e gerenciamento eletrônico de

informações de negócios consistem nas atividades básicas de um SAE, que ajuda a otimizar e automatizar
procedimentos administrativos existentes.
Pode-se considerar que a espinha dorsal da automação de escritório é a existência de uma rede
de computadores, a qual permite que os usuários transmitam dados, correspondências e imagens,
com ou sem voz. Todas as tarefas realizadas em um escritório, (inclusive ditados; digitação;
preenchimento de formulários; cópias; transmissão e recepção de fax e telex; gerenciamento de
microfilmes e registros; e uso de telefone, PABX e correio eletrônico administrativo) recaem nessa
categoria.
A expressão automação de escritório era popular nos anos 1970 e 1980, antes que o computador
pessoal entrasse em cena. A automação com sistemas de informação, na atualidade, ajuda nos serviços
de escritório, tais como preparação e comunicação da correspondência.
34
Dentre os diversos SAES, podemos citar:
• editores de texto;
• sistema de correio eletrônico;
• grupos de notícias;
• máquinas de fax;
• correio de voz;
• sistemas multimídia;
• sistemas de informação distribuídos;
• videoconferência.
Como tendência, os sistemas de automação de escritórios estão cada vez mais integrados à internet
para compartilhamento de informações. Todavia, ainda existem diversos obstáculos para a difusão dos
aplicativos do tipo SAE, tais como dificuldade de integrar componentes (diferentes padrões) e custo de
armazenar informações não usuais (imagens, som, vídeos).
Observação
Como exemplos do estágio atual da automação de escritório, podem-se

citar os conceitos de prédio inteligente e escritório inteligente.
Foi a partir da automação de escritório que se tornou possível fazer

tanto o prédio quanto o escritório (e até uma casa) “inteligentes”, isto é, ter
sistemas de informação controlando toda a sua infraestrutura.
Dentro de um “prédio inteligente” e de um “escritório inteligente”,

pode-se ter, hoje, uma sofisticada Central de Telefonia Inteligente (CTI),
controlando por computador todos os telefones da empresa, e, ainda,
integrada com o sistema de administração de relacionamento com clientes,
e assim por diante.
2.2 Problemas com prazo, planejamento e custos
Quando se trabalha com conceitos de prazo e custos, trata-se da disciplina de Gerenciamento de

Projetos. Na engenharia de software, esses são projetos de desenvolvimento e manutenção de software.
Todavia, há outro fato característico envolvido, que é a ênfase nos aspectos relativos à qualidade de
projetos, tocando em pontos como prazo, custo e qualidade de produto.
35
Unidade I
Atualmente, em razão do aumento constante da complexidade dos sistemas de informação, o

processo de desenvolvimento requer competência e habilidade maiores da equipe de projetos, tendo em
vista que tais sistemas são essenciais para o negócio.
Uma aplicação de software possui forte integração de diversos elementos, e sua característica de
múltipla funcionalidade exige a interação de sistemas de bancos de dados, uso de redes de comunicação,
segurança no acesso indevido aos dados e diversas outras habilidades que não eram exigidas nos sistemas
desenvolvidos num passado recente. Sob esse prisma, os aspectos do gerenciamento do projeto, bem
como o controle de prazos e de custos são peças-chave para o sucesso de um projeto de sistemas de
software.
De acordo com o PMBOK (2008):
Gerenciamento de projetos é a aplicação de conhecimentos, habilidades,

ferramentas e técnicas para projetar atividades, de forma a atender ou
exceder as expectativas dos stakeholders concernentes ao produto ou
serviço gerado pelo projeto (PMBOK, 2008, p. 11).
Atender às expectativas dos stakeholders ou excedê-las, relativamente ao projeto, invariavelmente,

implica atender ao escopo, ao tempo, ao custo e à qualidade, bem como a requisitos de projeto e a
expectativas que não tinham sido identificadas na sua definição.
Ainda de acordo com o PMBOK (2008), para atender a essas metas, é necessário que a missão do
projeto esteja definida, isto é, devem-se definir os aspectos relativos a:
• estratégia: que problema deve ser solucionado;
• pessoas: a quem o projeto se destina;
• processos: como o projeto deve ser elaborado para atingir seus objetivos.
Conforme Trevisani et al. (2004):
A gerência deve formar uma equipe onde todos os seus membros entendam
o relacionamento de suas atividades com a dos outros membros (fluxo); e
garantir que todas as pessoas envolvidas no projeto tenham visão abrangente
do projeto, de modo que todas as atividades previstas sejam executadas
conforme o cronograma estabelecido. Também é necessário garantir que
as pessoas envolvidas sejam capazes de ter a mesma visão de todos os
processos que estão sendo desenvolvidos, ou seja, garantir a visibilidade do
projeto (TREVISANI et al, 2004).
Uma das maiores dificuldades em projetos de software para os gerentes durante o planejamento
de um projeto são as estimativas, tanto do prazo quanto dos custos. Essas estimativas devem
36
se aproximar ao máximo da realidade. Uma estimativa maior do que o cliente espera pode
causar perda de competitividade, tanto no caso de tempo quanto de custo, sobretudo, quando o
concorrente, estimando de forma correta, apresenta um projeto mais barato e em menor prazo. Já
quando a estimativa for abaixo da realmente exequível, poderá causar transtornos para a equipe,
atrasos e prejuízos. Todavia, as pesquisas demonstram que a maior parte dos projetos de software
ultrapassa o prazo estipulado e despende mais recursos do que o previsto no orçamento e na
estimativa iniciais.
Um estudo realizado nos Estados Unidos na década de 1990 identificou que as empresas americanas
gastaram 81 bilhões de dólares em projetos de software que foram cancelados em 1995, e 31% dos
projetos estudados foram cancelados antes de estarem concluídos; 53% dos projetos de software que
foram concluídos excederam em mais de 50% a sua estimativa de custo; somente 9% dos projetos,
em grandes organizações, foram entregues no tempo e no orçamento previsto. O estudo aponta o
gerenciamento de software como a razão para o sucesso ou a falha de um projeto de software (ROUILLER,
2008).
Dentre as diversas razões apontadas, Trevisani et al. (2004) listam as seguintes causas desse insucesso:
• planejamento do projeto top-down: quando a alta gerência impõe, de “cima para baixo”, o prazo
e/ou o custo que o projeto deve ter, sem discutir com a equipe;
• fechamento de contrato com o cliente sem consultar a equipe técnica: em algumas situações,
o gerente de vendas está negociando e, na ânsia de fechar o negócio rapidamente, aceita as
exigências do cliente sem ter a certeza de que estas serão passíveis de serem atendidas pela
equipe técnica;
• não entendimento exato das necessidades do cliente: é um problema notório em TI a equipe

de projeto e os usuários terem problemas de comunicação, seja por diferença de “linguagem”
(aqui não nos referimos a idiomas diferentes, mas sim a expressões e jargões específicos de cada
área), seja por ausência de conversações frequentes; o certo é que, em inúmeros casos, o produto
entregue não é o que foi especificado inicialmente, e esse fato causa retrabalhos, gastos extras e
tempo perdido.
Ao longo do tempo, a engenharia de software tem apresentado diversas alternativas e técnicas para
os processos de planejamento de um projeto de software, relativas aos problemas das estimativas e do
cumprimento dos prazos e dos custos envolvidos.
Dentre as técnicas mais conhecidas, citamos a Análise por Pontos de Função (APF), a Use Case Point
(UCP) e o Constructive Cost Model (COCOMO).
37
Unidade I
Saiba mais
Para saber mais sobre o APF, acesse o site disponível em: <http://www.
bfpug.com.br>. Trata-se de um grupo brasileiro que tem como objetivo
estimular e divulgar a utilização da métrica de pontos por função no Brasil.
Sobre a UCP, acesse o site disponível em: <http://www.rational.com>,

da empresa que pertence à IBM e é responsável pela métrica de pontos por
caso de uso da Unified Modeling Language (UML).
Sobre o COCOMO, acesse o artigo:
BOEHM, B. Cocomo® II. Los Angeles, [s.d.]. Disponível em: <http://csse.

usc.edu/csse/research/COCOMOII/cocomo_main.html>. Acesso em: 31 mar.
2014.
2.3 Qualidade de software
Quando se estuda a qualidade de software, uma das evoluções mais necessárias está em entender
que a qualidade do produto de software é importante, mas a do processo de produção de aplicações é
ainda mais.
No caso de um prato de comida, por exemplo, podemos dizer mais sobre a qualidade observando
como o prato foi preparado do que analisando o produto final, pois não conseguimos ter certeza da
higiene ou do valor nutricional apenas comendo o conteúdo do prato. Essa descoberta aconteceu, ao
longo dos anos, durante a própria evolução dos conceitos de qualidade. Modernamente, considera-se
que a qualidade do produto é conseguida de forma consistente, em longo prazo, a partir da qualidade
do processo.
A qualidade do processo pode ser explicada como o melhor caminho lógico a ser percorrido entre o
início e a conclusão de um produto que será construído. Para determiná-lo, são utilizadas as ferramentas
da qualidade total para efetuar os estudos e as simulações, e determinar a rota ideal.
Um assunto fundamental no gerenciamento da qualidade é que a condição do processo afeta

diretamente a dos produtos liberados. Isso vem dos sistemas de manufatura nos quais a qualidade do
produto está intimamente relacionada com o processo de produção. Em um sistema de manufatura
automático, o processo envolve a configuração, o set-up e a operação das máquinas. Uma vez que
essas máquinas estão operando de modo correto, a qualidade do produto acontece naturalmente. Sua
medição permite a mudança no processo até que se encontre o nível de qualidade que se quer.
A figura a seguir mostra que há uma ligação clara entre a qualidade do processo e a qualidade do
produto na manufatura, porque o processo é relativamente fácil de padronizar e monitorar. Uma vez
38
que o sistema de manufatura é calibrado, pode ser executado várias vezes e gerar produtos de alta
qualidade.
Define Asseguara a
Desenvolve qualidade do
processo produto produto
Início
Não Sim
Melhora o Produto Processo
processo ok? padronizado
Fim
Figura 3 – Processo-base da qualidade
Saiba mais
Leia o trecho indicado a seguir:
COSTA, I. et al. Qualidade em tecnologia da informação. São Paulo:

Atlas, 2013. Cap. 2. p. 24-30.
Nesse trecho, é feita uma apresentação das abordagens e dimensões da

qualidade, da qualidade de produtos e da qualidade em serviços.
De acordo com Rocha, Maldonado e Weber (2001), um produto é algo concreto, no qual se percebem
as formas, os tamanhos, as cores, a beleza, a perfeição e outras observações perceptíveis aos sentidos
humanos.
Pode-se afirmar que qualidade é o sentimento de satisfação de uma pessoa por ter conquistado
algum produto desejado. O comprador espera que o produto adquirido funcione por muito tempo e que
não apresente problema durante sua vida útil.
A qualidade de um produto ou serviço pode ser vista de duas formas: com o olhar do produtor e o
do cliente.
39
Unidade I
Do ponto de vista do produtor, a qualidade se associa à concepção e à fabricação de um

produto que vá ao encontro das necessidades do cliente. Do ponto de vista do cliente, a qualidade
está associada ao valor e à utilidade reconhecida ao produto, estando, em alguns casos, ligada ao
preço.
Também do ponto de vista do cliente, a qualidade de um produto pode ser vista por diversas
características, por exemplo, sua dimensão, sua cor, sua durabilidade, seu design, as funções que
desempenha etc. Assim, é um conceito multidimensional.
A qualidade tem muitas dimensões e é, por isso, mais difícil definir qualidade de produto.
Do ponto de vista da empresa, contudo, se o objetivo for oferecer produtos e serviços de

qualidade, o conceito não poderá ser deixado ao acaso, devendo ser definido de forma clara e
objetiva. Isso significa que a empresa deve apurar quais são as necessidades dos clientes e, de
acordo com estas, definir os requisitos de qualidade do produto, que são definidos conforme
variáveis como comprimento, largura, altura, peso, cor, resistência, durabilidade, funções
desempenhadas, tempo de entrega, simpatia de quem atende ao cliente, rapidez do atendimento,
eficácia do serviço etc.
Cada requisito é, em seguida, quantificado, a fim de que a qualidade possa ser interpretada por
todos (empresa, trabalhadores, gestores e clientes) exatamente da mesma maneira. Os produtos
devem exibir esses requisitos, a publicidade se faz em torno deles, o controle de qualidade visa
a assegurar que estejam presentes no produto, a medição da satisfação se faz para apurar em
que medida esses requisitos estão presentes e em que medida vão realmente ao encontro das
necessidades.
De acordo com Shiba (1997), citando a norma ISO/IEC 9126, devem-se considerar alguns aspectos
para se obter a qualidade do produto, conforme apresentado no quadro a seguir.
Quadro 2 – Aspectos da qualidade de produto
Aspecto Descrição
Funcionalidade Identifica os procedimentos de funcionamento de um produto.

O produto não deve apresentar problemas junto aos clientes, caso
Confiabilidade contrário, o fornecedor deverá resolvê-los.
Deve-se testar o produto o máximo possível e constatar o
Usabilidade resultado de seu uso como satisfatório.
Eficiência Comprovação, pelo cliente, de sua satisfação com o produto.
Manutenibilidade Garantia de correções dos problemas.
O produto muda de ambiente e a operação ocorre da mesma forma
Portabilidade satisfatória.
Fonte: adaptado de Shiba (1997).
40
Lembrete
Falconi (1992) afirma que produto ou serviço de qualidade é aquele que

atende perfeitamente, de forma confiável, acessível, segura e no tempo
certo, às necessidades dos clientes.
Resumo
Esta unidade teve como objetivo apresentar os fundamentos, conceitos

e definições da engenharia de software, partindo da visão de que a área vive
uma crise desde a década de 1960. De acordo com os autores citados no
texto, a engenharia de software surgiu exatamente para propor alternativas
à solução da tão conhecida “crise do software”.
Dentre os conceitos, apresenta-se que a Engenharia de Software é uma

disciplina do conhecimento humano que estuda os processos relacionados
ao desenvolvimento e à manutenção de softwares e, a partir desses estudos
e dessas práticas, propõe um conjunto de soluções que inclui tanto os
produtos de software quanto os processos, as metodologias e os métodos
envolvidos. Diversas opções são necessárias para essa abordagem, já que se
tem os sistemas ou as aplicações novas. Tem-se os sistemas denominados
legados, além de sistemas simples e outros de alta complexidade; sistemas
pequenos e sistemas extremamente grandes, inclusive com alta criticidade
na sua operação, e garantia de qualidade.
Qual a diferença entre produto e processos de software?
Como é mostrado no texto, um processo de software é um conjunto de

tarefas ou atividades necessárias para se entender um problema, fazer seu
mapeamento, definir as melhores soluções e, finalmente, construí-lo da
melhor forma possível, de modo que atenda às necessidades do negócio e
dos usuários finais.
Para se discutir a dimensão do produto de software, é preciso discutir

os conceitos apresentados pela norma internacional ABNT NBR ISO/
IEC 12207 (2000), que tem como objetivo normatizar todos os aspectos
envolvidos no ciclo de vida de um software. O texto debate a natureza
mutável do software, mostrando como este tem de ser visto e trabalhado
de forma diferente de outros produtos da manufatura. Todas as diferenças
apresentadas pelo produto de software são detalhadas, especialmente, pelo
autor Capovilla (1999).
41
Unidade I
Logo, são apresentados e detalhados os principais tipos de aplicações

de software ou sistemas de informação que surgiram ao longo do tempo
e atendem desde às tarefas do dia a dia das organizações até aos sistemas
mais especializados aplicados em tarefas mais específicas e mais científicas.
Um fato é certo: ainda existem diversos problemas envolvidos com o

planejamento de projetos de software, e estes são apresentados com ênfase
no prazo e nos custos dos projetos de software.
Finalmente, no encerramento da unidade, são discutidas as

características envolvidas com a qualidade de software. Um fato importante
é a diferenciação entre qualidade de um produto de software e qualidade
dos processos de desenvolvimento e manutenção de software. São
apresentados e discutidos os aspectos envolvidos na qualidade do produto,
sob o ponto de vista do autor Shiba (1997), bem como os atributos de
qualidade da norma ISO/IEC 9126, citada por esse autor.
Exercícios
Questão 1. De acordo com Paula Filho (2003), muitas pessoas, inclusive dirigentes de empresas,
percebem o computador como um problema, e não como solução. Muitos aceitam que os sistemas de
informática “são assim mesmo” e que não existe solução. A partir dessa colocação do autor, analise as
afirmativas que seguem:
I – A tecnologia da informação só resolve problemas quando é usada por pessoas qualificadas,

dentro de processos adequados.
II – Uma das causas de problemas com softwares decorre das suas características peculiares, e não
dos processos e produtos.
III – Os problemas dos sistemas de informática podem ser fruto de deficiência dos operadores, ou
seja, causados pelos usuários dos sistemas.
IV – Os problemas dos sistemas de informática podem ter origem em processos inadequados de

negócios.
V – Os problemas dos sistemas de informática não podem ser originados das tecnologias envolvidas,
e sim das equipes de desenvolvimento de sistemas.
Assinale a alternativa correta:
A) As afirmativas I e II estão corretas.
42
B) As afirmativas II, IV e V estão corretas.
C) As afirmativas I, III e IV estão corretas.
D) As afirmativas III e V estão corretas.
E) A afirmativa II está correta.
Resposta correta: alternativa C.
Análise das afirmativas
I) Afirmativa correta.
Justificativa: a afirmativa é encontrada em diversos autores consagrados da engenharia de software,

como Pressman (2006), Sommerville (2007) e Paula Filho (2003). Se uma empresa de TI não possuir um
processo de desenvolvimento padronizado e não contar com profissionais qualificados, as chances de se
ter graves problemas em seus softwares aumentarão substancialmente.
II) Afirmativa incorreta.
Justificativa: as características peculiares dos produtos de software reforçam as necessidades de se

terem processos efetivos, com práticas consagradas de desenvolvimento e de qualidade. Esses fatores
não são específicos para produtos de TI, e sim para todas as áreas do conhecimento humano.
III) Afirmativa correta.
Justificativa: de acordo com Paula Filho (2003), isso pode ocorrer por falta de treinamento, dificuldade
de uso do sistema ou outros fatores relacionados com pessoas.
IV) Afirmativa correta.
Justificativa: normalmente os sistemas de informação estão inseridos em procedimentos

executados por pessoas e processos automatizados por meio do computador. Dependendo do
grau de automatização desses procedimentos, os problemas apresentados são mais de pessoas do
que dos sistemas de informação.
V) Afirmativa incorreta.
Justificativa: os sistemas de informática envolvem dezenas de conhecimentos, tais como métodos

e técnicas de desenvolvimento, tecnologias de banco de dados, tecnologias de comunicação e,
principalmente, o domínio das linguagens e técnicas de programação. Como as tecnologias são
dinâmicas, exigem que as equipes estejam constantemente atualizadas e preparadas para as suas
aplicações corretas. A não preocupação com todas essas características fatalmente levará a produtos
43
Unidade I
inadequados que apresentarão defeitos ao longo de sua vida útil, provocando problemas aos seus
usuários e aos processos de negócio.
Questão 2. O autor Pressman (2006) apresenta as seguintes camadas da engenharia de software:

ferramentas, métodos, processos e foco na qualidade. Com base nessa visão do autor, analise as
afirmativas que seguem:
I – A camada de processos é a responsável por organizar a forma de trabalho dos desenvolvedores

de sistemas de informática e é voltada para o sucesso da gerência de pessoas ou equipes no processo
de desenvolvimento.
II – A camada de processos é um conjunto de atividades, produtos resultantes de suas execuções,

métodos de trabalho, pessoas participantes, ferramentas de automação e gerência, na busca de uma
entrega efetiva do software.
III – As ferramentas de automação do desenvolvimento de software procuram obter o maior

rendimento das equipes e tornar o processo eficiente.
IV – A camada de métodos aplica conjuntos de práticas consagradas no mercado envolvidas com a

forma de se executar as atividades dos processos de software.
V – As ferramentas CASE sempre dão o suporte necessário aos processos de desenvolvimento e

manutenção de software.
Assinale a alternativa correta:
A) As afirmativas I e III estão corretas.
B) As afirmativas II e V estão corretas.
C) Todas as afirmativas estão corretas.
D) As afirmativas III e IV estão corretas.
E) As afirmativas II, IV e V estão corretas.
Resolução desta questão na plataforma.
44

Livro-Texto - Unidade I

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro-Texto - Unidade I

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software I

Autor: Prof. Ivanir Costa

É orientador de mestrado do Instituto de Pesquisas Tecnológicas (IPT), da USP, e professor-titular do programa

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

1. Engenharia de software. 2. Modelos e métodos ágeis. 3.

Prof. Fábio Romeu de Carvalho

Profa. Melânia Dalla Torre

Prof. Dr. Yugo Okida

Profa. Dra. Marília Ancona-Lopez

Unip Interativa – EaD

Profa. Elisabete Brihy

Material Didático – EaD

O objetivo da disciplina Engenharia de Software I é apresentar e avaliar os conceitos básicos da

Dessa forma, a disciplina proporciona ao aluno os conhecimentos em métodos e técnicas de análise

No final, serão discutidas as práticas da engenharia de software e as envolvidas na comunicação, no

1.1 Conceitos preliminares

No livro Engenharia de Software: Fundamentos, Métodos e Padrões, de

O que caracteriza um sistema de software complexo é o fato de que ele é constituído

O embasamento científico para a engenharia de software envolve o uso de diversos modelos e

Atualmente, essas tecnologias e práticas englobam pessoas, linguagens de programação, bancos de

Engenharia de software é o estabelecimento e o emprego de sólidos princípios

Quadro 1 – Definições de informática, ciência e engenharia

Arte de aplicar conhecimentos científicos e empíricos, bem como certas

Fonte: adaptado de Paula Filho (2003).

Para saber mais sobre as diferenças existentes entre a Engenharia de

1.2 Conceitos e objetivos

A engenharia de software é composta de diversos conceitos fundamentais na área e abrange um

Fernandes (2003) afirma que a Engenharia de Software é a disciplina do conhecimento humano

A primeira definição é a de software:

• muitas pessoas não sabem dizer realmente o que é um software;

A engenharia de software está fortemente relacionada ao software, na medida em que capacita os

A camada de processos representa um conjunto de atividades, recursos e

Outro conceito bastante importante na engenharia de software é o de artefato, que, do ponto

Figura 1 – Camadas da engenharia de software

Para Pressman (2006), a camada de processos:

• é a responsável por manter as camadas de tecnologia coesas e possibilita o desenvolvimento de

• é 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

Quanto à camada de ferramentas:

• as ferramentas são responsáveis por fornecer suporte automatizado ou semiautomatizado para o

É importante ressaltar que somente as ferramentas não conseguem

1.3 Conceitos de 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

— em que os clientes e os engenheiros definem o software a ser produzido e as restrições para

— também é útil o uso de ferramentas de prototipagem para apoiar o entendimento do que o

— em que o software é desenhado e programado;

— o desenvolvimento envolve diversas tarefas, como conhecimentos e especializações diversos,

— em que o software é modificado para adaptá-lo a mudanças do cliente requisitadas pelo

Consequentemente, essas atividades genéricas de desenvolvimento podem ser organizadas de

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

De acordo com Fernandes (2003), tem-se:

O software é um produto do trabalho humano cada vez mais presente

1.4 A natureza mutável do software

• Complexidade: normalmente um produto de software tem muitas regras a serem cumpridas;

— Como o software possui diversas camadas de funcionalidades, umas chamando as outras

• Invisibilidade e intangibilidade: o software é invisível para o usuário ou cliente. O que se vê são

• Conformidade e modificabilidade: o software é a interface entre diversas entidades do meio no