Informática em foco

Prévia do material em texto

INFORMÁTICA EM FOCO
UNIASSELVI 2016
Organização
Greisse Moser Badalotti
 
Autoria
Danice Bethania de Almeida
Edemilson Bay
Elton Giovani Gretter
Grazielle Jenske
Greisse Moser Badalotti
Neli Miglioli Sabadin
Pedro Sidnei Zanchett
Reitor da Uniasselvi
Prof. Hermínio Kloch
Pró-Reitora de Ensino de Graduação a Distância
Prof.ª Francieli Stano Torres
Pró-Reitor Operacional de Graduação a Distância
Prof. Hermínio Kloch
Diagramação
Matheus Cristi
Capa
Djenifer Luana Kloehn
Revisão Final
Joice Carneiro Werlang
José Roberto Rodrigues
Propriedade do Centro Universitário Leonardo da Vinci
CENTRO UNIVERSITÁRIO
LEONARDO DA VINCI
Rodovia BR 470, Km 71, nº 1.040, Bairro Benedito
89130-000 - INDAIAL/SC
www.uniasselvi.com.br
Informática em Foco
Ficha catalográfica 
Elaborada na fonte pela Biblioteca Dante Alighieri – UNIASSELVI – Indaial.
004.7
I43i Badalotti; Greisse Moser
Informática em foco/ Greisse Moser Badalotti; Danice Betânia 
de Almeida; Pedro Sidnei Zanchett (Orgs.) : UNIASSELVI, 2016.
 
141 p. : il.
 
ISBN 978-85-7830-992-3
 
1. Informática – estudo e ensino.
I. Centro Universitário Leonardo Da Vinci. 
Informática em Foco
Informática em Foco
------------------ [ APRESENTAÇÃO INFORMÁTICA EM FOCO ] ------------------
INFORMÁTICA EM FOCO I
Caro leitor, você está prestes a iniciar a leitura do livro Informática em 
Foco I, que apresentamos a você com grande satisfação. O presente livro envolve 
assuntos vinculados à área de atuação do Professor de Informática. O objetivo é 
explorar temas que permitam instigá-lo sobre os diversos assuntos aqui tratados, 
fazendo conexões pertinentes ao contexto tecnológico. 
Constantemente somos avalidados em provas, concursos e em grande 
parte precisamos de um guia rápido para nos apoiar na revisão dos conhecimentos 
adquiridos no decorrer do curso. Com base nesta necessidade consideramos de 
extrema importância a revisão dos assuntos e, como resultado, prepará-lo ainda 
mais para obter o sucesso nestas atividades. 
Vale salientar que os textos reunidos nesta publicação são frutos das 
problematizações e estudos realizados pela equipe de professores, e organizados 
pela Coordenadora do Curso de Licenciatura em Informática da UNIASSELVI, pois 
o mesmo reflete a base conceitual da profissão.
Esperamos que você faça uma ótima leitura!
Me. Greisse Moser Badalotti
Coordenadora do Curso Superior de Licenciatura em Informática
Informática em Foco
Informática em Foco
SUMÁRIO
CAPÍTULO 1 - ENGENHARIA DE SOFTWARE E QUALIDADE
 DE SOFTWARE ...................................................................... 1
1 INTRODUÇÃO À ENGENHARIA DE SOFTWARE ...................................... 1
2 METODOLOGIA DE DESENVOLVIEMENTO DE SISTEMAS ..................... 3
3 FASES DE DESENVOLVIMENTO DE SOFTWARE .................................... 4
4 PROCESSOS DE ENGENHARIA DE SOFTWARE ..................................... 5
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE ...................... 5
6 REQUISITO DE SOFTWARE ....................................................................... 7
7 ESTIMATIVAS E MÉTRICAS DE PROJETOS DE SOFTWARE .................. 8
8 QUALIDADE DE SOFTWARE ...................................................................... 12
9 PADRÕES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE ..... 16
10 MÉTODOS ÁGEIS ...................................................................................... 20
10.1 SCRUM .................................................................................................... 21
10.2 EXTREME PROGRAMMING ................................................................... 22
11 TESTES DE SOFTWARE ........................................................................... 23
CAPÍTULO 2 - LÓGICA, ALGORITMOS E ESTRUTURA DE DADOS .......... 27
1 LÓGICA DE PROGRAMAÇÃO .................................................................... 27
1.1 ESTRUTURAS DE SELEÇÃO ................................................................... 29
1.1.1 “Se-então-senão”..................................................................................... 29
1.1.2 Seleção Encadeada ................................................................................ 30
1.2 ESTRUTURAS DE REPETIÇÃO ............................................................... 32
1.2.1 Enquanto-faça ......................................................................................... 32
1.2.2 Para-faça ................................................................................................. 33
1.2.3 Repita-até ................................................................................................ 34
1.3 VETORES UNIDIMENSIONAIS ................................................................. 34
1.4 MATRIZES .................................................................................................. 36
1.5 LISTAS ENCADEADAS .............................................................................. 37
1.6 PILHAS ....................................................................................................... 40
1.7 FILAS.......................................................................................................... 41
Informática em Foco
1.8 ANÁLISE E TÉCNICAS DE ALGORITMOS ............................................... 43
1.8.1 Divisão e Conquista................................................................................. 42
1.8.2 Método Guloso ........................................................................................ 45
1.8.3 Programação Dinâmica ........................................................................... 48
CAPÍTULO 3 - GESTÃO DE PROJETO .......................................................... 49
1 INTRODUÇÃO .............................................................................................. 49
2 PARTES INTERESSADAS E PMO .............................................................. 51
3 OS GRUPOS DE PROCESSOS DE GERENCIAMENTO DE PROJETO .... 54
4 ÁREAS DE CONHECIMENTO ..................................................................... 56
5 ESCOPO ....................................................................................................... 59
6 TEMPO .......................................................................................................... 60
7 CUSTO .......................................................................................................... 61
8 QUALIDADE ................................................................................................. 62
9 RECURSOS HUMANOS ............................................................................... 63
10 COMUNICAÇÕES ....................................................................................... 64
11 RISCOS ....................................................................................................... 65
12 AQUISIÇÕES .............................................................................................. 67
13 GERENCIAMENTO DAS PARTES INTERESSADAS ............................... 68
CAPÍTULO 4 - INTELIGÊNCIA ARTIFICIAL ................................................... 71
1 MODERNAS TÉCNICAS DE COMPUTAÇÃO:
 SISTEMAS ESPECIALISTAS ....................................................................... 71
2 MODERNAS TÉCNICAS DE COMPUTAÇÃO - REDES NEURAIS ............ 77
CAPÍTULO 5 - FUNDAMENTOS DA COMPUTAÇÃO, ARQUITETURA
 E REDES DE COMPUTADORES ............................................ 83
1 PRINCIPAIS MARCOS DA EVOLUÇÃO DA COMPUTAÇÃO ..................... 83
2 BASES DOS SISTEMAS COMPUTACIONAIS ............................................ 86
3 PRINCIPAIS TIPOS DE ARQUITETURAS COMPUTACIONAIS ................. 90
4 COMPONENTES FÍSICOS DO SISTEMA COMPUTACIONAL ................... 93
5 TIPOS DE MEMÓRIAS E GERENCIAMENTO ............................................. 101
6 TIPOS DE REDES ........................................................................................105
Informática em Foco
7 TOPOLOGIAS DE REDES ........................................................................... 106
8 ENDEREÇOS IPV4 E IPV6 ........................................................................... 107
9 SISTEMA DNS .............................................................................................. 110
CAPÍTULO 6 - MATRIZES ............................................................................... 115
1 DEFINIÇÃO ................................................................................................... 116
2 MONTAGEM DE UMA MATRIZ .................................................................... 116
2.1 REPRESENTAÇÃO GENÉRICA DE UMA MATRIZ ................................... 117
3 OPERAÇÕES ENTRE MATRIZES ............................................................... 120
3.1 ADIÇÃO E SUBTRAÇÃO DE MATRIZES .................................................. 121
3.2 MULTIPLICAÇÃO DE UMA MATRIZ POR UM NÚMERO REAL ............... 123
3.3 MULTIPLICAÇÃO DE MATRIZES .............................................................. 124
CAPÍTULO 7 - ESTATÍSTICA .......................................................................... 129
1 MEDIDAS DE TENDÊNCIA CENTRAL ........................................................ 129
1.1 MÉDIA (M) .................................................................................................. 129
1.2 MEDIANA (ME)........................................................................................... 132
1.3 MODA (MO) ................................................................................................ 134
REFERÊNCIAS ................................................................................................ 137
Informática em Foco
Informática em Foco
Informática em Foco
1
CAPÍTULO 1
ENGENHARIA DE SOFTWARE E QUALIDADE DE SOFTWARE
APRESENTAÇÃO
Caro(a) acadêmico(a), neste capítulo vamos relembrar alguns dos principais 
conceitos relacionados aos temas de Engenharia de Software e Qualidade de 
Software. Apresentaremos esses assuntos de forma sintetizada. Ressaltamos que, 
em caso de dúvida, você pode buscar o detalhamento do assunto no caderno da 
disciplina.
Apresentaremos um resumo do que consideramos os principais tópicos 
do tema apresentado, que são: Introdução à Engenharia de Software, Metodologia 
de Desenvolvimento de Sistemas, RUP, Scrum, Extreme Programming e Testes 
de Software.
Vamos então iniciar os estudos, empregando o máximo de atenção e foco 
para que os resultados sejam os melhores possíveis, contribuindo para o incremento 
e fixação dos seus conhecimentos!
Me. Pedro Sidnei Zanchett
1 INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Segundo Ian Sommerville (2011), a Engenharia de Software é uma disciplina 
da engenharia de sistemas que se ocupa de todos os aspectos da produção de 
software, desde os estágios iniciais de levantamento e especificação de requisitos 
até a implantação e manutenção, ou seja, que entrou em operação. É um conjunto 
de atividades, parcialmente ou totalmente ordenadas, com a finalidade de obter 
um produto de software de qualidade e cumprir corretamente os contratos de 
desenvolvimento.
Informática em Foco
2
Segundo Roger Pressman (2006), a Engenharia de Software poderá ser 
mais bem entendida como uma tecnologia em camadas ou níveis, conforme pode 
ser vista na Figura 1.
Figura 1 - Camadas da Engenharia de Software
FONTE: Disponível em: <http://3.bp.blogspot.com/_CMoqSGzMYOg/SkrJEy3nGeI/AAAAAAAAAAk/
Ee1ZgJBwMdM/s320/Figura+2.1.Engenharia+de+Software+em+Camadas.gif>. Acesso em: 
6 jul. 2015.
Na base da figura, formando a camada foco na qualidade, dá-se ênfase à 
preocupação de qualquer disciplina de engenharia, que é qualidade. A qualidade na 
Engenharia de Software é baseada nos conceitos de gerenciamento de qualidade 
total (TQM – Total Quality Management) para a melhoria contínua dos processos para 
obter sucesso em longo prazo através da satisfação dos clientes (HIRAMA, 2011).
De acordo com Hirama (2011), as camadas são divididas em:
A camada de processo permite integrar as camadas de métodos e de 
ferramentas para que se possa desenvolver um software nos prazos acordados e 
de maneira adequada. Um processo que permite que se planeje e se controle o 
projeto de software.
A camada de métodos provê as abordagens e as atividades necessárias 
para a construção de um software. Os métodos abrangem um conjunto amplo 
de tarefas que incluem análise de requisitos, projeto, implementação, testes e 
manutenção. Os métodos de Engenharia de Software são baseados em um 
conjunto de princípios que governam cada área de tecnologia e incluem atividades 
de modelagem e técnicas descritivas.
Informática em Foco
3
A camada de ferramentas provê apoio automatizado ou semiautomatizado 
para processos e métodos. As ferramentas da área de Engenharia de Software são 
conhecidas como CASE (Engenharia de Software Apoiada por Computador, do 
termo em inglês Computer-Aided Software Engeneering). 
2 METODOLOGIA DE DESENVOLVIEMENTO DE SISTEMAS
Segundo Fernandes (1999), metodologia de sistemas se define como um 
conjunto de normas, procedimentos, técnicas e ferramentas de análise que definem o 
padrão desejado por uma empresa para o desenvolvimento de projetos de sistemas. 
A ausência de uma metodologia de desenvolvimento de sistemas pode 
levar ao caos, na medida em que cada indivíduo procura aplicar em seu projeto as 
melhores soluções dentro das limitações de sua experiência profissional. Mesmo 
que suas soluções sejam ótimas e que os resultados individuais sejam melhores, 
dificilmente, no conjunto de todas as aplicações de uma corporação, haverá a 
harmonia desejada. A produtividade e a eficiência que são esperadas de um 
departamento de sistemas não podem ser obtidas sem critérios, sem regras e sem 
análise contínua das ferramentas de trabalho postas à disposição dos profissionais 
de sistemas (PRESSMAN, 2006).
Fernandes (1999) nos diz que, para que uma metodologia de desenvolvimento 
de sistemas seja consistente, oferecendo maior produtividade e qualidade, deverá 
atender a alguns requisitos fundamentais:
• Padronização: executar as atividades de maneira idêntica, fazendo com 
que haja aperfeiçoamento do processo. 
• Flexibilidade: é a capacidade de se adaptar às mudanças.
• Documentação: manter informações sobre o produto e garantir rapidez 
diante das mudanças.
• Modularização: consiste em dividir um conjunto de atividades em vários 
conjuntos menores, objetivando melhor visualização e acompanhamento por parte 
de todos os interessados no resultado final
Informática em Foco
4
• Planejamento: forma madura de administrar o tempo é programar o futuro 
em relação às metas e aos objetivos a serem alcançados.
2.1 RUP
Segundo Kroll e Kruchten (2003), o Rational Unified Process, de sigla RUP, é 
uma maneira de desenvolvimento de software que é iterativa, centrada à arquitetura 
e guiada por casos de uso. É um processo de engenharia de software bem definido 
e bem estruturado. Ele define claramente quem é responsável pelo que, como as 
coisas devem ser feitas e quando fazê-las. O RUP também provê uma estrutura 
bem definida para o ciclo de vida de um projeto, articulando claramente os marcos 
essenciais e pontos de decisão e, por fim, é também um produto de processo que 
oferece uma estrutura de processo customizável para a engenharia de software.
O RUP utiliza a linguagem de modelagem unificada para especificar, modelar 
e documentar artefatos. Por ser flexível e configurável, ele pode ser utilizado em 
projetos de pequeno, médio e grande porte. Com o RUP é possível obter qualidade 
de software, produtividade no desenvolvimento, operação e manutenção de software, 
controle sobre o desenvolvimento dentro de custos, prazos e níveis de qualidade 
desejados, sem deixar de levar em conta a estimativa de prazos e custo com maior 
precisão (BOENTE, 2016).
3 FASES DE DESENVOLVIMENTO DE SOFTWARE
Atualmente, muitas são as metodologias de desenvolvimentode softwares. 
Existem as clássicas (antigas), que são mais estáveis de serem executadas através 
de diversos ciclos de vida prescritivo, seguindo um único caminho de trabalho, e 
aquelas metodologias ágeis, que possuem diversas formas dinâmicas de execução, 
exigindo maior experiência dos envolvidos.
Para capturar a dimensão do tempo de um projeto, o processo de Engenharia 
de Software se divide em quatro fases que indicam a ênfase que é dada no projeto 
em um dado instante:
Informática em Foco
5
• Fase de Iniciação: ênfase no escopo.
• Fase de Elaboração: ênfase na análise. 
• Fase de Construção: ênfase no desenvolvimento.
• Fase de Transição: ênfase na implantação.
4 PROCESSOS DE ENGENHARIA DE SOFTWARE
No momento em que se decide construir um software, é fundamental 
também decidir qual processo será seguido. A criação de um projeto de software 
é uma atividade intelectual de alto nível de complexidade, necessitando melhor 
visibilidade na sua construção, sabendo-se de início quais são as etapas do projeto.
Um processo de software é composto por métodos (aquilo que diz o que, 
em uma determinada tarefa), por ferramentas (que dão suporte automatizado aos 
métodos) e procedimentos (que fazem o elo de ligação entre os métodos e as 
ferramentas). Uma organização que possui um processo de engenharia de software 
deverá levar muito a sério estes três princípios de processo, a fim de que seus 
projetos de software sejam de sucesso, ou seja, equipes produtivas e softwares 
bem feitos.
5 CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE
O ciclo de vida de um software descreve as fases pelas quais o software 
passa desde a sua concepção até ficar sem uso algum, determinando os passos a 
serem seguidos no desenvolvimento de sistemas, mantendo uma padronização de 
trabalho e determinando as etapas de validação do projeto. As fases do ciclo de vida 
são constituídas de planejamento (iniciação), análise e especificação de requisitos, 
projeto (elaboração), implementação (construção), testes, entrega e implantação 
(transição) e, por fim, operação e manutenção, passando desde a sua concepção 
até ficar sem uso algum após o término do projeto.
Informática em Foco
6
De maneira geral, as fases do ciclo de vida de um software são constituídas 
de planejamento, análise e especificação de requisitos, projeto, implementação, 
testes, entrega e implantação, operação e manutenção. 
Os modelos de processo de ciclo de vida durante o desenvolvimento do 
software podem ser linear, incremental ou iterativo, logo, compreendê-los poderá 
auxiliar na adoção de um dos modelos mais adequados à realidade e necessidade 
da organização. 
Para cada uma destas categorias de ciclos de vida de software há um ou 
mais modelos formais disponíveis para adoção, e os modelos mais conhecidos são: 
• Modelo cascata ou sequencial, possui um ciclo de vida clássico, em 
que todas as fases de desenvolvimento possuem início e fim bem definidos, e não 
avança sem estar com a fase anterior 100% concluída. 
• O objetivo das tecnologias de prototipação é produzir uma representação 
visual das funcionalidades que o sistema terá depois de pronto, permitindo ao 
usuário e à equipe de desenvolvimento avaliar as características antes que ele 
seja efetivamente implementado e entregue. Inicialmente, o modelo de prototipação 
desenvolve uma visão da sua interface e depois reaproveita as telas para configurar 
e programar o restante do produto de software, trazendo maior rapidez na construção 
do projeto e aceitação dos usuários.
• O modelo espiral traz uma abordagem orientada à gestão de riscos 
ao invés de apenas orientar a documentação e codificação, como nos casos dos 
modelos cascata e de prototipação. Também no modelo espiral, à medida que o 
projeto de software avança, são incorporados novos requisitos de forma evolutiva, 
com sobreposição de atividades em cada fase do projeto, aumentando a qualidade 
do planejamento em cada ciclo e dando maior visibilidade à gerência.
• O modelo iterativo e incremental permite dividir o escopo do projeto em 
partes gradativas do desenvolvimento, evoluindo o projeto em versões de novas 
funcionalidades até o sistema estar completo. O modelo iterativo pode desenvolver 
os módulos ou funcionalidade de forma independente e liberar o projeto em partes; 
já o modelo incremental poderá desenvolver em módulos, porém há dependência 
Informática em Foco
7
de funcionalidades entre estes módulos para um próximo módulo ser implementado, 
permitindo a liberação após o acréscimo de funcionalidades feitas nas iterações 
anteriores.
• O modelo baseado em componentes permite agrupar rotinas relacionadas 
de forma a montar componentes que podem ser reutilizados em diversos módulos 
do sistema. A partir do momento em que sobe o requisito do cliente, é feita uma 
busca na biblioteca de componentes, que trata sobre este requisito, e se já existir 
e estiver completo, faz-se o seu reúso; caso contrário, criar um novo componente 
e fazer sua integração à biblioteca, liberando o produto pronto ao cliente.
• O foco do modelo em V dá ênfase nas atividades de testes durante a 
análise, implementação e homologação do sistema, primeiramente validando-os 
antes do desenvolvimento, garantindo maior entendimento do problema e evitando 
enganos e retrabalhos.
• Modelo RAD (Rapid Application Development) propõe um ciclo de vida 
rápido de desenvolvimento utilizando um processo incremental entre as etapas de 
modelagem e codificação durante um período de até 90 dias. Já o modelo de quarta 
geração trata dos modelos de última geração, utilizando ferramentas de alto nível 
através da inteligência computacional, explorando os paradigmas da ontologia e 
semântica das aplicações, ou seja, próxima à linguagem natural.
6 REQUISITO DE SOFTWARE
A partir do momento em que for decidido iniciar um processo de construção 
de um software, deve-se definir o escopo do projeto através de uma lista de 
funcionalidades que se deseja disponibilizar para seus usuários no sistema, no qual 
estas necessidades identificadas são denominadas de requisito. Portanto, requisito 
é uma definição formal e detalhada de uma função do sistema.
A extração de requisitos é o processo de transformar o conhecimento tácito, 
que está na mente dos usuários, em conhecimento explícito via documentação 
formal. Essa transformação só é possível através da determinação dos objetivos 
Informática em Foco
8
do produto e das restrições para a sua operacionalidade, através de uma análise 
do problema e documentação dos resultados. A saída do processo de extração de 
requisitos é um documento de especificação do sistema que deve dizer o que o 
produto a ser desenvolvido deverá fazer, e não como deve ser feito. 
Diversas atividades de requisitos de software ocorrem ao longo de todo o 
ciclo de vida do software, um trabalho que consiste na análise de requisitos para 
identificar, quantificar, definir, especificar, documentar, rastrear, priorizar e classificar 
os principais problemas que o futuro software deve resolver. 
Existem duas categorias de requisitos: os requisitos de negócio, que irão 
detalhar quais serviços e restrições são esperados do sistema, e os requisitos de 
sistemas, que irão detalhar as funções e restrições operacionais do sistema; a 
primeira atividade executada pelo analista de negócios e, a segunda, pelo analista 
de sistemas.
Os requisitos de negócio ou de sistemas podem ser realizados por três tipos: 
os requisitos funcionais, que definem o comportamento do sistema; os requisitos 
não funcionais, que incluem restrições impostas pelas normas ou tecnologias; e os 
requisitos inversos, que irão informar tudo o que não deverá contemplar no sistema.
7 ESTIMATIVAS E MÉTRICAS DE PROJETOS DE SOFTWARE
Estimar software significa determinar quanto de dinheiro, esforço, recursos 
e tempo serão necessários para criar um sistema, ou seja, o gerente e a equipe de 
desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessários, 
o tempode duração e, por fim, o custo do projeto.
A estimativa de custo faz parte do planejamento de qualquer projeto de 
engenharia. A diferença é que na engenharia de software o custo principal é o 
esforço, ou seja, o custo de mão de obra; assim, para se calcular o custo de software 
é necessário dimensionar o trabalho para desenvolvê-lo. Em geral, esse trabalho é 
expresso pelo número de pessoas trabalhando numa unidade de tempo, tal como 
Informática em Foco
9
pessoas-mês ou pessoa-ano. O trabalho que uma pessoa consegue fazer num mês 
pode ser traduzido em números de horas de trabalho num mês. 
Métricas de Software é um assunto discutido há mais de 20 anos na 
engenharia de software, e, no entanto, não é verificada sua utilização, na prática, 
pela grande maioria dos projetos de construção de software. Área que possibilita 
realizar uma das atividades mais fundamentais do processo de gerenciamento 
de projetos: o planejamento. A partir desse, pode-se identificar a quantidade de 
esforço, de custo e das atividades que serão necessárias para a realização do 
projeto. (ZANCHETT, 2015).
Ainda segundo o autor, uma métrica de software é a medição de um atributo 
(propriedades ou características) de uma determinada entidade (produto, processo 
ou recursos). Como exemplo podemos citar: o tamanho do produto de software em 
número de linhas de código; número de pessoas necessárias para programar um 
caso de uso; número de defeitos encontrados por fase de desenvolvimento; esforço 
para a realização de uma tarefa; tempo para a realização de uma tarefa; custo para 
a realização de uma tarefa; grau de satisfação do cliente etc.
A partir do uso das métricas de software, uma empresa desenvolvedora de 
sistemas poderá entender e aperfeiçoar o processo de desenvolvimento, melhorar 
a gerência de projetos e o relacionamento com clientes, reduzir frustrações e 
pressões de cronograma, gerenciar contratos de software, indicar a qualidade de 
um produto de software, avaliar a produtividade do processo, avaliar os benefícios 
(em termos de produtividade e qualidade) de novos métodos e ferramentas de 
engenharia de software, avaliar retorno de investimento, identificar as melhores 
práticas de desenvolvimento de software, embasar solicitações de novas ferramentas 
e treinamento, avaliar o impacto da variação de um ou mais atributos do produto ou 
do processo na qualidade e/ou produtividade, formar uma baseline para estimativas, 
melhorar a exatidão das estimativas, oferecer dados qualitativos e quantitativos ao 
gerenciamento de desenvolvimento de software, de forma a realizar melhorias em 
todo o processo de desenvolvimento de software etc. (ZANCHETT, 2015).
Existem vários métodos que podem ser utilizados para se estimar o custo do 
desenvolvimento e a vida útil de um sistema. Em geral, representa o custo monetário 
ou o esforço necessário para desenvolver e manter um sistema. 
Informática em Foco
10
Para se estabelecer essas estimativas, podem-se utilizar técnicas de 
decomposição do produto e utilizar a opinião de especialistas que, baseados em 
experiências de projetos anteriores, são capazes de estimar o esforço e o tempo 
de desenvolvimento do projeto. Podem-se considerar dois tipos de decomposição: 
(1) decomposição do produto para estimar o número de linhas de código utilizando 
técnicas como pontos por função, caso de uso etc.; (2) decomposição do processo 
considerando-se as atividades de cada etapa de engenharia de software, 
dependendo do paradigma utilizado.
A seguir são apresentados métodos ou técnicas para estimativa de software, 
que são: Linhas de Código (LOC); Pontos de História; Análise de Pontos de 
Função, Análise de Pontos de Caso de Uso, COCOMO II e estimativa para projetos 
Orientados a Objeto.
• Linha de Código (LOC): é métrica orientada ao tamanho do software, 
consiste em estimar o número de linhas que um programa deverá ter. Para sua 
definição são considerados três valores, o LOC otimista, o LOC pessimista e o LOC 
esperado, e a partir dos dados coletados seus valores são aplicados na fórmula: 
KSLOC = 4*KSLOC esperado + KSLOC otimista + KSLOC pessimista)/6.
• Pontos de História: é uma métrica de estimativa de tempo, pergunta-
se à equipe quanto tempo tantas pessoas que se dedicassem a uma história de 
usuário levariam para terminá-la, gerando uma versão executável funcional. Então, 
multiplica-se o número de pessoas pelo número de dias para chegar ao valor de 
pontos de história.
• Análise de Pontos de Função (APF): define processos e técnicas 
formais e padronizadas para dimensionamento e estimativa da complexidade de 
sistema, ou seja, para medir o tamanho do escopo. Para manter e determinar os 
procedimentos de contagem APF observa-se os seguintes passos: (1) Determinar o 
tipo de contagem (desenvolvimento, melhoria ou aplicação existente). (2) Determinar 
as Fronteiras da aplicação (escopo do sistema). (3) Identificar e atribuir valor em 
pontos de função não ajustados para as transações sobre dados (entrada, consultas 
e saídas externas). (4) Identificar e atribuir valor em pontos de função não ajustados 
(UFPA) para os dados estáticos (arquivos internos e externos). (5) Determinar o valor 
Informática em Foco
11
de ajuste técnico (VAF). (6) Calcular o número de pontos de função ajustados (AFP).
• Pontos de Caso de Uso (PUC): baseia-se na análise da qualidade e 
complexidade dos atores e casos de uso, o que gera pontos de caso de uso não 
ajustados. Depois, a aplicação e fatores técnicos e ambientais levam aos pontos 
de caso de uso ajustados. Primeiro deve-se relacionar os atores, classificá-los de 
acordo com seu nível de complexidade (simples, médio ou complexo), atribuindo 
respectivamente os pesos 1, 2 ou 3. Em seguida, contar os casos de uso e atribuir o 
grau de complexidade, sendo baseada no número de classe e transações. Utiliza-se 
a seguinte fórmula para calcular PCUs não ajustados: PCUNA = TPNAA+ TPNAUC, 
e para chegar ao PUCs ajustado determina-se o fator de complexidade técnica, que 
varia da escala de 0 a 5 para cada grau de dificuldade do sistema a ser construído 
e, por fim, chega-se ao valor PUCs ajustado utilizando a seguinte fórmula: PCUA 
= PCUNA * Fator de complexidade técnica * Fator de complexidade ambiental. E 
para 8. Calcular a estimativa de horas de programação, basta multiplicar o PCUs 
ajustado pelo número pessoa hora por unidade de PCU. (ZANCHETT, 2015).
• Modelo COCOMO II: é um modelo construtivo de custo que trata das 
seguintes áreas: Modelo de composição de aplicação, Modelo de estágio de início 
do projeto e Modelo de estágio pós-arquitetura.
Para requerer informações de tamanho como parte da hierarquia do projeto 
há disponíveis três diferentes opções: pontos de objeto, pontos de função e linhas 
de código-fonte.
• A contagem de pontos de objeto é então determinada multiplicando-se 
o número original de instâncias de objeto pelo fator de peso e somando para obter o 
total da contagem de pontos de objeto. Quando deve ser aplicado desenvolvimento 
baseado em componentes ou reutilização de software em geral, é estimada a 
porcentagem de reutilização (% reúso) e é ajustada a contagem de pontos de 
objeto: NOP = (pontos de objeto) * [(100 - % reúso)/100]. Em que NOP é definido 
como novos pontos de objeto.
• Para derivar uma estimativa de esforço com base no valor calculado para 
NOP, deve ser derivada uma “taxa de produtividade”. O quadro abaixo apresenta 
a taxa de produtividade: PROD = (NOP)/pessoa-mês. Para diferentes níveis de 
experiência do desenvolvedor e maturidade do ambiente de desenvolvimento. 
Informática em Foco
12
Uma vez determinada a taxa de produtividade, calcula-se a estimativa de esforço 
do projeto: Esforço estimado = NOP/PROD.
Quadro 1 – Fatores de Ajuste
FONTE: Pressman (2011)
• Estimativa para projetos Orientados a Objeto: utilize qualquer método 
anterior para decomposição de esforço, valendo-se da modelagem UML através da 
PCU, determine o número de classes-chave e classifique o tipo de interfacepara 
a aplicação, desenvolva um multiplicador para classes e multiplique o número das 
classes-chave pelo multiplicador para obter uma estimativa do número de classes 
de apoio. Multiplique o número total das classes (classes-chave + classe de apoio) 
pelo número médio de unidades de trabalho por classe.
8 QUALIDADE DE SOFTWARE
Em desenvolvimento de software, a qualidade deve ser entendida nos 
aspectos da correta compreensão dos requisitos do cliente, quando se desenvolve 
o projeto com zero defeito, quando se obtém aumento de produtividade e redução 
de custos e, por fim, uma boa usabilidade do sistema. A qualidade está fortemente 
relacionada à conformidade com os requisitos, ou seja, atender ao que o usuário 
pede formalmente. Na área de Engenharia de Software, segundo Roger Pressman 
(2011) a qualidade é definida como sendo a conformidade a requisitos funcionais e de 
desempenho explicitamente declarados, a padrões de desenvolvimento claramente 
documentados e a características implícitas que são esperadas de todo software 
profissionalmente desenvolvido. 
Informática em Foco
13
A Organização Internacional de Padronização (International Organization 
for Standardization - ISO), através da ISO 9000, define qualidade como a totalidade 
das características de uma entidade que lhe confere a capacidade de satisfazer 
às necessidades explícitas e implícitas. Necessidades explícitas são as condições 
e objetivos propostos por aqueles que produzem o software. As necessidades 
implícitas são necessidades subjetivas dos usuários, também chamadas de fatores 
externos, e podem ser percebidas tanto pelos desenvolvedores quanto pelos 
usuários. (ISO, 2015).
Qualidade de software está relacionada a entregar ao cliente o produto 
final que satisfaça suas expectativas, dentro daquilo que foi acordado inicialmente 
por meio dos requisitos do projeto. Nesse contexto, qualidade de software que 
objetiva garantir essa qualidade pela definição de processos de desenvolvimento. 
(ENGHOLM JR., 2010).
Para produzir um produto de software com qualidade deve-se possuir 
processos formais que visem à prevenção e detecção de defeitos durante o 
desenvolvimento de software. A origem do produto se dá pela implementação de 
um processo consistente e em constante melhoria contínua. 
Figura 2 – Desenvolvimento de Produto de Software
FONTE: O autor
Várias técnicas são utilizadas para identificar defeitos nos produtos de 
trabalho. Esses defeitos são eliminados através de retrabalho, que tem efeito 
Informática em Foco
14
imediato na produtividade do projeto. Defeitos também são encontrados em 
atividades de teste e podem ser analisados, a fim de se identificar suas causas. 
A partir dessa análise, lições aprendidas podem ser usadas para criar futuros 
produtos e prevenir futuros defeitos e, dessa forma, ter impacto positivo na 
qualidade do produto e na produtividade do projeto.
Todo processo de software deve possuir, junto ao plano de projeto, uma 
documentação específica da qualidade, denominada como plano de qualidade, 
que deve compreender informações sobre como a equipe de qualidade irá garantir 
o cumprimento da política de qualidade, no contexto do programa ou projeto a 
ser desenvolvido, quais métodos, técnicas, métricas, treinamentos e padrões 
devam ser utilizados ao longo de todo o ciclo de vida do projeto. O plano deve 
oferecer a base do gerenciamento dos riscos, dos testes, das inspeções, das 
auditorias e como deverão ocorrer os reportes de problemas e ações corretivas.
FONTE: Disponível em: <http://www.infoclad.com.br/apostilas/Engenharia%20de%20Software/
Apostila%20de%20Engenharia%20de%20Software/Cap%EDtulos/UNIDADE%20
II/CAP%CDTULO%2015%20DA%20APOSTILA_QUALIDADE%20DE%20 
SOFTWARE_2%AA%20%20PARTE.doc>. Acesso em: 8 maio 2016.
Pode-se citar, entre tantos outros exemplos, que a técnica de prevenção 
de defeitos em um processo de desenvolvimento de software se dá pelo uso de 
instruções de procedimentos (padrões formais), treinamentos, documentação, 
modelagem e reengenharia; já as técnicas de detecção de defeitos podem ser pela 
análise de código; revisão por pares; testes, auditorias, verificações e validações. 
Na gestão da qualidade de software existem diversas atividades voltadas à 
garantia da qualidade e ao controle de qualidade de software. A primeira é para a 
definição padronizada das atividades voltadas à prevenção de defeitos e problemas, 
que podem surgir nos produtos de trabalho. Área que define padrões, metodologias, 
técnicas e ferramentas de apoio ao desenvolvimento tendo como entrada o plano 
de qualidade de software e os resultados de medições de qualidade. A segunda 
é voltada para o monitoramento de resultados específicos do projeto, ou seja, a 
detecção de defeitos, executada através do uso de técnicas que incluem revisões 
por pares, teste e análise de tendências, entre outras. Observe o quadro com as 
principais diferenças entre elas (VASCONCELOS et al., 2006).
Informática em Foco
15
Quadro 2 – Garantia de Qualidade X Controle de Qualidade
 Garantia da Qualidade Controle da Qualidade
1. Garantia da qualidade garante que 
o processo é definido e apropriado. 
2. Metodo log ia e padrões de 
desenvolvimento são exemplos de 
garantia da qualidade. 
3. Garantia da qualidade é orientada 
ao processo. 
4. Garantia da qualidade é orientada 
à prevenção. 
5. Foco em monitoração e melhoria 
de processo. 
6. As atividades são focadas no 
início das fases no ciclo de vida de 
desenvolvimento de software. 
7. Garantia da qualidade garante que 
você está fazendo certo as coisas e da 
maneira correta. 
1. As atividades de controle da 
qualidade focam na descoberta de 
defeitos específicos. 
2. Um exemplo de controle da 
qualidade poderia ser: "Os requisitos 
definidos são os requisitos certos?". 
3. Controle da qualidade é orientado 
a produto. 
4. Controle da qualidade é orientado 
à detecção. 
5. Inspeções e garantia de que o 
produto de trabalho atenda aos 
requisitos especificados. 
6. As atividades são focadas no 
final das fases no ciclo de vida de 
desenvolvimento de software. 
7. Controle da qualidade garante que 
os resultados do seu trabalho são os 
esperados, conforme requisitos. 
FONTE: Disponível em: <http://slideplayer.com.br/slide/3692245/>. Acesso em: 20 set. 2015.
Roger Pressmann (2011) definiu que a Engenharia de Software é composta 
em uma tecnologia em camadas com Foco em Qualidade, em que se dá ênfase à 
preocupação da disciplina, padronização e satisfação do cliente.
Foco em Processo, em que se dá ênfase no planejamento das atividades 
e no controle do projeto de software. Foco em Métodos, em que se dá ênfase às 
abordagens e às atividades necessárias para a construção de um software. Foco 
em Ferramentas, em que se dá ênfase ao apoio automatizado ou semiautomatizado 
para processos e métodos. 
Informática em Foco
16
A engenharia de software pode ser considerada uma tecnologia, com 
métodos e ferramentas próprios, estruturada em camadas, do ponto de vista 
sistêmico. A abordagem sistêmica da engenharia de software deve se apoiar num 
compromisso organizacional com a qualidade que leve à cultura de um processo 
contínuo de aperfeiçoamento, e é essa cultura que, em última análise, leva ao 
desenvolvimento de abordagens cada vez mais efetivas. A camada de base em 
que a engenharia de software se apoia é o foco na qualidade, e o “adesivo” que 
mantém unidas as camadas, estruturadas segundo a visão sistêmica, é o processo 
(ZANCHETT, 2015). 
As dimensões da qualidade de software: Qualidade do processo, qualidade 
das pessoas, tecnologia de desenvolvimento, custo, tempo e cronograma.
9 PADRÕES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE
Entre os principais objetivos da qualidade de software está a definição 
de técnicas e ferramentas para serem utilizadas durante o ciclo de vida do 
projeto, PADRONIZANDO a forma de realizar as atividades, um guia de trabalho 
proporcionando assertividade no projeto, evitando erros humanos. 
Diversos padrões e normasde qualidade de software vêm sendo propostos 
ao longo dos anos. Essas normas têm sido fortemente adotadas nos processos 
de software das organizações em todo o mundo. As normas da International 
Organization for Standardization (ISO, 2015) são padrões internacionais que 
“especificam requisitos para um sistema gerencial de qualidade de uma organização”. 
Com o crescimento substancial das indústrias de software e levando-se 
em conta que a produção de software apresenta características peculiares, a ISO 
tem trabalhado na definição de várias normas que podem ser utilizadas como 
guias e padrões para diversas áreas de atuação dentro do contexto da ciência da 
computação. 
As principais normas ISO aplicadas à qualidade de produto ou processo 
de software são:
Informática em Foco
17
• Norma ISO/IEC 9000: é um conjunto de documentos que engloba pontos 
referentes à garantia da qualidade em projeto, desenvolvimento, produção, instalação 
e serviços associados; objetivando a satisfação do cliente pela prevenção de não 
conformidades em todos os estágios envolvidos no ciclo da qualidade da empresa. 
• Norma ISO/IEC 12207: é o estabelecimento de uma estrutura comum 
utilizada como referência para os processos de ciclo de vida de software 
considerando que o desenvolvimento e a manutenção de software devem ser 
conduzidos da mesma forma que a disciplina de engenharia.
• Norma ISO/IEC 15504: possui um conjunto de nove documentos que 
endereçam avaliação de processo, assessoria de treinamento e competência, 
determinação da capacidade e melhoria de processo e está se tornando um modelo 
de referência para outros padrões, como o CMMI.
• Norma ISO/IEC 9126: estabelece um modelo de qualidade para o produto 
de software que é avaliado conforme seis categorias básicas, que são subdivididas 
em algumas características que são importantes para cada categoria: funcionalidade, 
confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade.
• Norma ISO/IEC 27000: trata sobre a área de segurança da informação 
através de Requisitos do SGSI; Controles de Segurança; Diretrizes de Implementação; 
Medição; Gestão de Risco e Auditoria de Segurança.
• Norma ISO/IEC 15939: define um processo de medição aplicável a 
sistemas, engenharia de software e disciplinas de gestão. 
Os modelos de qualidade mais difundidos nas indústrias de software no 
Brasil são o CMMI e MPS.BR.
O principal propósito do CMMI (Capability Maturity Model Integration ou 
Integração dos Modelos de Capacitação e Maturidade de Sistemas) é fornecer 
diretrizes baseadas em melhores práticas para a melhoria dos processos e 
habilidades organizacionais, cobrindo o ciclo de vida de produtos e serviços 
completos, nas fases de concepção, desenvolvimento, aquisição, entrega e 
manutenção.
Informática em Foco
18
O CMMI é um dos modelos mais aceitos para a melhoria da qualidade 
e do processo de software em todo o mundo e define os princípios e práticas 
que devem ser aplicados a uma organização para atingir estágios evolutivos de 
maturidade em seu processo de software. Os cinco níveis de maturidade são: (1) 
Inicial: processo imprevisível e sem controle. (2) Repetível: processo disciplinado. (3) 
Definido: processo consistente e padronizado. (4) Gerenciado: processo previsível 
e controlado e (5) Otimização: processo aperfeiçoado continuamente.
O MPS. BR (Melhoria de Processo de Software Brasileiro) é um programa 
que foi criado para melhorar a capacidade de desenvolvimento de software nas 
empresas brasileiras voltados para médias e pequenas empresas e com baixo 
custo de implantação. 
MPS.BR possui as seguintes metas: (1) definir e implementar o Modelo de 
Referência para Melhoria de Processos de Software (MR mps); (2) criar cursos em 
diversos locais do país para capacitar e formar consultores do modelo; (3) credenciar 
instituições e centros tecnológicos capacitados a implementar e avaliar o modelo 
com foco em grupo de empresas. 
Os sete níveis de maturidade do MPS.Br são: (G) Parcialmente gerenciado: 
inicia o gerenciamento de requisitos e projetos; (F) Gerenciado: inclui medições, 
gerência de configurações e garantia de qualidade; (E) Parcialmente definido: inclui 
treinamento, adaptação de processos para gerência de projetos; (D) Largamente 
definido: envolve teses e integração de produto; (C) Definido: gerência de riscos; (B) 
Gerenciado quantitativamente: avalia o desempenho dos processos e a gerência 
quantitativa dos mesmos; e (A) em otimização: preocupação com a inovação e 
análise de causas. (ZANCHETT, 2015).
Segundo Franciscani e Pestili (2015), existem medições entre os modelos, 
e as comparações entre eles podem ser visualizadas no quadro a seguir. 
Informática em Foco
19
Quadro 2 – Comparativo entre os Modelos CMMI e MPS.Br
CMMI MPS.BR
O modelo de Qualidade CMMI é 
reconhecido internacionalmente.
O MPS.BR é mais conhecido 
nacionalmente e na América Latina.
O modelo CMMI envolve um grande 
custo na avaliação e certificação do 
modelo.
No MPS.BR o custo da certificação é 
mais acessível.
No CMMI é necessário investir tempo, 
geralmente para se chegar aos níveis 
de maturidade mais altos.
No MPS.BR as avaliações são 
bienais.
O CMMI tem foco global voltado para 
empresas de maior porte.
MPS.BR é um modelo criado em 
função das médias e pequenas 
empresas.
O CMMI possui cinco níveis de 
maturidade por estágio e seis na 
contínua.
MPS.BR possui sete níveis de 
maturidade, onde a implementação é 
mais gradual.
O CMMI é aceito como maturidade 
para licitações.
O MPS.BR é o aceito como 
maturidade para licitações.
O CMMI torna as empresas 
competitivas internacionalmente.
O MPS.BR não torna as empresas 
competitivas internacionalmente.
O CMMI não utiliza contrato conjunto 
de empresas.
No MPS.BR pode acontecer contrato 
cooperado em grupo de empresas 
que queiram a certificação.
Implementação mais complexa. Implementação mais simples.
Desenvolvido pelo Software 
Engineering Institute – SEI em 1992.
Desenvolvido por algumas instituições 
brasileiras em 2003.
FONTE: Franciscani e Pestili (2015)
Informática em Foco
20
10 MÉTODOS ÁGEIS
As Metodologias Ágeis de Desenvolvimento de Software são indicadas como 
sendo uma opção às abordagens tradicionais para desenvolver softwares: produzem 
pouca documentação, é recomendado documentar somente o que será útil. Em 
essência, as Metodologias Ágeis foram desenvolvidas com o objetivo de vencer 
as fraquezas percebidas e reais da Engenharia de Software. (PRESSMAN, 2010). 
Segundo Souza (2015), os doze princípios do Manifesto Ágil são:
1. Garantia da satisfação do consumidor com entrega rápida e contínua de 
softwares funcionais. 
2. Mudanças de requisitos, mesmo no fim do desenvolvimento, ainda são 
bem-vindas. 
3. Frequentemente são entregues softwares funcionais (semanas, ao invés 
de meses). 
4. Desenvolvedores e pessoas relacionadas aos negócios devem trabalhar, 
em conjunto, até o fim do projeto. 
5. Construir projetos com indivíduos motivados, dar-lhes ambiente e suporte 
necessários e confiar que farão seu trabalho. 
6. Uma conversa face a face é o método mais eficiente e efetivo de transmitir 
informações para e dentro de uma equipe de desenvolvimento. 
7. Software em funcionamento é a principal medida de progresso. 
8. Desenvolvimento sustentável, de modo a manter um ritmo constante 
indefinidamente. 
9. Atenção contínua para com a excelência técnica e para com bons projetos 
aumenta a agilidade. 
10. Simplicidade – a arte de maximizar a quantidade de trabalho não efetuado 
– é essencial. 
11. As melhores arquiteturas, requisitos e projetos emergem de equipes 
auto-organizáveis. 
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais 
eficiente.
Informática em Foco
21
Entre todos os métodos ágeis podem-se citar como exemplo o Scrum e o 
Extreme Programming.
10.1 Scrum
Scrum é um método ágil de desenvolvimento de software criado por Jeff 
Sutherland e sua equipe no início de 1990. O Scrum considerauma abordagem mais 
humana ao solucionar os problemas existentes no desenvolvimento de software. 
Ao invés de desperdiçar tempo criando documentações extensas e detalhadas que 
as pessoas acabam não lendo minuciosamente, no Scrum as equipes trabalham 
com Sprints. São realizadas reuniões curtas onde o time verifica quais as decisões 
que devem ser tomadas e os recursos do product backlog que entram nos sprints. 
Elas também decidem quem trabalha nos sprints e quanto tempo dura cada tarefa. 
(DIMES, 2014).
O Scrum serve como fundamento para um projeto complexo, não ditando 
regras que devem ser estritamente seguidas, mas que podem ser personalizadas 
conforme a necessidade da equipe, servindo como base para uma gerência de 
sucesso.
O Scrum é um método orientado a iterações, sendo elas chamadas 
de Sprints. As entradas de sprints ocorrem normalmente uma vez por mês. Os 
requisitos e funcionalidades a serem desenvolvidas em um determinado projeto 
são armazenados em uma lista conhecida como Product Backlog. Ao iniciar-se um 
Sprint, é realizada uma reunião de planejamento, na qual o Product Owner dita quais 
as principais funcionalidades a serem implementadas e à equipe as atividades que 
será capaz de produzir. As funcionalidades que serão implementadas em um Sprint 
são removidas do Product Backlog e alocadas no Sprint Backlog.
A cada dia é realizada uma reunião, analisando o que foi produzido no dia 
anterior e o que será produzido no dia atual. Essa reunião é chamada de Daily 
Scrum e acontece normalmente no início da manhã. 
Ao fim de um Sprint, a equipe apresenta os requisitos e funcionalidades 
desenvolvidas em uma Sprint Review Meeting. Após uma retrospectiva, a equipe 
de desenvolvimento passa para o planejamento do próximo Sprint. 
Informática em Foco
22
A divisão de tarefas no Scrum baseia-se em Sprints e Reuniões Diárias. O 
Sprint é o ciclo em que diversas atividades precisam ser feitas e entregues no final 
para que possam ser entregues para o cliente, possuem duração fixa, normalmente 
de duas a quatro semanas, mas podem ser adaptadas de acordo com a necessidade 
da empresa, desde que mantenha a entrega constante. 
Para ajudar a manter o time atualizado, é comum no Scrum que todos os 
dias, no mesmo horário, seja realizada uma breve reunião em pé, que consiste em 
três pequenas perguntas: “O que fiz ontem em relação ao projeto?”, “O que vou 
fazer hoje em relação ao projeto?”, “Existe algum impedimento para que a meta do 
Sprint seja alcançada?”. Ao responder estas perguntas, o time saberá como está 
indo o andamento do projeto.
10.2 Extreme Programming
A metodologia de desenvolvimento Extreme Programming (XP) é uma 
metodologia baseada em comportamentos e atitudes, tem foco em agilidade de 
equipes e qualidade de projetos.
Sommerville (2011) afirma que nesse método a diferença está na forma 
como o sistema é testado. Não existe especificação do sistema que possa ser usada 
por uma equipe de teste externa. Para evitar problemas nos testes, a abordagem 
XP enfatiza a importância dos testes do programa, incluindo um foco de testes que 
reduz as chances de erros não identificados na versão atual do sistema.
A Programação Extrema valoriza o trabalho em equipe, desenvolvedores, 
administradores e clientes são todos iguais e todos precisam estar dispostos a ajudar 
quando necessário. Portanto, sua principal característica é a PROGRAMAÇÃO 
EM PARES.
Baseia-se em cinco princípios fundamentais: comunicação, simplicidade, 
feedback, respeito e coragem e em diversas regras simples, além das já definidas 
pelo desenvolvimento ágil: o código deve ser escrito usando a técnica de 
programação em par, todo código deve ter testes unitários, o tempo deve ter um bom 
espaço para trabalhar, um novo teste será criado quando um bug for encontrado, 
entre outras regras específicas.
Informática em Foco
23
Conforme destacado por Souza (2015), o Extreme Programming utiliza a 
Orientação ao Objeto como paradigma de desenvolvimento, onde inclui um conjunto 
de regras e práticas com base nas seguintes atividades: Planejamento, Projeto, 
Codificação e Teste. No planejamento é realizada a criação de um conjunto de 
“histórias de usuários” descrevendo as características e funcionalidades requeridas 
pelo software que será construído, estas histórias (semelhantes aos casos de uso) 
são escritas pelos clientes e colocadas em cartões de indexação, então o cliente 
atribui uma prioridade a cada história e os desenvolvedores analisam cada história e 
atribuem um custo a cada uma delas, com base em número de semanas necessárias 
para o seu desenvolvimento. Se a história precisar de mais de três semanas para 
desenvolvimento, é solicitado ao cliente que ela seja dividida em histórias menores 
e, por fim, com o avanço do projeto, o cliente pode adicionar novas histórias, mudar 
a sua prioridade, subdividi-las e eliminá-las.
11 TESTES DE SOFTWARE
Sommerville (2011) destaca que o teste de software serve para evidenciar 
que o programa faz o que ele realmente deve fazer e para evidenciar os defeitos 
que existem antes do uso. No processo de teste existem dois objetivos distintos, 
que são: demonstrar que o software atende seus requisitos e descobrir em que 
situação o software se comporta de forma incorreta.
O teste busca descobrir a maior quantidade de defeitos possível, é 
importante saber onde os defeitos podem estar. Saber como os defeitos são criados 
nos dá pistas sobre onde procurá-los durante o teste do sistema (PFLEEGER, 2004).
A tarefa de efetuar testes, em software, foi considerada secundária por 
muito tempo. Geralmente, era vista como castigo para o programador ou como uma 
tarefa, onde não se deveria gastar muito tempo e investimentos. O tema esteve 
relegado a segundo plano e, até alguns anos atrás, não se encontrava muita literatura 
sobre o assunto. Este é um paradigma que vem mudando no mundo moderno de 
desenvolvimento de software. Um dos testes, que ajudou a mudar este paradigma, 
é o teste de aceitação, que tem como principal característica verificar o sistema, em 
relação aos seus requisitos originais e às necessidades atuais do usuário.
Informática em Foco
24
O teste de software constitui-se em uma etapa importante no ciclo de 
desenvolvimento de software. Uma das características mais importantes de um 
conjunto de testes de software, adequadamente planejados, é ter alta probabilidade 
de detectar erros no programa sob teste (ZANCHETT, 2015). 
Os testes de software são executados usando os procedimentos e 
documentos de script de teste. Para que a fase de execução de teste seja realizada 
com sucesso deve(m) ser executado(s) os casos de teste.
A validação é verificar se o software tem todos os itens necessários para 
atender ao cliente. O sistema que será entregue ao cliente vai ajudá-lo e o mesmo 
vai ficar contente. Para a validação a pergunta é: "Fizemos o software correto?"
A verificação fica escondida do usuário final, em comparação à validação. 
Os encarregados devem buscar e prever erros entre os requisitos. Verificar se todas 
as etapas de desenvolvimento conforme planejado foram realizadas e da melhor 
forma. Para a verificação a pergunta é: "Fizemos o software corretamente?".
Realizar os testes nada mais é que entrar com vários dados de maneira 
diferente e analisar os dados de saída e seu comportamento. Aqui são realizados 
vários tipos de teste, como, por exemplo, teste de interface, de regras de negócio 
e de carga. Para testar a pergunta é: "O software tem defeito?".
Teste de software é o processo que visa sua execução de forma controlada, 
com o objetivo de avaliar o seu comportamento baseado no que foi especificado. 
A execução dos testes é considerada um tipo de validação.
Na área de testes, os tipos de Teste Caixa Preta, que visam verificar a 
funcionalidade e a aderência aos requisitos, em uma ótica externa ou do usuário, sem 
se basear em qualquer conhecimento do código e da lógica interna do componente 
testado, e os de Teste Caixa, que visam avaliaras cláusulas de código, a lógica 
interna do componente codificado, as configurações e outros elementos técnicos.
Os tipos de testes conforme seus níveis são:
Informática em Foco
25
• Teste de Unidade: o teste é realizado em cada componente do programa 
isoladamente, no qual se verifica se ele funciona de forma adequada aos tipos de 
entradas esperadas.
• Teste de Integração: tem o objetivo de provocar falhas associadas às 
interfaces entre os módulos quando esses são integrados para construir a estrutura 
do software que foi estabelecida na fase de projeto.
• Teste de Sistema: avalia o software em busca de falhas utilizando o mesmo 
como se fosse um usuário final. 
• Teste de Aceitação: é realizado em conjunto com os clientes e nele o 
sistema é verificado em comparação com a descrição dos requisitos do cliente.
Segundo Zanchett (2015), as práticas de desenvolvimento na área de 
testes são:
• TDD – Test - Driven Development: o Desenvolvimento Guiado a Testes; se 
escreve primeiramente os testes para posteriormente escrever o código, o processo 
aborda os parâmetros Red, Green e Refactor: (1) Escrever um teste, mesmo sem 
ter escrito o código real a ser testado; (2) Executar os testes e acompanhar a falha 
(Red); (3) Escrever a funcionalidade do sistema que irá ser testada; (4) Testar 
novamente, agora para passar (Green); (5) Refatorar a funcionalidade e escrever 
por completo (Refactor); (6) Próxima estória ou caso de uso e iniciar novo teste.
• DDD – Domain - Driven Design: no desenvolvimento guiado ao domínio 
o foco é no Domínio do Software, no propósito que o software deve atender, é a 
automatização de um processo de negócio. O DDD traz abordagens de como fazer 
isto, como atender um domínio complexo de informações. Qualquer abordagem de 
DDD é muito bem aceita numa metodologia ágil.
• BDD – Behavior - Driven Development: o desenvolvimento guiado por 
comportamento, associa os benefícios de uma documentação formal, escrita 
e mantida pelo negócio, com testes de unidade que demonstram que essa 
documentação é efetivamente válida. Na prática, isso garante que a documentação 
deixa de ser um registro estático, que se converte em algo gradualmente 
ultrapassado, em um artefato vivo que reflete constantemente o estado atual de 
um projeto.
• ATDD - Acceptance Test - Driven Development: o desenvolvimento guiado 
por testes de aceitação; o trabalho ocorre em resposta a testes de aceitação. O 
ATDD pode ser considerado como análogo ao TDD. 
Informática em Foco
26
• FDD - Feature Driven Development: desenvolvimento guiado por 
funcionalidades, serve para gerenciar e desenvolver projetos de software através de 
um conjunto de atividades simplificadas, de maneira a estimular o compartilhamento 
do conhecimento acerca do software e da criação de bons códigos.
Informática em Foco
27
CAPÍTULO 1I
LÓGICA, ALGORITMOS E ESTRUTURA DE DADOS
APRESENTAÇÃO
Caro(a) acadêmico(a), neste capítulo vamos relembrar alguns dos principais 
conceitos relacionados a uma das disciplinas essenciais ao nosso curso de Análise 
e Desenvolvimento de Sistema, a disciplina de Lógica, Algoritmos e Estrutura de 
Dados. Apresentaremos de forma condensada os temas que são os pilares desse 
assunto que introduz os alunos à lógica. Reforçamos que esse material visa oferecer 
ao acadêmico um conteúdo importante para sua vida acadêmica e profissional. 
Iniciaremos os estudos empregando o máximo de atenção e foco para 
que os resultados sejam os melhores possíveis, contribuindo para o incremento e 
fixação dos seus conhecimentos!
Prof. Elton Giovani Gretter 
Me. Greisse Moser Badalotti
1 LÓGICA DE PROGRAMAÇÃO
Dentre as disciplinas essenciais para a formação do profissional da área 
de Análise e Desenvolvimento de Sistemas destaca-se a Lógica, a qual, segundo 
Bastos (1991), é a disciplina que trata das formas de pensamento, da linguagem 
descritiva do pensamento, das leis da argumentação e raciocínios corretos, dos 
métodos e dos princípios que regem o pensamento humano.
De maneira geral, a palavra lógica encontra-se relacionada a uma forma 
distinta de raciocinar, a fim de justificar determinada situação, podendo ser 
classificada em Lógica Aristotélica, de Argumentação, Matemática, Proposicional e 
Informática em Foco
28
de Programação, sendo esta última a de maior relevância para os nossos estudos 
neste momento.
A lógica de programação é essencial no desenvolvimento dos programas 
e sistemas informáticos (pois ela define o encadeamento lógico para esse 
desenvolvimento), os quais são denominados de algoritmos e consistem em uma 
sequência lógica de instruções para que a função seja executada.
Figura 1 – Exemplo de lógica de programação
Fonte: O autor
Segundo o Dicionário Aurélio (2010), algoritmo é: “Sequência de raciocínios 
ou operações que oferece a solução de certos problemas”. Nesse sentido, um 
algoritmo pode ser entendido como uma sequência de passos ou instruções, que 
têm por objetivo resolver determinado problema, desde situações mais rotineiras do 
cotidiano, como a receita para fazer um bolo, até situações mais complexas, como 
o desenvolvimento de um sistema computacional. Todavia, independentemente 
dos objetivos que se busca alcançar, para atingi-los há uma cadeia de passos que 
devem ser executados em uma sequência bem definida. 
Tomaremos por base que você, acadêmico, já detém os conhecimentos 
básicos sobre o desenvolvimento dos algoritmos e, portanto, abordaremos um 
conteúdo mais avançado, como: Estruturas de Seleção; Estruturas de Repetição; 
Funções Recursivas; Matrizes Multidimensionais; Listas Encadeadas; Pilhas, Filas 
e Pesquisa Binária. 
Informática em Foco
29
1.1 ESTRUTURAS DE SELEÇÃO
As estruturas de seleção permitem que um algoritmo tome caminhos 
distintos conforme determinada situação, e esses caminhos poderão executar 
as mais variadas instruções. Segundo Kochanski e Andrietti (2005, p. 49): “[...] a 
estrutura de seleção permite a definição de uma condição para que um conjunto 
de instruções seja ou não executado. Por esse motivo, as estruturas de seleção 
também são conhecidas como estruturas condicionais”.
1.1.1 “Se-então-senão”
O comando SE-ENTÃO com base no resultado de uma condição, que 
pode retornar um valor Verdadeiro ou Falso, irá definir o fluxo do algoritmo, ou seja, 
estabelece qual bloco de instruções deve ou não ser executado. Este comando 
pode se apresentar de duas formas distintas, no entanto, sua função é a mesma: 
decidir por uma ou por outra alternativa.
SE (condição) ENTÃO
Instruções a serem executadas quando a condição for VERDADEIRA
SENÃO
Instruções a serem executadas quando a condição for FALSA>
FIM-SE
Importante ressaltar que o bloco de código SENÃO é opcional, sendo muito 
comum encontrarmos instruções de decisão apenas com SE-ENTÃO, sem o bloco 
SENÃO.
Vejamos a utilização do comando em um caso prático.
Informática em Foco
30
algoritmo CalculaMedia;
var
 n1; n2; media : real;
inicio
 escreva (“Informe a primeira nota: ”);
 leia (n1);
 escreva (“Informe a segunda nota: ”);
 leia (n2);
 media := (n1 + n2) / 2
 SE (media >= 7) ENTÃO
 escreva (“O aluno está aprovado”)
 SENÃO
 escreva (“O aluno está reprovado”)
 FIM_SE
fim.
1.1.2 Seleção Encadeada
No exemplo visto no item anterior precisávamos verificar apenas duas 
situações: se o aluno havia sido Aprovado ou Reprovado com base na média 
obtida pelo mesmo. Todavia, existem casos em que haverá mais situações para 
serem analisadas, como, por exemplo, se o aluno está “Aprovado”, “em Exame” 
ou “Reprovado”, ocasião em que será necessária a utilização de uma Seleção 
Encadeada, ou seja, um comando SE-ENTÃO subordinado a outro comando SE-
ENTÃO.
Vamos estabelecer as regras e verificar como ficaria a estrutura deste 
algoritmo:
Se a média for maior ou igual a 6.5, o aluno está aprovado. 
Se a média for maior ou igual a 5.0 e menor que 6.5, o aluno está em exame.
Se a média for menor do que 5.0, o aluno está reprovado.
Informática em Foco
31
01
02
03
04
05
06
07
0809
10
11
12
13
14
15
16
17
18
19
algoritmo CalculaMedia;
var
 n1; n2; media : real;
inicio
 escreva (“Informe a primeira nota: ”);
 leia (n1);
 escreva (“Informe a segunda nota: ”);
 leia (n2);
 media := (n1 + n2) / 2
 SE (media >= 6.5) ENTÃO
 escreva (“O aluno está aprovado”)
 SENÃO
 SE (media >= 5) ENTÃO
 escreva (“O aluno está em exame”)
 SENÃO
 escreva (“O aluno está reprovado”)
 FIM_SE
 FIM_SE
fim.
Sempre que um bloco de instruções dentro de uma estrutura de seleção 
for executado, os demais blocos serão desconsiderados. Vejamos um exemplo: 
Se a média for 8.0, ou seja, maior do que 6.5, será executado o bloco da linha 11. 
Depois de executar esse bloco, a execução do algoritmo passará para a linha 18, 
ou seja, os blocos das linhas 12 a 17 não serão executados.
Vejamos outras situações:
Se a média for 5.5: Ao verificar a condição SE (media >= 6.5) obteremos 
como resultado o valor falso, situação em que será executado o primeiro SENÃO 
(linha 12). Ao executar o bloco de instruções deste SENÃO, haverá uma nova 
condição a ser verificada, SE (media >= 5). Nesse caso, o resultado será verdadeiro, 
devendo executar o bloco de instruções logo abaixo, exibindo a mensagem “O 
aluno está em exame”. 
Informática em Foco
32
Se a média for 4,0: Ao verificar a condição SE (media >= 6,5) o resultado 
será falso, situação em que será executado o primeiro SENÃO (linha 12). Ao executar 
o bloco de instruções deste SENÃO, haverá uma nova condição a ser verificada, 
SE (media >= 5), onde, novamente, o resultado será falso. A execução avançará 
para o próximo SENÃO (linha 15), que executará o bloco de instruções, exibindo a 
mensagem “O aluno está repro
1.2 ESTRUTURAS DE REPETIÇÃO
As estruturas de repetição, também conhecidas por laços ou looping, 
possibilitam que uma sequência de comandos seja executada reiteradas vezes, 
até que determinada condição de interrupção seja atendida. Dentre os tipos de 
estruturas de repetição destacam-se: Enquanto-faça; Para-faça e Repita-até, os 
quais serão aprofundados na sequência.
1.2.1 Enquanto-faça
Essa estrutura de repetição é também conhecida por loop pré-testado, pois 
a condição para sua execução é verificada logo no início, ou seja, se a condição 
resultar falso, as instruções que estão dentro do bloco não serão executadas 
nenhuma vez. 
Ressalta-se que nessa estrutura de repetição, toda vez que a execução 
chegar ao fim do bloco, retornará para o início da própria estrutura e verificará 
novamente se a condição é verdadeira. Se for, executa novamente o referido bloco 
de instruções.
Vamos a um exemplo, onde o bloco de instruções será executado diversas 
vezes, até que o usuário informe que não deseja mais continuar.
Informática em Foco
33
01
02
03
04
05
06
07
08
09
10
11
12
13
14
Algoritmo EnquantoFaca;
var
 continuar: Caractere;
Inicio
 Escreva (‘Informe “s” para continuar ou outro caractere para sair: ’);
 Leia (continuar);
 Enquanto (continuar = ‘s’) faça
 Inicio
 Escreva (‘Você quis continuar!’);
 Escreva (‘Informe “s” para continuar ou outro caractere para sair: ’);
 Leia (continuar);
 Fim
 Escreva (‘Você não quis continuar!’);
Fim.
1.2.2 Para-faça
A estrutura Para-faça é a mais simples das estruturas de repetição, uma vez 
que permite que um bloco de instruções seja executado reiteradas vezes, conforme 
quantidade predeterminada. Portanto, deve-se saber o número de vezes que o bloco 
de instruções será executado, definindo-se um limite inferior e outro superior, além 
da variável de controle, a qual será incrementada ou decrementada, conforme a 
necessidade. Vejamos um exemplo:
01
02
03
04
05
06
07
08
09
Algoritmo ParaFaca;
var
 i: Inteiro;
Inicio
 Para i := 1 até 10 faça
 Inicio 
 Escreva (i);
 Fim
Fim.
Informática em Foco
34
1.2.3 Repita-até
É uma estrutura de repetição que tem por função repetir um determinado 
bloco de comandos até que a condição se torne verdadeira. Ao contrário das 
demais estruturas de repetição, o Repita-até testa a condição somente ao final, 
executando, desta forma, pelo menos uma vez o bloco de instruções nele contido. 
Vejamos um exemplo:
01
02
03
04
05
06
07
08
09
10
Algoritmo RepitaAte;
var
 Idade : Inteiro;
Inicio
 Repita
 Escreva (‘Qual a sua idade: ’);
 Leia(Idade);
 Escreva(‘A idade informada é: ‘, Idade);
 Até (Idade = 0);
Fim.
1.3 VETORES UNIDIMENSIONAIS
Como se sabe, a variável é um “local na memória do computador”, que 
recebe um nome e possibilita o armazenamento de um valor por vez. Contudo, 
algumas situações exigem o armazenamento de vários valores concomitantemente, 
ocasião em que o desenvolvedor poderá fazer uso dos vetores, ou seja, uma variável 
dividida em vários “compartimentos”, onde cada compartimento é identificado por 
meio de um número, referente à posição de uma determinada informação no vetor 
em questão, sendo que o número de cada posição é denominado de índice.
Vejamos a representação visual de como é estruturado um vetor. Para 
tanto, tomaremos como exemplo um vetor que possibilite o armazenamento de 
vários Nomes.
Informática em Foco
35
Figura 2 – Representação gráfica do vetor unidimensional
FONTE: O autor (2016)
Conforme representado no exemplo acima, temos uma única “caixa”, 
denominada Nomes com vários “compartimentos” numerados, sendo que cada um 
permite apenas a inserção de um único elemento, mas que deverão ser do mesmo 
tipo de dados, ou seja, se a variável vetor for do tipo Caractere, cada compartimento 
receberá apenas valores do tipo Caractere, se a variável for do tipo Inteiro, todos 
os compartimentos deverão receber valores do tipo Inteiro.
A utilização de vetores em nossos algoritmos implicará consequentemente 
na utilização de estruturas de repetição, com vistas a possibilitar a navegação, tanto 
para a leitura quanto para a inserção dos elementos em cada compartimento do 
vetor. Vejamos um exemplo:
Informática em Foco
36
01
02
03
04
05
06
07
08
09
10
11
Algoritmo Vetor_ParaFaca;
var
 Nomes : Vetor [1..4] de Caractere;
 i : Inteiro;
Início
 Para i := 1 até 4 faça
 Início
 Escreva (‘Informe o ‘,i,’° nome: ‘);
 Leia(Nomes[i]);
 Fim
Fim.
1.4 MATRIZES
Matriz (array multidimensional) é um vetor de vetores. No nosso exemplo 
anterior, imagine uma matriz para armazenar quatro notas para cada um dos nomes. 
Ou seja, um vetor de quatro posições, e em cada posição do vetor há outro vetor 
com quatro posições, sendo que cada item do vetor (matriz) é acessado por um 
número chamado de índice.
Para a melhor compreensão do conceito de matrizes, veja o algoritmo 
abaixo, o qual tem por finalidade permitir a inclusão de quatro nomes e de quatro 
notas para cada nome e, ao final, apresentar a média de cada um.
01
02
03
04
05
06
07
08
Algoritmo Media
var
 nomes: vetor [1..4] de caractere;
 notas: vetor [1..4,1..4] de real;
 medias: vetor [1..4] de real;
 i, j: inteiro
Inicio
Informática em Foco
37
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 //Leitura dos nomes e das notas
 Para i := 1 ate 4 faça
 Inicio 
 Escreva (“Informe o nome da posição ”, i, “: ”);
 Leia (nomes[i]);
 Para j := 1 ate 4 faça
 Inicio
 Escreva (“Informe a nota ”, j, " para o nome ", nomes[i], “: ”);
 Leia (notas[i, j])
 Fim 
 
 //Cálculo das médias
 medias[i] := (notas[i, 1] + notas[i, 2] + notas[i, 3] + notas[i, 4]) / 4
 Fim
 
 //Apresentação dos resultados
 Para i := 1 ate 5 faça
 Inicio 
 SE medias[i] >= 6 ENTAO
 ESCREVA (“O aluno ”, nomes[i], ” foi aprovado com as notas (“, notas[i 
1], ", ", notas[i, 2], ", ", notas[i, 3], ", ", notas[i, 4], ") e média: ", medias[i])
 SENAO
 ESCREVA (“O aluno ”, nomes[i], ” foi reprovado com as notas (“, notas[i, 
1], ", ", notas[i, 2], ", ", notas[i, 3], ", ", notas[i, 4], ") e média: ", medias[i])
 Fim
Fim.
1.5 LISTAS ENCADEADAS
Na lista encadeada, cada elemento inserido na estrutura será alocado de 
forma dinâmica na memória. Consequentemente, o espaço total de memória utilizado 
pela estrutura será proporcional ao número de elementos nela armazenados, 
diferentemente do que ocorre em um vetor,que reservará o espaço físico na 
memória, independentemente do número de elementos inseridos.
Informática em Foco
38
De acordo com Deitel e Deitel (2003, p. 62):
Criar e manter estruturas de dados dinâmicas exige alocação 
dinâmica de memória – a capacidade de um programa obter 
mais espaço de memória durante a execução para armazenar 
novos nodos e liberar espaço não mais necessário. [...] O limite 
para alocação dinâmica de memória pode ser tão grande quanto 
à quantidade de memória física disponível no computador ou 
a quantidade de espaço disponível em disco em um sistema 
de memória virtual. Frequentemente, os limites são muito 
menores, porque a memória disponível do computador deve 
ser compartilhada entre muitos aplicativos.
Outra característica interessante do processo de alocação dinâmica é que 
não podemos afirmar que os elementos armazenados na lista ocuparão um espaço 
de memória contíguo, isto quer dizer um ao lado do outro. Logo, não há possibilidade 
de acesso direto aos elementos da lista. Para que seja possível percorrer todos 
os elementos da lista, devemos explicitamente armazenar o encadeamento dos 
elementos. Desta forma, armazena-se a informação de cada elemento juntamente 
com um ponteiro para o próximo elemento da lista.
A figura a seguir ilustra o arranjo da memória de uma lista encadeada.
Figura 3 – Representação do arranjo da memória de uma lista encadeada 
FONTE: O autor
A estrutura consiste numa sequência encadeada de elementos, comumente 
denominada de nós da lista. A lista é representada por um ponteiro para o primeiro 
elemento (ou nó), a partir do qual se pode ascender ao segundo, seguindo o 
encadeamento, e assim por diante. O último elemento da lista aponta para NULL, 
indicando que não há mais elementos na lista.
Informática em Foco
39
Para exemplificar a implementação de listas encadeadas em Java, vamos 
considerar um exemplo simples em que queremos armazenar o nome e o peso 
de uma pessoa numa lista encadeada. O nó da lista pode ser representado pela 
estrutura a seguir:
Figura 4 – Estrutura em Java representando o nó da lista encadeada
FONTE: O autor
A classe PessoaLista trata-se de uma estrutura autorreferenciada, pois, além 
dos campos que armazenam as informações (nome e peso), há o atributo (prox) 
que é um ponteiro para uma próxima estrutura do mesmo tipo. Normalmente, o 
acadêmico fica confuso em relação a isso, como se esse código fosse gerar um laço 
infinito, ou uma recursão infinita. No entanto, não é o caso, já que a declaração do 
atributo prox é apenas uma referência, que não cria uma instância de PessoaLista 
na memória, apenas criando uma referência à referida classe já instanciada!
Figura 5 - Representação da lista de pessoas
FONTE: O autor
Importante destacar que, embora a figura acima represente as pessoas 
uma ao lado da outra, na memória, provavelmente elas estejam em regiões bem 
distintas, contudo, cada uma delas sabe dizer em que local se encontra a próxima 
pessoa, já que há a referência ao próximo pelo atributo prox.
Informática em Foco
40
O código-fonte exibido acima não é a melhor forma de implementar uma 
lista, tendo em vista que há uma confusão de responsabilidades, onde a classe 
PessoaLista, além de armazenar informações sobre uma pessoa, armazena também 
uma lista de pessoas. Logo, manipulá-la pode ficar estranho e muito trabalhoso, já 
que há a necessidade de manter constantemente uma referência para a primeira 
pessoa na memória em algum outro lugar, o que também pode ser confuso, além 
de violar o conceito de coesão.
Ademais, sendo necessário criar uma lista encadeada de produtos, por 
exemplo, ao invés de reaproveitar o código existente, prática comum na programação 
orientada a objetos, será necessário criar uma nova classe, denominada 
ProdutoLista, semelhante com a PessoaLista. Neste sentido, para criar uma estrutura 
mais funcional, utiliza-se uma classe separada como “nós”, evitando mesclar a 
classe de dados (Pessoa) da nossa estrutura.
1.6 PILHAS
A estrutura de dados denominada pilha admite a remoção e inserção de 
novos elementos de forma dinâmica na memória, sujeitando-se à seguinte regra 
de operação: o elemento a ser removido será sempre o que está na estrutura há 
menos tempo.
A pilha é uma versão limitada de uma lista encadeada – novos 
nodos podem ser adicionados a uma pilha e removidos de uma 
pilha apenas na parte superior (topo). Por essa razão, a pilha 
é conhecida como uma estrutura de dados último a entrar, 
primeiro a sair (last-in, first-out - LIFO). O membro de link do 
nodo inferior (isto é, o último) da pilha é configurado como nulo 
para indicar a base da pilha (DEITEL; DEITEL, 2003, p. 56).
Neste sentido, as pilhas têm muitas aplicações interessantes, principalmente 
na análise de expressões e sintaxe, como no caso das calculadoras que utilizam a 
Notação Polonesa Reversa, que implementam a estrutura de dados de pilha para 
expressar seus valores, podendo ser representadas de forma prefixa, pós-fixa ou 
infixa, ou ainda, os compiladores de muitas linguagens de programação ao realizar 
a análise sintática de expressões e blocos de programas.
Informática em Foco
41
Existem duas funções que se aplicam a todas as pilhas: PUSH, que insere 
um dado no topo da pilha, e POP, que remove o item no topo da pilha, conforme 
exemplo que segue abaixo.
Figura 6 – Representação gráfica de uma Pilha
FONTE: O autor
No dia a dia, estamos acostumados com as filas em diversos lugares: 
nos bancos, nos mercados, nos hospitais, nos cinemas, entre outros. As filas 
são importantes, pois elas determinam a ordem de atendimento das pessoas.
As pessoas são atendidas conforme a posição delas na fila. O próximo 
a ser atendido é o primeiro da fila. Quando o primeiro da fila é chamado para 
ser atendido a fila “anda”, ou seja, o segundo passa a ser o primeiro, o terceiro 
passa a ser o segundo e assim por diante até a última pessoa.
Normalmente, para entrar em uma fila, uma pessoa deve se colocar na 
última posição, ou seja, no fim da fila. Desta forma, quem chega primeiro tem 
prioridade. Assim como Listas e Pilhas, as Filas são estruturas de dados que 
armazenam os elementos de maneira sequencial.
As estruturas de dados denominadas Filas são estruturas do tipo FIFO 
(first-in, first-out), ou seja, o primeiro elemento a ser inserido será o primeiro a 
ser retirado, assim sendo, adiciona-se itens no fim e remove-se do início.
1.7 FILAS
FONTE: Caelum (2014, p. 2)
Informática em Foco
42
A fila é semelhante a uma fila de caixa em um supermercado – a 
primeira pessoa na fila é atendida primeiro e os outros clientes 
entram na fila apenas no final e esperam ser atendidos. Os 
nodos da fila são removidos apenas do início (ou cabeça) da 
fila e são inseridos somente no final (ou cauda) da fila (DEITEL; 
DEITEL, 2003, p. 72).
Segundo Deitel e Deitel (2003), as filas podem ser usadas em diversas 
aplicações computacionais, haja vista que a maioria dos computadores tem apenas 
um único processador, logo, apenas um aplicativo pode ser atendido por vez. Desta 
forma, os pedidos dos outros aplicativos são colocados em uma fila, onde cada 
pedido avança gradualmente para o início da fila à medida que os aplicativos vão 
sendo atendidos.
São exemplos de uso de fila em um sistema:
o	Controle de documentos para impressão (spool de impressão).
o	Troca de mensagem entre computadores numa rede (pacotes de 
informações).
o	Solicitações de acesso a arquivos em uma rede.
1.8 ANÁLISE E TÉCNICAS DE ALGORITMOS
1.8.1 Divisão e Conquista
A técnica de divisão e conquista consiste em três passos básicos, quais 
sejam:
1. Divisão: Dividir o problema original em subproblemas menores.
2. Conquista: Resolver cada subproblema recursivamente.
3. Combinação: Combinar as soluções encontradas, compondo uma solução 
única para o problema original.
Informática em Foco
43
Para que a estratégica de divisão e conquista possa ser utilizada com 
sucesso deve ser possível decompor uma instância em subinstâncias;