Merged All

Gestão
de Requisitos
Créditos
Centro Universitário Senac São Paulo – Educação Superior a Distância
Diretor Regional Juliana Quitério Lopez Salvaia
Luiz Francisco de Assis Salgado Jussara Cristina Cubbo
Superintendente Universitário Kamila Harumi Sakurai Simões
e de Desenvolvimento Katya Martinez Almeida
Luiz Carlos Dourado Lilian Brito Santos
Luciana Marcheze Miguel
Reitor Mariana Valeria Gulin Melcon
Sidney Zaganin Latorre Mônica Maria Penalber de Menezes
Diretor de Graduação Mônica Rodrigues dos Santos
Eduardo Mazzaferro Ehlers Nathália Barros de Souza Santos
Rivia Lima Garcia
Diretor de Pós-Graduação e Extensão Sueli Brianezi Carvalho
Daniel Garcia Correa Thiago Martins Navarro
Gerentes de Desenvolvimento Wallace Roberto Bernardo
Claudio Luiz de Souza Silva Equipe de Qualidade
Luciana Bon Duarte Ana Paula Pigossi Papalia
Roland Anton Zottele Josivaldo Petronilo da Silva
Sandra Regina Mattos Abreu de Freitas Katia Aparecida Nascimento Passos
Coordenadora de Desenvolvimento Coordenador Multimídia e Audiovisual
Tecnologias Aplicadas à Educação Ricardo Regis Untem
Regina Helena Ribeiro
Equipe de Design Audiovisual
Coordenador de Operação Adriana Mitsue Matsuda
Educação a Distância Caio Souza Santos
Alcir Vilela Junior Camila Lazaresko Madrid
Professor Autor Carlos Eduardo Toshiaki Kokubo
Diego Martins Polla de Moraes Christian Ratajczyk Puig
Danilo Dos Santos Netto
Revisor Técnico Hugo Naoto Takizawa Ferreira
João Carlos Neto Inácio de Assis Bento Nehme
Técnico de Desenvolvimento Karina de Morais Vaz Bonna
Ozeas Vieira Marcela Burgarelli Corrente
Marcio Rodrigo dos Reis
Coordenadoras Pedagógicas Renan Ferreira Alves
Ariádiny Carolina Brasileiro Silva Renata Mendes Ribeiro
Izabella Saadi Cerutti Leal Reis Thalita de Cassia Mendasoli Gavetti
Nivia Pereira Maseri de Moraes Thamires Lopes de Castro
Otacília da Paz Pereira Vandré Luiz dos Santos
Equipe de Design Educacional Victor Giriotas Marçon
Alexsandra Cristiane Santos da Silva William Mordoch
Ana Claudia Neif Sanches Yasuraoka Equipe de Design Multimídia
Angélica Lúcia Kanô Alexandre Lemes da Silva
Anny Frida Silva Paula Cristiane Marinho de Souza
Cristina Yurie Takahashi Emília Correa Abreu
Diogo Maxwell Santos Felizardo
Fernando Eduardo Castro da Silva
Flaviana Neri
Francisco Shoiti Tanaka Mayra Aoki Aniya
Gizele Laranjeira de Oliveira Sepulvida Michel Iuiti Navarro Moreno
Hágara Rosa da Cunha Araújo Renan Carlos Nunes De Souza
Janandrea Nelci do Espirito Santo Rodrigo Benites Gonçalves da Silva
Jackeline Duarte Kodaira Wagner Ferri
João Francisco Correia de Souza
Gestão de Requisitos
Aula 01
Engenharia de Requisitos
Objetivos Específicos
• Compreender os valores e fundamentos da engenharia de requisitos.
Temas
Introdução
1 Engenharia de requisitos
2 Habilidades de um engenheiro de requisitos
3 Tipos de requisitos
4 Requisitos e modelos de processos
Considerações finais
Referências
Professor Autor
Diego Martins Polla de Moraes
Introdução
O objetivo desta aula é que o aluno possa compreender os valores e fundamentos da
engenharia de requisitos. Para percorrer este caminho, iremos apresentar inicialmente os
conceitos de “requisitos”, “stakeholders” e “engenharia de requisitos”.
De posse de tal conhecimento, explicaremos quais habilidades são esperadas de um

engenheiro de requisitos para que ele obtenha êxito em seus projetos de desenvolvimento
de software.
Na sequência, conceituaremos cada tipo de requisito a partir de exemplos práticos.
Por fim, apresentaremos os principais modelos de processo de desenvolvimento de

software, com o intuito de ressaltar como a engenharia de requisitos se vincula a cada um deles.
Ao fim desta aula, esperamos que o aluno conheça a importância da engenharia de

requisitos em um projeto de desenvolvimento de software.
A engenharia de requisitos é a uma das fases mais importantes da engenharia de software.
É necessário considerar que todas as etapas posteriores da construção de um software se
basearão nos requisitos definidos nessa fase. Erros no processo de requisitos resultarão em
falhas sucessivas em todas as fases posteriores do projeto de software (KERR, 2015).
Mas, afinal, o que é requisito?
Para o Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE, 2014), requisito é

essencialmente uma condição que deve estar presente em um software, com o objetivo de
resolver algum problema do mundo real ou permitir que um usuário alcance um objetivo.
A grande questão envolvida é que os engenheiros de requisitos não conhecem os

problemas de cada organização. Claro que ter noções de gestão e de ambiente organizacional
é essencial para o processo de trabalho, mas são as organizações que devem ter ciência de
suas necessidades de forma clara para que o analista de requisitos faça o seu trabalho, que é
coletar, especificar, validar e implantar sistemas que atendam às necessidades das empresas
contratantes (POHL; RUPP, 2011).
Para criar sistemas, todas as informações relevantes para o projeto devem ser fornecidas
pelos stakeholders, ou seja, os envolvidos no processo. Stakeholders são pessoas ou
organizações que têm influência (direta ou indireta) nos requisitos de um sistema (POHL;
RUPP, 2011).
Senac São Paulo - Todos os Direitos Reservados 3

Vale ressaltar que a maioria das pessoas que fornecerão as informações e os requisitos
para a criação de um programa nunca participou de um projeto de desenvolvimento de
software. São advogados, administradores, contadores, professores, médicos, ou seja,
profissionais das mais diversas áreas de atuação que serão envolvidos em uma fase
essencial do desenvolvimento de um projeto, trazendo as necessidades do mundo real
que se pretende resolver através do uso do software (SOMMERVILLE, 2011). Por isso,
é muito importante que o engenheiro de requisitos tenha capacidade analítica para
compreender quais são as condições necessárias para que o projeto se desenvolva de
maneira satisfatória.
Os requisitos não são de uma única pessoa ou área da organização. Eles tipicamente
são uma combinação emaranhada de necessidades de várias pessoas e de diferentes níveis
organizacionais que estão vinculados a um processo de trabalho. Outro fator preponderante
são as normas organizacionais e os requisitos legais que podem estar vinculados a essas
necessidades (POHL; RUPP, 2011).
A maioria das falhas de projetos de software está ligada à falta de requisitos ou à falha
nos requisitos definidos. Um fator corriqueiro que ocasiona tais erros é que os stakeholders
não informam detalhes que consideram óbvios, por fazer parte do seu dia a dia de trabalho,
mas que são totalmente desconhecidos para o engenheiro de requisitos. Para minimizar esses
problemas, a equipe de projeto deve deixar claras a importância e a função dos processos
de engenharia de requisitos. Os stakeholders devem ser envolvidos de forma plena, pois,
através da participação mais ativa nos processos de requisitos, a chance de sucesso aumenta
(KERTZNER, 2012).
Se os stakeholders têm pouca ou nenhuma experiência com software, uma forma

de minimizar e até eliminar falhas nos projetos pode ser a realização de workshop com
o grupo de envolvidos. O objetivo é demonstrar como o processo de desenvolvimento
de software funciona e qual a importância das informações repassadas por cada
profissional.
O workshop fará com que a engenharia de requisitos seja entendida pelos envolvidos
no projeto, e a chance de sucesso aumentará consideravelmente. Isso também fará com
que haja uma proximidade com os stakeholders, e eles provavelmente confiarão mais
no trabalho do engenheiro de requisitos após esse contato inicial (KERTZNER, 2012).

De acordo com o IEEE (2014), a engenharia de requisitos é o processo que envolve

elicitação, análise, especificação e validação de requisitos de software, bem como a gestão
de requisitos durante todo o ciclo de vida do produto de software. A seguir, detalhamos cada
uma das fases da engenharia de requisitos:
• Elicitação dos requisitos: é a fase que envolve o levantamento de informações para

identificação dos requisitos de um software.
Um fator comum na maioria dos projetos atuais é que o levantamento de requisitos está
vinculado a mudanças nos processos em vigor e também à implementação de um processo
de negócio que será viável somente se a solicitação demandada estiver funcionando. A
troca de uma solução já existente por outra nova quase sempre é problemática, pois os
requisitos fornecidos podem ser vinculados à solução atual com vícios antigos e, além disso,
os stakeholders podem se manter avessos à substituição. Já no caso da implantação de um
projeto que depende de uma ferramenta computacional para ser executado, o desafio é
delimitar as necessidades de uma situação que ainda não existe. Os stakeholders devem ser
treinados para terem capacidade de abstração e, assim, permitirem a discussão das soluções
com o engenheiro de requisitos.
• Documentação dos requisitos: os requisitos elicitados anteriormente serão

documentados de acordo com um padrão de descrição, que pode ser em linguagem
informal ou em linguagem técnica.
• Validação e negociação dos requisitos: os requisitos de software devem ser

constantemente validados e negociados entre as partes envolvidas para garantir que
os critérios de qualidade previamente definidos estejam sendo cumpridos.
• Gerenciamento de requisitos: é uma fase “guarda-chuva”, que está presente

permanentemente no processo de requisitos, com o intuito de tomar as medidas de
gestão necessárias para a realização das demais fases.
2 Habilidades de um engenheiro de requisitos

O papel de um engenheiro de requisitos em um projeto de software é essencial. Em
muitos cenários, ele é a única pessoa que tem contato direto com os stakeholders. Ele tem
a missão de coletar as informações que os envolvidos no processo estão fornecendo e
identificar as necessidades que estão por trás dessas informações.
O engenheiro de requisitos deve ser o elo entre o mundo dos negócios (que não conhece
as possibilidades que a tecnologia pode oferecer) e o mundo da tecnologia (que não conhece
o mundo dos negócios). É o interlocutor entre o usuário e a equipe técnica. Deve falar a
linguagem desses dois grupos de modo a ter condições de interpretar o domínio de negócios
que envolve as necessidades dos usuários e saber como transmiti-las à equipe técnica de
desenvolvimento (POHL; RUPP, 2011).

Em uma organização que demanda um software, um dos maiores desafios do engenheiro

de requisitos é lidar com o capital humano e sua influência organizacional (SOMMERVILLE,
2011). Pense que o engenheiro de requisitos, na maioria das vezes, não conhece a cultura da
organização e também não conhece as pessoas que ali trabalham. O engenheiro de requisitos
está lá essencialmente fazendo seu trabalho, de elicitação, documentação, negociação e
gerenciamento de requisitos. Será que fatores externos ao projeto, como o clima organizacional,
podem influenciar nas informações repassadas pelos stakeholders? Será que algum membro
importante pode ser excluído do processo com a intenção de a opinião dele não ser levada em
consideração nos requisitos do projeto? Qual deve ser a atitude do engenheiro de requisitos
nesse cenário?
O engenheiro de requisitos possui um papel-chave em um projeto de software. Pohl e

Rupp (2011) definem sete capacidades que um engenheiro de requisitos deve possuir:
01 Raciocínio analítico
O engenheiro de requisitos deve ter capacidade de compreender assuntos complexos que lhe sejam desconhecidos
e de lidar com problemas e relacionamentos complexos. Em muitos casos, os stakeholders discutem situações
problemáticas sobre as quais eles mesmos têm dúvidas e/ou estão confusos. Nesses casos, o raciocínio analítico
do engenheiro de requisitos deve levá-los a analisar a situação sob a ótica de diferentes cenários até se chegar a
uma extração mais exata das necessidades reais.
02 Empatia
Trata-se da capacidade de se colocar no lugar do outro. O engenheiro de requisitos deve fazer esse exercício no
intuito de compreender os motivos pelos quais o stakeholder está demonstrando determinada necessidade. Esse
exercício também ajuda a entender se as necessidades apresentadas são essenciais ou fazem parte de um
conjunto de desejos supérfluos.
03 Comunicação
A capacidade comunicativa do engenheiro de requisitos é essencial para que ele saiba ouvir os envolvidos, retome
um assunto quando mal explicado e faça perguntas para que o interlocutor elucide uma determinada necessidade
com outro ponto de vista para confirmar as informações compreendidas.
04 Resolução de conflitos
As divergências de opiniões entre os stakeholders são comuns. Temos conflitos hierárquicos, ideológicos e até
mesmo políticos, portanto, o analista de requisitos deve estar preparado para utilizar técnicas de resolução de
conflitos.
05 Moderação
O analista de requisitos deve conduzir eventos em que seja necessária a moderação de diferentes opiniões,
liderando as discussões, agindo como mediador.
06 Autoconfiança
Considerando a importância do papel do analista de requisitos como centralizador de informações, ele deve estar
ciente de suas funções e ser autoconfiante, com capacidade para defender seu ponto de vista sem levar a situação
para o lado pessoal.
07 Persuasão
O analista de requisitos deve utilizar seu poder de persuasão para convencer os envolvidos dos requisitos
identificados, criar um senso comum e facilitar definições.

3 Tipos de requisitos
Os requisitos de software são divididos em duas categorias: funcionais e não funcionais.
Os requisitos funcionais têm ligação com o que o software deve fazer. Já os não funcionais
estão vinculados a características de qualidade e arquiteturais do software. A seguir, veremos
o detalhamento de cada um desses tipos.
Requisitos funcionais
Para Sommerville (2011, p. 59), “[...] os requisitos funcionais de um sistema descrevem

o que ele deve fazer”. Isso inclui as necessidades específicas dos usuários para resolver
os problemas de negócio. Em sua obra, Sommerville (2011) ainda destaca que, além
do estabelecimento dos serviços que o sistema deve fornecer, um requisito funcional
deve apresentar o comportamento do sistema em situações específicas, bem como pode
declaradamente definir o que o sistema não deve fazer.
Fazendo uma analogia com a construção civil, podem-se citar como exemplo os seguintes
requisitos funcionais para a construção de uma residência:
• A casa deve possuir uma cozinha com duas janelas de 1 m x 1,10 m;
• A residência deve ter um banheiro vinculado a cada dormitório;
• A casa deve possuir grades de proteção em todas as portas e janelas;
• Em todas as torneiras de água, devem estar disponíveis água quente e fria.
Agora que entendemos que os requisitos funcionais estão ligados essencialmente à

funcionalidade da residência, veremos os requisitos funcionais de um sistema. Serão dados
como exemplo os requisitos funcionais de um sistema de controle de frotas:
• O sistema deve permitir o cadastro de veículos;
• O sistema deve possibilitar o registro do abastecimento de cada um dos veículos;
• O sistema deve calcular a média de consumo para cada veículo e para cada modelo;
• O usuário poderá incluir no cadastro os acessórios pertencentes a cada veículo.
Requisitos não funcionais ou de qualidade
O International Institute of Business Analysis (IIBA, 2011) define que os requisitos não
funcionais estão relacionados ao ambiente no qual o software deve permanecer operante.
Para o IEEE (2014), os requisitos não funcionais atuam para restringir as soluções.
Essas restrições podem envolver requisitos de desempenho, requisitos de manutenção,
requisitos de segurança, requisitos de confiabilidade, requisitos de segurança, requisitos

de interoperabilidade e outros tipos que estejam ligados à solução como um todo, e não
a uma funcionalidade específica. Os requisitos não funcionais também são chamados de
requisitos de qualidade.
Os requisitos não funcionais tendem a ter uma importância maior em relação aos
requisitos funcionais (KERR, 2015), pois um usuário geralmente tem condições de contornar
uma falha em um requisito funcional, mas não dispõe de meios para operar o sistema caso
um requisito não funcional que suporta o software esteja indisponível. Por exemplo: se um
relatório de faturamento (requisito funcional) não for impresso devido à ocorrência de uma
falha, o usuário provavelmente poderá obter as informações através de outra funcionalidade,
por exemplo, realizando um print screen da tela para apresentar as informações ao seu gestor.
Já no caso de um requisito não funcional que, por exemplo, determine o funcionamento do
software vinculado a um Sistema de Gerenciamento de Banco de Dados (SGDB), se o SGDB
estiver indisponível, o usuário não terá a possibilidade de realizar nenhuma ação.
Para Sommerville (2011), os clientes de um sistema têm dificuldades em determinar

requisitos não funcionais, pois é necessário ter um conhecimento muito técnico para definir
essas questões. Dessa forma, sempre que possível, o analista de requisitos deve envolver
também o departamento técnico da organização demandante do software, pois esses
funcionários conhecem a realidade da organização e podem ajudar a identificar os requisitos não
funcionais. Sugere-se ainda a utilização da Tabela 1, a seguir, para que seja possível descrevê-los
quantitativamente, pois somente dessa forma poderão ser efetivamente validados.
Tabela 1 – Métricas para especificar requisitos não funcionais
Propriedade Medida
Transações processadas/segundo
Velocidade Tempo de resposta do usuário/evento
Tempo de atualização da tela
Megabytes
Tamanho
Número de chips de memória ROM
Tempo de treinamento
Facilidade de uso
Número de frames de ajuda
Tempo médio para falha
Probabilidade de indisponibilidade
Confiabilidade
Taxa de ocorrência de falhas
Disponibilidade
Tempo de reinício após falha
Robustez Percentual de eventos que causam falha
Probabilidade de corrupção de dados em caso de falha
Percentual de declarações dependentes no sistema-alvo
Portabilidade
Número de sistemas-alvo
Fonte: Sommerville (2011, p. 63).

Fazendo uma analogia com a construção civil novamente, podem-se citar como exemplo
de requisitos não funcionais para a construção de uma residência:
• As paredes externas devem ser resistentes à chuva e ao vento, sem permitir que a
umidade se infiltre;
• Cada cômodo da residência deve suportar até 20.000 kg de carga líquida;
• Devem ser utilizados equipamentos (torneiras, fechaduras, louças) que possuam

peças de reposição no mercado da construção civil.
Agora que entendemos que os requisitos não funcionais estão ligados a questões gerais,
de confiabilidade e de características gerais da residência, veremos exemplos de requisitos
não funcionais de um sistema. Por exemplo, para um sistema de controle de frotas, são
exemplos de requisitos não funcionais:
• Deve ter disponibilidade de uso 24 horas por dia, nos sete dias da semana;
• O tempo de qualquer transação realizada pelo usuário não pode exceder 20 s;
• Deve ser construído com arquitetura de software em três camadas: apresentação,

negócios e dados;
• Deve possuir uma página de ajuda para cada funcionalidade, com acesso sensível ao
contexto.
4 Requisitos e modelos de processos

Neste tópico, iremos abordar os principais modelos de processo de desenvolvimento de
software e ainda veremos como a engenharia de requisitos se vincula a cada um deles.
4.1 Modelo cascata

Alguns modelos de processos de desenvolvimento de software preveem que todas as
fases ocorram em uma sequência, e apenas uma vez, tal como o modelo cascata, por exemplo.
Uma fase não se inicia antes que a outra tenha sido concluída, aprovada e documentada. Isso
faz com que a fase de requisitos seja inicial e única, ou seja, todo o processo de engenharia
de requisitos ocorra de uma única vez e somente uma vez. Devemos considerar que, nesse
cenário, todos os requisitos do software precisam ser elicitados, documentados e validados
antes que comece a fase de projeto.
A Figura 1, a seguir, apresenta o formato que o modelo de processo cascata propõe. Esse
modelo não prevê alternativa se, durante as fases posteriores à fase de requisitos, forem
detectadas necessidades de modificação nos requisitos previamente acordados. A principal

falha do modelo cascata é se vincular a um processo de fabricação, e não de criação. Não

são previstos caminhos de retorno entre as atividades, o que faz com que a criação fique
prejudicada. O desenvolvimento de um software envolve tentativas, análise de alternativas,
análise de viabilidade e aprendizado com erros para chegar a uma solução ideal para o
problema (CURTIS et al apud PFLEEGER, 2004).
Figura 1 – Modelo cascata
Análise
de requisitos
∠
Projeto
do sistema
∠
Projeto
do programa
∠
Codificação
∠
Teste de unidades
e integração
∠
Teste
do sistema
∠
Teste
de aceitação
∠
Operação
e manutenção
Fonte: Pfleeger (2004, p. 39)
Para Pressman (2011), o modelo cascata pode ser aplicado com sucesso em adaptações
ou aperfeiçoamentos pontuais em um software, por exemplo, uma adaptação originada de
uma exigência legal, que tem requisitos bem definidos e relativamente estáveis. No entanto,
tal modelo geralmente falha pelos seguintes motivos:
• Projetos do “mundo real” raramente seguem o fluxo sequencial e rígido que o modelo
cascata propõe;
• Dispor de todas as necessidades em uma fase inicial de projeto é algo impossível para
a maioria dos stakeholders, fora a incerteza natural que faz parte também de grande
parte dos projetos;
• A entrega de software funcional para o cliente ocorrerá apenas no final do projeto e,

portanto, ele deve ter paciência.
4.2 Modelo incremental

O modelo incremental é centrado na ideia de desenvolver uma implementação inicial,
um fragmento do software, e depois apresentá-la aos usuários, receber os feedbacks e
partir para a criação de várias versões até que o software ideal esteja construído. Nesse
modelo, conforme pode ser verificado na Figura 2, a seguir, as atividades de especificação,
desenvolvimento e validação são intercaladas e interativas (SOMMERVILLE, 2011).
Figura 2 – Modelo Incremental
Incremento nº n
Funcionalidade e recursos do software
A B C D Entrega no
E
n-ésimo incremento
Incremento nº 2
A B C D Entrega do
E
2º incremento
Incremento nº 1
A B C D Entrega do
E
1º incremento
Cronograma do projeto
A Comunicação B Planejamento C Modelagem (análise, projeto)

D Construção (codificação, testes) E Emprego (entrega, realimentação ou feedback)
Fonte: Pressman (2011, p. 61).
Dessa forma, utilizando o modelo incremental, a engenharia de requisitos é uma fase

permanente no desenvolvimento do software. Definidos os incrementos que o software terá,
o escopo de requisitos a serem tratados naquele momento é o escopo do incremento. Para
Pressman (2011), as vantagens do modelo incremental em relação ao modelo cascata são:
• O custo das mudanças é reduzido. Quando há um ajuste nas definições de requisitos,

a quantidade de documentação a ser refeita está limitada ao incremento;
• Considerando a baixa capacidade de abstração que os stakeholders têm, apresentar

partes do software funcionando aumenta o entendimento da solução que está sendo
desenvolvida. Isso contribui para um levantamento mais preciso das necessidades
dos próximos incrementos;
• A entrega de partes funcionais faz com que os stakeholders possam utilizar o software
mesmo sem toda a funcionalidade concluída, o que não é possível no modelo cascata.

4.3 Processos ágeis

Os métodos ágeis utilizam essencialmente a abordagem do modelo incremental, mas com
a inclusão de alguns princípios que os fazem se aproximar dos stakeholders (BECK et al, 2001).
Os métodos ágeis são baseados no Manifesto Ágil, que contém 12 princípios. Os que têm
maior relação com requisitos são:
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento; processos ágeis

se adequam a mudanças, para que o cliente possa tirar vantagens competitivas;
pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e
diariamente, durante todo o curso do projeto. (BECK et al., 2001, s.p.).
Sommerville (2011) defende que a aproximação com stakeholders oferece maiores

chances de se obter as informações necessárias para os requisitos do projeto. Mas o autor
alerta para o fato de muitas das metodologias ágeis sugerirem uma menor preocupação
com documentação, o que pode tornar o registro dos requisitos precário e dificultar a
implementação dos futuros incrementos em um software. O documento de requisitos é a
fonte de informações para avaliação das mudanças necessárias em um software e, portanto,
ter um documento incompleto pode tornar o processo difícil e custoso.
Fica para reflexão um ponto de vista que Pressman (2011, p. 85) expõe, sobre a relação
engenharia de software versus metodologias ágeis: “Você não tem de escolher entre agilidade
ou engenharia de software. Em vez disso, defina uma abordagem de engenharia de software
que seja ágil”.
Você acha que é possível obter as melhores práticas da engenharia de software tradicional
e dos métodos ágeis para chegar a um resultado satisfatório da engenharia de requisitos do seu
projeto e da entrega do seu software?
Nesta aula, tivemos a oportunidade de conhecer os fundamentos da engenharia de
requisitos e como ela se vincula aos principais modelos de processo de desenvolvimento de
software.
Devemos ressaltar, portanto, o papel fundamental da engenharia de requisitos como

base para o desenvolvimento de um bom software.
O engenheiro de requisitos, por sua vez, é ator essencial e central em um processo

de desenvolvimento de um software. E, junto com a relevância da sua atuação, vem a

responsabilidade por definir requisitos consistentes para que as fases posteriores do

desenvolvimento de software sejam concluídas com êxito.
Vimos também a conceituação de requisitos funcionais e não funcionais, o que nos

permitiu compreender a necessidade de identificação de requisitos de ambos os tipos nos
projetos de desenvolvimento de software.
Por fim, apresentamos os principais modelos de processo de desenvolvimento de

software. Com isso, verificamos que a engenharia de requisitos é sempre uma premissa, com
papel importante, vinculada a todos os modelos de processo.
Referências
BECK, K. et al. Manifesto para o desenvolvimento ágil de software. Disponível em: <http://
www.manifestoagil.com.br>. Acesso em: 26 jul. 2015.
IEEE. Guide to the software engineering body of knowledge: SWEBOK®. 3. ed. Washington:
IEEE Computer Society, 2014.
IIBA. Um guia para o corpo de conhecimento de análise de negócios: guia BABOK®. 2. ed.
Toronto: IIBA, 2011.
KERR, E. S. Gerenciamento de requisitos. São Paulo: Pearson, 2015.
KERTZNER, H. The changing role of stakeholder involvement in projects: the quest for better
metrics. In: Project perspectives 2012. Viena: IPMA, 2012. Disponível em: <http://ipma.ch/
assets/re-perspectives_2012.pdf>. Acesso em: 23 ago. 2015.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.
POHL, K.; RUPP, C. Requirements engineering fundamentals: a study guide for the certified
professional for requirements engineering exam: foundation level. Santa Bárbara, Estados
Unidos: Rocky Nook, 2011.
PRESSMAN, R. Engenharia de software: uma abordagem profissional. 7. ed. Porto Alegre:

AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

Aula 02
Planejamento e Monitoramento da Análise de Requisitos
• Conhecer meios para realizar o planejamento e o monitoramento da análise
de negócios.
Temas
Introdução
1 Análise das partes interessadas
2 Planejamento da comunicação da análise de negócios
3 Planejamento do gerenciamento de requisitos
4 Gerenciamento do desempenho da análise de negócios
Referências
Professor Autor
Introdução
Esta aula tem como objetivo apresentar uma série de tarefas que o Business Analysis
Body of Knowledge (BABOK®) indica como mecanismos que permitem o planejamento e o
monitoramento da análise de negócios.
Começaremos a aula com o estudo da análise das partes interessadas, que é dividida
nas seguintes tarefas: identificação das partes interessadas, gerenciamento das partes
interessadas e elaboração de mapas das partes interessadas.
Na sequência, veremos o planejamento da comunicação da análise de negócios e do

gerenciamento dos requisitos, tarefas que irão nortear o trabalho de análise dos negócios de
um projeto.
Por último, conheceremos os conceitos do gerenciamento do desempenho, os quais

permitirão que o trabalho de análise de negócios seja avaliado.
Convido você, aluno, a imergir neste importante tema, para que ao final desta aula você
seja capaz de identificar os conceitos e a importância das tarefas aqui estudadas, e tenha
condições de aplicá-los em um projeto de desenvolvimento de software.
1 Análise das partes interessadas

O International Institute of Business Analysis (IIBA, 2011) define a análise das partes
interessadas como sendo o trabalho de identificação das partes que podem ser afetadas por
uma necessidade de negócio. Essa identificação pode ser realizada para o projeto como um todo
ou fase a fase, no entanto, é importante determinar no início do trabalho a influência e/ou a
autoridade de cada uma das partes interessadas, que farão as aprovações das entregas do projeto.
Essa análise é realizada a partir do momento em que a necessidade de negócio é

detectada e é uma atividade contínua durante o processo de análise de negócios (IIBA, 2011).
1.1 Identificação das partes interessadas

De acordo com o IIBA (2011), o primeiro passo do processo de análise é identificar quais
são as partes interessadas, seus papéis, suas responsabilidades e sua autoridade sobre os
requisitos que cada parte detém ou com os quais é afetada.
Identificar as partes interessadas no início do projeto é fundamental para que se tenham

condições de garantir as entregas de requisitos em tempo hábil. Essa identificação é uma
tarefa fundamental da engenharia de requisitos, e o engenheiro responsável pelo projeto
deve coletar, documentar e consolidar os requisitos parcialmente conflitantes das diferentes
partes interessadas (GLINZ; WIERINGA, 2007).

Para Pohl e Rupp (2011), a não consideração de partes interessadas pode fazer com que
requisitos importantes sejam ignorados, ocorrendo solicitações de novos requisitos já na fase
de implantação. Para minimizar essas falhas, os autores sugerem que as listas de requisitos das
partes interessadas sejam atualizadas periodicamente, ou seja, que o processo seja contínuo.
O IIBA (2011) complementa o tema ao alertar que, em alguns casos, as solicitações de novos
requisitos podem gerar a necessidade de uma revisão completa do projeto do software.
Dois principais aspectos influenciam a complexidade de um grupo de partes interessadas:
01 O número e a variedade de usuários que a parte interessada representa;
02 O número de processos de negócio e de sistema automatizados.
O IIBA (2011) sugere que sejam considerados fatores relacionados à atitude e à influência
das partes interessadas.
• No que tange à atitude, os aspectos centrais são referentes aos objetivos e às metas
do negócio e a abordagem da solução, a atitude em relação à colaboração e atitude
em relação ao patrocinador.
• Já em relação à influência, é necessário conhecer a autoridade das partes interessadas

com o intuito de viabilizar relacionamentos de confiança e com a construção destes
relacionamentos, obter o comprometimento e a colaboração das partes interessadas.
Alguns fatores vinculados à influência que podem ser considerados são: influência
no projeto, influência necessária para o bem do projeto, influência na organização e
influência com outras partes interessadas.
As técnicas para identificar as partes interessadas, de acordo com o IIBA (2011), podem
incluir:
01 Definição dos critérios de aceite e avaliação

O analista de negócios deve, como parte da análise das partes interessadas, identificar quais delas possuem
autoridade suficiente para aceitar ou rejeitar uma solução.
02 Brainstorming
Processo que pode auxiliar na identificação das necessidades e dos requisitos que levam às possíveis partes
interessadas, ou ajudar na criação de uma lista de possíveis papéis de partes interessadas.
03 Entrevistas
Entrevistados podem ser capazes de apontar outras partes interessadas.
04 Modelagem organizacional
Fazer uma avaliação para determinar se as unidades organizacionais ou as pessoas listadas possuem quaisquer
necessidades e interesses únicos que devam ser considerados. Assim, será possível descrever os papéis e as
funções na organização e as maneiras como as partes interessadas interagem, o que facilitará a identificação
dessas partes interessadas.
05 SãoModelagem
Senac deDireitos
Paulo - Todos os processos
Reservados 3
Qualquer pessoa envolvida na execução de processos de negócio afetados pela solução é uma parte interessada.
Modelos de processos podem se tornar uma fonte para a identificação de partes interessadas, desde que os
04 Modelagem organizacional
Fazer uma avaliação para determinar se as unidades organizacionais ou as pessoas listadas possuem quaisquer
necessidades e interesses únicos que devam ser considerados. Assim, será possível descrever os papéis e as
funções na organização e as maneiras como as partes interessadas interagem, o que facilitaráGestão de Requisitos
a identificação
dessas partes interessadas.
05 Modelagem de processos
Qualquer pessoa envolvida na execução de processos de negócio afetados pela solução é uma parte interessada.
Modelos de processos podem se tornar uma fonte para a identificação de partes interessadas, desde que os
processos relacionados possam ser afetados. Além disso, a categorização de partes interessadas com base nos
sistemas que suportam seus processos de negócio pode ser útil quando mudanças precisam ser feitas nos
processos e sistemas.
06 Workshops de requisitos
Durante os workshops de requisitos, o analista de negócios pode perguntar aos participantes se eles podem indicar
outras partes interessadas.
07 Análise de riscos
Riscos para a iniciativa podem ser resultados das atitudes de partes interessadas ou da habilidade das principais
partes interessadas de participar da iniciativa.
08 Cenários e casos de uso e histórias de usuários

A identificação dos papéis das partes interessadas pode servir como ponto de partida para a identificação de atores
e papéis.
09 Modelagem do escopo
Os modelos do escopo devem mostrar partes interessadas que estão fora do escopo da solução, mas que irão se
inter-relacionar com o sistema de alguma forma.
10 Pesquisa/questionário
É útil para identificar características compartidas de um grupo de partes interessadas.
O IIBA (2011) apresenta, como saída do processo de identificação das partes interessadas,
uma lista de tais partes interessadas, com seus papéis e suas responsabilidades. Essa lista
deve conter:
Figura 1 – Modelo de lista das partes interessadas
Categoria das
partes interessadas
Localização das partes

interessadas e formas
de contato
Nome e cargo das

Número de indivíduos
partes interessadas
interessados neste papel
Lista de papéis
Necessidades especiais
Descrição da influência e
do interesse das partes
interessadas
Documentação dos níveis

de autoridade das partes
interessadas

1.2 Gerenciamento das partes interessadas
Depois de identificadas as partes interessadas, é importante gerenciá-las. Em sua obra,

Pressman (2011) deixa claro um dos motivos pelos quais devemos nos preocupar com isso:
para ele, cada interessado tem uma visão diversa do sistema e obtém diferentes benefícios
quando ele é desenvolvido com êxito, mas também está sujeito a diferentes riscos caso o
trabalho de desenvolvimento não saia como o desejado.
Com frequência, os projetos envolvem uma quantidade elevada de stakeholders. Desse

modo, é necessário realizar uma seleção criteriosa para que a elicitação de requisitos ocorra
com as partes interessadas mais adequadas (POHL; RUPP, 2011).
Segundo Pohl e Rupp (2011), o processo de gerenciamento das partes interessadas

exige habilidades do analista de requisitos para lidar com a comunicação contínua com os
stakeholders, envolvê-los de forma a evitar reações contrárias à solução proposta, apresentar
os benefícios da mudança sugerida aos mais céticos e também aos que estão confortáveis
com a situação atual.
Por isso, analisar os diversos pontos de vista dos stakeholders é importante. Assim,
será possível identificar os requisitos com mais precisão e montar uma matriz com os
requisitos emergentes. Essa matriz deve incluir inconsistências e/ou conflitos entre
requisitos, para que essas situações possam ser apresentadas aos tomadores de decisão
com o intuito de viabilizar um compêndio consistente de requisitos (PRESSMAN, 2011;
SOMMERVILLE, 2011).
1.3 Mapas das partes interessadas
Os mapas das partes interessadas são diagramas que representam o relacionamento

das partes interessadas com a solução desenvolvida. As duas abordagens mais comuns são a
matriz nível de influência versus nível de interesse e o diagrama cebola, que indica o nível em
que cada parte interessada está envolvida com a solução (IIBA, 2011).
A Figura 2 apresenta a matriz nível de influência versus nível de interesse, que posiciona
os stakeholders em diferentes cenários de acordo com a análise dessa razão. O objetivo é
orientar o engenheiro de requisitos sobre que tipo de abordagem deve utilizar com cada
parte interessada, segundo o quadrante em que ela ficou categorizada.

Figura 2 – Matriz das partes interessadas
Alto
Trabalhar próximo à parte
Assegurar que a parte interessada interessada para garantir que
permaneça satisfeita ela esteja de acordo e apoie
Influência da parte as mudanças
interessada
Manter informada; é provável

Monitorar se a influência ou
que a parte interessada esteja muito
o interesse da parte interessada
preocupada e possa se sentir
não se altera
ansiosa sobre a falta de controle
Baixo
Impacto sobre a Parte Interessada
Baixo Alto
Fonte: IIBA (2011, p. 34).
A Figura 3 apresenta o diagrama cebola das partes interessadas, que as organiza em

camadas, colocando no centro a entrega da solução e em cada uma das camadas um
agrupamento das partes interessadas.
Figura 3 – Diagrama cebola das partes interessadas
Clientes, fornecedores,
reguladores e outros
Partes interessadas
externas afetadas Patrocinadores, executivos,
especialista no assunto e outras
Organização pessoas que interagem com o
ou corporação grupo afetado
Unidade
Organizacional Usuário final, help desk e outros,
Afetada cujo trabalho muda quando a
solução é entregue
Entrega da Equipe de projeto e outros

Solução diretamente envolvidos com a
criação da solução
Fonte: IIBA (2011, p. 34).
2 Planejamento da comunicação da análise de negócios

Para realizar um bom trabalho de análise de negócios, é essencial o planejamento da
comunicação envolvida no processo de análise de negócios. Para atender a essa demanda,
o plano de comunicação da análise de negócios é o artefato que permitirá o registro e a
determinação das atividades, trazendo um detalhamento das expectativas relacionadas à
análise de negócios, tais como reuniões, revisões e demais comunicações (IIBA, 2011).

O plano de comunicação da análise de negócio deve conter uma estrutura proposta

para o funcionamento das comunicações e um cronograma das comunicações das tarefas
relacionadas à análise e ao negócio.
O processo de planejamento de análise de negócio precisa encontrar e definir o formato

ideal para receber, distribuir, acessar, atualizar e escalonar as informações das partes
interessadas do projeto. Em resumo, esse processo tem o intuito de determinar a forma de
comunicação com cada uma das partes interessadas.
O plano de comunicações pronto deve incluir o que, como, para quem e quando as
comunicações devem ocorrer no âmbito da análise de negócios. O IIBA (2011) ressalta a
importância de que as necessidades das partes interessadas e as restrições relevantes para a
comunicação sejam consideradas, tais como:
• Localização física e fuso horário das partes interessadas;
• Metodologia de abordagem da comunicação com a parte interessada;
• Tipos de comunicações que serão necessários, por exemplo: posicionamento,

anormalidades, problemas e suas resoluções, riscos, resultados de reuniões,
pendências;
• Tipos de requisitos serão elicitados, tais como: de negócio, das partes interessadas,
de solução ou de transição, em alto nível ou detalhados e a forma de elicitá-los;
• Forma de comunicação das conclusões e dos pacotes de requisitos de acordo com os

níveis de autoridade (aprovação, de veto ou de revisão);
• Restrições na disponibilidade de tempo e recursos.
A Figura 4 apresenta o diagrama do processo de planejamento da comunicação da análise

de negócios. Nele, têm-se como entrada: abordagem da análise de negócios; planos de
análise de negócios; lista de partes interessadas, com seus papéis e suas responsabilidades;
ativos de processos organizacionais (IIBA, 2011).
A saída desse processo é o plano de comunicação da análise de negócios e os processos

que utilizam esse artefato, ou seja, que são dependentes dele: preparação do pacote de
requisitos e comunicação dos requisitos (IIBA, 2011).

Figura 4 – Diagrama de entrada/saída do planejamento da comunicação da análise de negócios
Entradas
2.1 2.3 2.2
Abordagem Plano(s) da Ativos de Lista de partes

da análise de análise de processos interessadas, papéis e
negócios negócios organizacionais responsabilidades
2.4
Planejar a Comunicação
da Análise de Negócios
2.4
Plano de Comunicação
da Análise de Negócios
Tarefas que usam esta saída
4.4 4.5
Preparar Pacote Comunicar
de Requisitos Requisitos
Fonte: IIBA (2011, p. 43).
O IIBA (2011) cita como elementos a serem considerados no planejamento das

comunicações: a geografia, a cultura, o tipo de projeto, a necessidade de frequência na
comunicação e a formalidade nas comunicações. Na lista a seguir, é possível identificar os
principais pontos que devem ser considerados em cada um desses itens.
01 Geografia
Fuso horário, falta de tecnologia acessível para rápida comunicação, projeto complexo sendo desenvolvido em
conjunto por várias localidades envolvidas.
02 Cultura
O relacionamento com o tempo, vinculado ao compromisso com resultados acordados, pode ter diferentes
contextos em diferentes regiões. O comprometimento com a finalização das tarefas e a necessidade de uma
hierarquia de decisões formal ou informal variam em cada região. Por isso, é essencial que se use modelos de
representação com uma notação padronizada, a fim de que o entendimento de todos os participantes possa ser
equivalente, independentemente da cultura envolvida.
03 Tipo de projeto
Cada tipo de projeto requer uma estratégia de comunicação. O projeto de desenvolvimento de um novo software
customizado e produzido dentro da organização, por exemplo, requer que todos os requisitos sejam adicionados. Já
um upgrade da tecnologia ou da infraestrutura de um sistema em uso necessita apenas dos requisitos técnicos no
Senac Sãopacote.
Paulo -Mudanças em umReservados
Todos os Direitos processo de negócio ou novos dados para um aplicativo existente requerem processo e
8
requisitos de dados, regras de negócios, requisitos funcionais e técnicos. Em se tratando de uma aquisição de um
pacote de software, o projeto pedirá uma Solicitação de Proposta ou Request for Proposal (RFP), em inglês, e o
02 Cultura
O relacionamento com o tempo, vinculado ao compromisso com resultados acordados, pode ter diferentes
contextos em diferentes regiões. O comprometimento com a finalização das tarefas e a necessidade de uma
hierarquia de decisões formal ou informal variam em cada região. Por isso, é essencial que se use modelos de
Gestão de
representação com uma notação padronizada, a fim de que o entendimento de todos os participantes Requisitos
possa ser
equivalente, independentemente da cultura envolvida.
03 Tipo de projeto
Cada tipo de projeto requer uma estratégia de comunicação. O projeto de desenvolvimento de um novo software
customizado e produzido dentro da organização, por exemplo, requer que todos os requisitos sejam adicionados. Já
um upgrade da tecnologia ou da infraestrutura de um sistema em uso necessita apenas dos requisitos técnicos no
pacote. Mudanças em um processo de negócio ou novos dados para um aplicativo existente requerem processo e
requisitos de dados, regras de negócios, requisitos funcionais e técnicos. Em se tratando de uma aquisição de um
pacote de software, o projeto pedirá uma Solicitação de Proposta ou Request for Proposal (RFP), em inglês, e o
pacote deverá incluir requisitos do negócio, requisitos técnicos, requisitos funcionais limitados e até mesmo outras
especificações do fornecedor. No caso de iterações de desenvolvimento de software ágeis, a formalidade e a
documentação de requisitos podem ser opcionais e ser substituídas por user stories.
04 Frequência nas comunicações

Deve ser definida uma frequência em que serão realizadas as comunicações para cada tipo de parte interessada,
pois um patrocinador tem interesses diferentes de um especialista de negócios, por exemplo.
05 Formalidade nas comunicações

A formalidade pode variar de projeto para projeto, de parte interessada para parte interessada, e até mesmo de fase
para a fase. Mas, costumeiramente, existe uma necessidade maior de formalidade quando: o projeto é
extremamente grande, o domínio de negócios envolvido é muito complexo, utiliza-se uma nova tecnologia, o projeto
está ligado aos objetivos estratégicos organizacionais, há exigência por parte do patrocinador ou das partes
interessadas e existe a necessidade de crivo regulatório.
3 Planejamento do gerenciamento de requisitos

O IIBA (2011) preconiza que o propósito do processo de gerenciamento de requisitos é a
definição do processo que será empregado para aprovar requisitos de implementação e para
gerenciar as mudanças no escopo dos requisitos ou da solução.
A atividade inclui a vinculação do processo às mudanças nos requisitos, à definição

das partes interessadas que têm o poder de aprovar as mudanças, aquelas que serão
consultadas, aquelas que apenas serão comunicadas sobre as mudanças e até mesmo aquelas
que não precisam ser envolvidas. O processo também faz a avaliação das necessidades de
rastreabilidade dos requisitos e a determinação de quais atributos dos requisitos serão
utilizados (IIBA, 2011).
Na Figura 5, é possível visualizar as entradas do processo de gerenciamento de

requisitos.

Figura 5 – Diagrama de entrada/saída do planejamento do gerenciamento de requisitos
Entradas
2.1 2.3
Abordagem Plano(s) da Ativos de

da análise de análise de processos
negócios negócios organizacionais
2.5
Planejar o processo de
gerenciamento de requisitos
2.5
Plano de gerenciamento
de requisitos
2.6 4.1
3.2
Gerenciamento do Gerenciamento do
Condução das
desempenho da escopo e dos requisitos
atividades de elicitação
análise de negócios da solução
4.2
6.1
Gerenciamento
Priorização
da rastreabilidade
dos requisitos
dos requisitos
Fonte: IIBA (2011, p. 47).
Como elementos desse processo, são relacionados: repositório, rastreabilidade, seleção

dos atributos dos requisitos, priorização dos requisitos, gerenciamento da mudança e
adaptação do processo de gerenciamento de requisitos (IIBA, 2011).
O plano de gerenciamento dos requisitos, que é saída desse processo, deve incluir:
• Estratégia estruturada a ser adotada para a rastreabilidade;
• Definição de quais são as propriedades dos requisitos a serem empregados;
• Modo de funcionamento do processo de priorização de requisitos;
• Modo de funcionamento do processo de gerenciamento de mudanças,

necessariamente determinando como as mudanças são solicitadas, avaliadas,
aprovadas e executadas.

4 Gerenciamento do desempenho da análise de negócios

O gerenciamento do desempenho da análise de negócios está vinculado à área de
conhecimento de planejamento e monitoramento da análise de negócios. O gerenciamento
do desempenho da análise de negócios trata da escolha de métricas que irão nortear o
trabalho executado. Essas métricas incluem formas de rastrear, avaliar e reportar a qualidade
do trabalho aos responsáveis e a execução de ações necessárias para corrigir os desvios que
ocorrerem (IIBA, 2011).
Após definidas as medidas de desempenho, elas serão coletadas e apresentadas através

de relatórios de desempenho. De acordo com o resultado, é necessário estabelecer medidas
preventivas e/ou corretivas com partes interessadas, no intuito de viabilizar o projeto.
O IIBA (2011) determina como as saídas dessa tarefa:
• Avaliação de desempenho de análise de negócios: permite comparar o planejado

com o realizado, identificando a quantidade de esforço necessária para concluir as
atividades de análise de negócio;
• Ativos de processos de análise de negócios: considerando bons resultados de

desempenho, é primordial que os procedimentos de análise de negócios sejam
atualizados, para que as práticas aplicadas no projeto sejam documentadas e
sugeridas para os futuros eventos de análise de negócios.
Nesta aula, tivemos a oportunidade de aprender muito sobre análise de negócios e seu
planejamento. Essas tarefas, determinadas pelo BABOK®, dão ao profissional da área um
rumo a seguir.
Aprendemos que as partes interessadas são essenciais e, ao mesmo tempo, delicadas

em um projeto, pois estamos falando de pessoas que têm seus interesses e suas prioridades.
Portanto, nada mais adequado que efetuar um gerenciamento apropriado das partes
interessadas, com o intuito de garantir que estejam satisfeitas com a solução desenvolvida.
Na sequência, discutimos o planejamento da comunicação de análise de negócios e fomos

imersos nos conceitos que mostram a necessidade nos preocuparmos com a comunicação
em um processo de análise de negócios.
Na continuidade, apresentamos considerações sobre o gerenciamento de análise de

negócios, o qual irá nortear o funcionamento de uma série de processos futuros da análise
de negócios. Logo, é possível perceber a importância dessa atividade.

Na parte final, foi possível conhecer uma ferramenta que irá permitir que o nosso
trabalho seja avaliado, com o intuito da melhoria contínua: o gerenciamento do desempenho
da análise de negócios.
Cada vez que iniciarem um processo de desenvolvimento de um novo software, sugiro

que consultem este material e planejem executar o máximo de tarefas propostas aqui. Já no
curto prazo você poderá verificar os efeitos positivos do uso de tais técnicas.
Referências
GLINZ, M.; WIERINGA, R.J. Stakeholders in requirements engineering. IEE Software, v. 28, n. 1,
p. 18-20, 2007.
POHL, K.; RUPP, C. Requirements engineering fundamentals: a study guide for the certified
professional for requirements engineering exam: foundation level. Santa Bárbara, Estados
Unidos: Rocky Nook, 2011.

AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

Aula 03
Análise Corpotativa
• Compreender como é feita a análise da capacidade corporativa.
Temas
Introdução
1 Análise corporativa
Referências
Professor Autor
Introdução
Esta aula objetiva apresentar ao aluno como é realizada a análise corporativa e uma série
de tarefas que o BABOK® apresenta como mecanismos que permitem o planejamento e o
monitoramento da análise de negócios.
Com o estudo aqui apresentado, será possível avaliar a capacidade da organização em

diagnosticar mudanças pertinentes e eleger qual abordagem de solução de negócio é a mais
apropriada para atender às necessidades do negócio e atingir as metas estratégicas da corporação.
1 Análise corporativa
O International Institute of Business Analysis (IIBA, 2011) descreve que a área de
conhecimento corporativo possui atividades de análise de negócios imprescindíveis para
identificar uma necessidade, um problema ou uma oportunidade de negócio, definir uma
solução que atenda a essa necessidade e justificar o investimento que será feito para a
entrega dessa solução.
Além disso, a área de conhecimento corporativo avalia a capacidade organizacional,

determina o escopo e documenta os requisitos necessários para colocar em prática a solução
encontrada. Embora os trabalhos possam ser iniciados por qualquer tarefa, eles são mais
comumente iniciados pela análise corporativa ou pela avaliação do desempenho da solução
(IIBA, 2011).
Para aprofundar os estudos sobre o guia BABOK® e complementar o entendimento dos

conceitos apresentados, faça a leitura das 6 estruturas da área de conhecimento: planejamento
e monitoramento da análise de negócios; elicitação de requisitos; gerenciamento e comunicação
dos requisitos; análise corporativa; análise de requisitos; definição e validação da solução. Para
mais informações sobre como adquirir o guia BABOK®, acesse a Midiateca desta aula.
1.1 Definição da necessidade de negócio

O IIBA (2011) afirma que uma das atividades mais críticas do analista de negócios é
compreender exatamente qual é a necessidade da organização, ou seja, definir o problema
para o qual o analista do negócio está tentando encontrar a solução, questionar as suposições
e restrições que estão geralmente ocultas para garantir que o problema correto esteja sendo
resolvido e considerar o maior número possível de soluções alternativas.
Para iniciar a análise corporativa, deve-se seguir as etapas da Figura 1.

Figura 1 – Etapas da definição da necessidade do negócio
Entradas
3.3
Metas e Requisitos
objetivos do (Declarados)
Negócio
5.1
Definir a necessidade
do negócio
5.1
Necessidade
do Negócio
Fonte: IIBA (2011, p. 88).
1.1.1 Metas e objetivos
De acordo com o IIBA (2011), para realizar as tarefas de entradas como apresentadas
na Figura 1, é preciso que as metas e os objetivos sejam refinados com o intuito de definir a
necessidade do negócio. Em alguns casos, as metas ou os objetivos podem ser exploratórios
– e então a necessidade do negócio pode ser a de compreender se uma metodologia ou um
modelo de negócio funciona.
A declaração dos requisitos, depois de executada, auxilia as partes interessadas a

compreender suas necessidades de negócio e garantir que esses requisitos reflitam os
verdadeiros requisitos de negócio. Os requisitos não podem descrever soluções.
Conforme as metas são analisadas e elaboradas, elas são convertidas em objetivos mais
descritivos e específicos, tornando possível avaliar se eles foram alcançados. Para verificar os
objetivos e garantir que eles são SMART (“espertos”, em inglês), torna-se necessário identificar
se apresentam as seguintes características:
01 Específicos
Os objetivos precisam ser específicos e com resultado observável. Declarações genéricas dificultam os
trabalhos e a forma de mensurar resultados.
02 Mensuráveis
Os resultados dos objetivos propostos precisam ser rastreados e mensurados.
03 São Paulo
Senac Alcançáveis
- Todos os Direitos Reservados 3
Um objetivo precisa ser alcançável, caso contrário não há razão para ser criado.
Os objetivos precisam ser específicos e com resultado observável. Declarações genéricas dificultam os
trabalhos e a forma de mensurar resultados.
02 Mensuráveis Gestão de Requisitos

Os resultados dos objetivos propostos precisam ser rastreados e mensurados.
03 Alcançáveis
Um objetivo precisa ser alcançável, caso contrário não há razão para ser criado.
04 Relevantes
Os objetivos precisam estar alinhados com visão, missão e objetivos organizacionais.
05 Temporais
Os objetivos necessitam de um prazo viável para conclusão. Essa data deve estar alinhada com as
necessidades de negócio.
Além disso, ao determinar o problema ou a oportunidade, é importante quantificar e

determinar os benefícios esperados, verificar a rapidez para encontrar a solução e identificar
a fonte do real do problema (IIBA, 2011).
1.1.2 Técnicas
Algumas técnicas auxiliam na identificação de problemas, oportunidades e/ou

necessidades da organização ou unidade organizacional. São elas:
Figura 2 – Técnicas de identificação de problemas
Benchmarking Brainstorming Análise de regras de negócio

Saber o que outras organizações Ajuda a pensar nas Identifica mudanças nas
concorrentes e parceiros estão mudanças e definir políticas que guiam a
fazendo permite manter-se em opções. organização na direção do
um nível comparável de serviço atingimento de suas
ou identificar oportunidades para metas e seus objetivos.
aumentar a eficiência.
Grupo de discussão Decomposição funcional Análise de causa-raiz

(focus groups) Faz a conversão das metas Determina a causa
Auxilia na identificação e do negócio em objetivos e implícita de um problema.
discussão dos problemas. medidas atingíveis.
1.1.3 Partes interessadas
É importante determinar quais são as pessoas importantes para convidar a participarem

de reuniões para a identificação dos problemas e quais seriam os principais atores dessa
tarefa. Lembre-se de convidar sempre o patrocinador, pois ele é um dos principais
interessados e é quem deve aprovar as ações e se certificar de que a necessidade do
negócio será resolvida.
Identifique também alguém que seja especialista no domínio ou usuário final, que
seja profundo conhecedor de itens como sistemas, processos operacionais, limitações e
oportunidades de melhoria. Também podem participar o especialista em implementação,
eventuais clientes, eventuais fornecedores, etc. Como resultado dessa tarefa, encontraremos
a necessidade do negócio (IIBA, 2011).
Conhecer qual é a necessidade de negócio é muito importante, pois ela é um guia

para as possíveis soluções e também para outras tarefas de análise de negócios.
Na Figura 1, foi apresentada a entrada da definição da necessidade do negócio. Segundo

o IIBA (2011), a saída desse diagrama é justamente uma necessidade do negócio que descreve
um problema que a organização esteja enfrentando, que pode vir a enfrentar ou, ainda, uma
oportunidade que não foi aproveitada, e qual o resultado desejado. A necessidade do negócio
vai guiar a identificação e a definição de possíveis soluções.
1.2 Avaliação de capacidades
O objetivo da avaliação de capacidades é identificar novas competências para atender à

necessidade do negócio. Para isso, é importante identificar lacunas que impedem de alcançar
os resultados esperados.
Ao detectar as capacidades da situação atual, provavelmente será necessário lançar

um projeto para desenvolver aquela capacidade. Mudanças podem ser necessárias em
cada componente da organização, incluindo processos do negócio, funções, linhas de
negócios, estruturas organizacionais, competências da equipe, conhecimento e habilidades,
treinamento, instalações, ferramentas de escritório, localizações físicas da organização, dados
e informação, aplicativos de sistemas e/ou infraestrutura de tecnologia (IIBA, 2011).

Figura 3 – Etapas da avaliação de capacidades
Entradas
5.1 7.6
Necessidade Arquitetura Avaliação do

do negócio corporativa desempenho
da solução
5.2
Avaliar gaps (lacunas)
de capacidades
5.2
Capacidades
requeridas
Fonte: IIBA (2011, p. 92).
1.2.1 Entradas
Para identificar as novas capacidades necessárias à organização, é importante avaliar a

atual capacidade, identificando as melhorias necessárias para alcançar o resultado esperado.
Para isso, é importante ter em mãos os seguintes itens, conforme apresentados na Figura 3:
• Necessidade do negócio: as capacidades são avaliadas em relação à necessidade do

negócio para identificar gaps (lacunas);
• Arquitetura corporativa: define as capacidades atuais de uma organização;
• Avaliação do desempenho da solução: identifica deficiências, problemas ou

limitações de uma solução existente. Em alguns casos, uma solução pode possuir
capacidades que uma organização não está utilizando (ocorre frequentemente com
uma solução “empacotada” ou com serviços terceirizados), que também podem ser
avaliadas em relação à necessidade do negócio.
1.2.2 Técnicas
Algumas técnicas ajudam na avaliação de gaps de capacidade. Para identificar o estágio

atual da organização, de acordo com o IIBA (2011), é importante fazer:
• Análise de documentos: útil para compreender o estado atual da corporação, na

medida em que esse estado atual esteja documentado;

• Análise SWOT: identifica como as capacidades e as limitações atuais (forças e

fraquezas) alinham-se aos fatores influenciadores (oportunidades e ameaças).
1.2.3 Partes interessadas
É importante convidar clientes e fornecedores a participarem de tarefas que podem

impactar no negócio que está sendo alterado ou desenvolvido. Devem ser pessoas com alto
nível de conhecimento da tarefa que reconhecem fraquezas, forças, ameaças e oportunidades
de negócio, tais como o especialista no domínio, o usuário final e o especialista em
implementação. A participação desses profissionais é importante para a definição das novas
capacidades (PRESSMAN, 2011).
O resultado é a compreensão das capacidades atuais da organização e das novas

capacidades que podem ser requeridas para atender à necessidade do negócio (IIBA, 2011).
1.3 Definição da solução

O propósito da definição da solução é conceituar a solução recomendada em um nível
de detalhes suficiente para permitir que as partes interessadas compreendam quais novas
capacidades de negócio uma iniciativa entregará. O escopo pode ser alterado para atender
ao orçamento, tempo, qualidade e outras restrições (IIBA, 2011).
É muito importante identificar aquela solução que trará maior valor agregado à
organização, que poderá ser utilizada de maneira eficaz e que é factível de ser implementada.
Figura 4 – Etapas para definição do escopo da solução
Entradas
6.4 5.1 5.2 5.3
Suposições Necessidade Capacidades Abordagem

e restrições do negócio requeridas da solução
5.4
Definir o escopo
da solução
5.4
Escopo da
solução
Fonte: IIBA (2011, p. 98).

A solução é descrita no nível das maiores funcionalidades e funções a serem incluídas

e das interações que a solução terá com pessoas e sistemas fora do seu escopo. Ela declara
os componentes incluídos e excluídos do escopo da solução e ainda descreve as unidades
de negócio que serão envolvidas, os processos de negócio a serem aperfeiçoados ou
redesenhados, os responsáveis pelos processos e sistemas de TI e outras tecnologias que
serão provavelmente afetados (IIBA, 2011).
1.3.1 Entradas
A figura anterior apresenta as primeiras tarefas para obter a definição do escopo da

solução. Essas tarefas são detalhadas a seguir.
• Suposições e restrições: suposições e restrições relevantes podem incluir pressupostos

sobre como as partes interessadas irão responder a um novo produto ou serviço, ou a
respeito da disponibilidade da tecnologia. Restrições podem incluir ainda limitações
em relação ao que pode ser incluído no escopo da solução, como qualquer limitação
de fundos ou cronograma, além de padrões, políticas e regulamentações significativos
a serem seguidos e os dados de apoio requeridos.
• Necessidade do negócio: corresponde às metas, aos objetivos e aos resultados

desejados pela organização.
• Capacidades requeridas: nessa tarefa, deve ser descrito como as novas capacidades
são requeridas para atender à necessidade do negócio e como elas servem de base
para o escopo da solução.
• Abordagem da solução: a abordagem geral para a entrega das novas capacidades

requeridas pelo negócio será usada na avaliação das opções para a implementação
dos componentes da solução.
1.3.2 Elementos
A definição do escopo da solução deve descrever as funcionalidades principais, as

características, as inter-relações e as capacidades que serão entregues; a abordagem de
implementação deverá dar suporte à solução e descrever como e quando as novas capacidades
estarão disponíveis. A seguir, são detalhados os elementos da definição do escopo da solução,
de acordo com o IIBA (2011).
• Definição do escopo da solução: a solução é descrita no nível das maiores

funcionalidades e funções a serem incluídas e das interações que a solução terá com
pessoas e sistemas fora do seu escopo. Declara os componentes incluídos e excluídos
do escopo da solução. Descreve as unidades de negócio que serão envolvidas, os
processos de negócio a serem aperfeiçoados ou redesenhados, os responsáveis pelos
processos e sistemas de TI e outras tecnologias que serão provavelmente afetadas.

• Abordagem de implementação: descreve como a abordagem de solução escolhida

irá entregar o escopo da solução. Por exemplo, se a abordagem de solução envolve a
divisão do projeto proposto em liberações de subconjuntos úteis de funcionalidades
para o negócio, a abordagem de implementação descreverá a funcionalidade em
cada liberação e o cronograma esperado das entregas. Se a abordagem de solução
envolver a terceirização de processos-chave, a abordagem de implementação definirá
quais processos são candidatos à terceirização ou o processo que será usado para
identificar aqueles candidatos.
• Dependências: define as principais dependências de negócio e as técnicas que irão

impor restrições ao esforço de entrega da solução, incluindo dependências que
possam existir entre os componentes da solução.
1.3.3 Técnicas
As técnicas utilizadas para elaborar o escopo da solução, segundo o IIBA (2011), são:
• Decomposição funcional: objetiva compreender o escopo do trabalho e quebrar o

escopo da solução em produtos de trabalho e entregas menores;
• Análise de interfaces: descreve o escopo de trabalho requerido para a integração da

nova solução aos ambientes de negócios e técnicos;
• Modelagem de escopo: identifica fronteiras apropriadas para o escopo da solução;
• Histórias do usuário: descrevem as partes interessadas e as metas que o sistema

suporta. Também podem ser usadas para definir o escopo da solução.
É importante elaborar uma declaração de visão ou problema informando a necessidade

do negócio, identificando as principais partes interessadas e descrevendo brevemente o
impacto positivo que, ao atender à necessidade do negócio, a solução terá sobre as partes
interessadas. Veja um exemplo de declaração de visão ou problema na Figura 5.
Figura 5 – Exemplo de declaração do problema
O problema: Descrever o problema
Afeta: As partes interessadas afetadas pelo problema.
O impacto é: Qual é o impacto do problema sobre cada parte interessada?
Uma solução bem-sucedida poderia: Listar alguns dos principais benefícios de uma boa solução.
Fonte: IIBA (2011, p. 100).
É de grande importância que as partes interessadas estejam presentes nessa etapa: o

patrocinador, que autoriza o financiamento; o especialista no assunto, que auxilia na estimativa
dos benefícios de negócio esperados da nova iniciativa; o especialista na implementação

da solução, que auxilia na estimativa de projeções de custos para a tecnologia necessária
para suportar a nova solução; o gerente do projeto, que participa no desenvolvimento das
estimativas de tempo e custo e pode desenvolver um plano de projeto preliminar ou estrutura
analítica do projeto com a equipe do projeto (IIBA, 2011).
Como vimos nesta aula, tivemos a oportunidade de compreender a análise corporativa
de negócios. Através de tarefas de entrada, conseguimos encontrar o escopo da solução
conforme proposto.
Aprendemos que é de extrema importância compreender a real necessidade de negócio

da corporação e determinar as soluções e as abordagens necessárias.
Na sequência, vimos como identificar as capacidades existentes na organização, para que

a solução possa atender às novas necessidades de negócios e, assim, alcançar os resultados
desejados.
Finalizamos com a abordagem da solução, etapa em que é apresentada a solução

mais viável que atenda o negócio, com um nível de detalhe suficiente para que as partes
interessadas possam entender.
Referências

AMGH, 2011.

Aula 04
Gerenciamento e comunicação de requisitos
• Compreender como é realizado o gerenciamento e a comunicação de
requisitos.
Temas
Introdução
1 Gerenciamento e comunicação dos requisitos
2 Tarefas do gerenciamento e comunicação dos requisitos
Referências
Professor Autor
Introdução
Esta aula tem como objetivo expor ao aluno uma série de tarefas que o BABOK® apresenta
como estruturas que permitem o gerenciamento e a comunicação de requisitos.
A aula se concentra no tema gerenciamento e comunicação dos requisitos, que é dividido

em cinco tarefas: gerenciar o escopo e os requisitos da solução; gerenciar a rastreabilidade
dos requisitos; manter requisitos para reutilização; preparar pacote de requisitos e comunicar
os requisitos.
Por último, conheceremos os conceitos do gerenciamento do desempenho da análise de

negócios, que irá permitir que o trabalho de análise de negócios seja avaliado.
A sugestão que tenho é a de que, sempre que você se envolver com o processo de
conhecimento de uma nova técnica, ferramenta ou processo, pense em como ela poderia ser
aplicada no seu dia a dia.
Boa leitura!
1 Gerenciamento e comunicação dos requisitos

A área de conhecimento de gerenciamento e comunicação dos requisitos concentra as
atividades que permitem gerenciar e expressar os requisitos para as partes interessadas.
Precisamos levar em conta que o grupo de partes interessadas é geralmente amplo e diverso.
Dentro desse contexto, existe a necessidade de comunicar os requisitos apropriados para
cada grupo e também utilizar um formato de comunicação que esteja adequado ao seu meio.
É importante que se tenha uma segurança acerca do entendimento da solução pelas partes
interessadas. Isso fará com que tenham condições de aprovar as soluções propostas (IIBA,
2011).
A figura 1, a seguir, apresenta o processo em que o IIBA (2011) divide a área de

gerenciamento e comunicação dos requisitos em cinco tarefas, que iremos estudar
detalhadamente nas próximas seções.

Figura 1 – Diagrama de entrada/saída do gerenciamento e comunicação de requisitos
Entradas Tarefas Saídas
2.4 * 4.1 4.5

4.1 4.2
Gerenciar o Gerenciar
Plano de Comuni- Ativos de Requisitos escopo e os rastreabilidade Requisitos Requisitos
cação da Análise processos requisitos da solução dos requisitos (aprovados) (Comunicados)
de Negócios organizacionais
4.3 4.4
Manter requisitos Preparar o pacote
2.5 6.2 5.4  para a reutilização de requisitos  4.3 4.2
Plano de Estrutura de Escopo da 4.5 Requisitos Requisitos

Gerenciamento requisitos Solução Comunicar (mantidos e (rastreados)
de Requisitos Requisitos reusáveis)
2.2
4.4
Lista de partes
interessadas, papéis e Pacotes de
responsabilidades requisitos
Fonte: IIBA (2011, p. 67).
2 Tarefas do gerenciamento e comunicação dos requisitos
2.1 Gerenciar o escopo e os requisitos da solução

O gerenciamento do escopo e dos requisitos da solução é o processo responsável por
conseguir o consenso entre as principais partes interessadas acerca do escopo comum da
solução e os requisitos que serão implementados, além de conservá-los (IIBA, 2011).
De acordo com Sommerville (2011), o gerenciamento de requisitos é o processo de

compreender e controlar as mudanças nos requisitos de sistemas. Esse processo é realizado
em conjunto com os outros processos da engenharia de requisitos e o seu planejamento tem
início a partir do levantamento inicial dos requisitos, ou seja, no processo de identificação de
requisitos, no momento em que um esboço da versão do documento de requisitos estiver
disponível.
A tarefa envolve obter a aprovação das partes interessadas que têm autoridade para
determinar os requisitos. Após essa aprovação, uma linha de base pode ser gerada e, a partir
desse ponto, qualquer alteração nos requisitos deverá envolver um processo de gestão de
mudanças.
Conforme os requisitos são desenvolvidos e revisados, é comum o surgimento de

conflitos, que podem estar vinculados a prioridades ou requisitos contrários, pois são vistos
de diferentes perspectivas por áreas diferentes. Os conflitos precisam ser resolvidos antes
de o projeto ser aprovado, e uma das técnicas é a facilitação da comunicação entre as áreas
conflitantes.
A saída desse processo é uma lista de requisitos que as partes interessadas aprovam e
que deve estar pronta para ser utilizada nas próximas fases do desenvolvimento do projeto
(IIBA, 2011).
2.2 Gerenciar a rastreabilidade dos requisitos

O objetivo desse processo é criar e manter relacionamentos entre objetivos de negócios,
requisitos, outras entregas da equipe e componentes da solução para apoiar a análise de
negócios ou outras atividades.
O rastreamento de requisitos pode ser feito em nível de pacote de requisitos ou

individualmente. Esse processo oferece sustentação aos procedimentos de análise de
impacto, gerenciamento de mudanças e alocação de requisitos (IIBA, 2011).
É importante ressaltar que só existe gestão efetiva de requisitos quando este

procede à rastreabilidade dos requisitos. Pode-se fazer o delineamento dos requisitos
quando é possível descobrir quem sugeriu os requisitos, a razão da sua existência,
os relacionamentos que se estabelecem entre si e de que forma se relacionam com
o restante da informação de desenvolvimento. Com efeito, a rastreabilidade é uma
característica importante, mas o grande desafio está na decisão das ligações que se
devem manter. Essas decisões devem ser tomadas na fase inicial do projeto com a ajuda
das linhas orientadoras do desenho. Nesse sentido, devem ser definidas regras sobre
as ligações a estabelecer, como as estabelecer e quando as atualizar (SOMMERVILLE,
2011).
Através do rastreamento, pode-se acompanhar o progresso dos requisitos por todo o

ciclo de vida até a solução do desenvolvimento. É viável efetuar a ligação dos requisitos de
negócio aos de solução, aos de stakeholders, aos artefatos criados e aos diversos componentes
que poderão existir, provendo uma maneira de gerenciar o escopo da solução e identificar
mudanças.
Pohl e Rupp (2011) lembram que a rastreabilidade de requisitos pode ser demonstrada
de diversas formas, e as mais comuns são: referências textuais e hyperlinks, matrizes de
rastreabilidade e grafos de rastreabilidade:

• Referências textuais e hyperlinks: são a forma mais simples de representar a

vinculação entre requisitos e outros requisitos ou artefatos, em que uma referência
textual ou uma vinculação através de hyperlink é realizada no artefato inicial, em
relação ao artefato-alvo.
• Matrizes de rastreabilidade: conforme a Figura 2, as matrizes de rastreabilidade

sinalizam na interseção entre linhas e colunas quando há um relacionamento entre
os artefatos relacionados. Podem ser vinculados como linhas e colunas os requisitos,
gerando assim uma matriz de rastreabilidade de requisitos, ou como linhas os
requisitos e colunas de outros artefatos, por exemplo, casos de teste.
Figura 2 – Matriz de rastreabilidade de requisitos
Artefatos Alvo
derivados Req - 1 Req - 2 Req - 3 Req - 4 Req - 5
Req - 1 X
Artefatos Iniciais
Req - 2 X
Req - 3 X
Req - 4 X
Req - 5
Fonte: Pohl e Rupp (2011, p. 156).
• Grafos de rastreabilidade: os grafos de rastreabilidade representam em cada nó

um artefato, e as linhas representam o relacionamento entre os artefatos. Pode-se
determinar representações diferentes para cada tipo de artefato, como podemos
verificar na figura a seguir.

Figura 3 – Grafo de rastreabilidade de requisitos
Req - 6
Req - 1
Comp - 3
C-1
Req - 2
C-2
C-4 Req - 5
C-3 Req - 3
Comp - 2
Comp - 1
Informação sobre o contexto do sistema
Requerimentos
realizado por
Componentes
é origem
refina
Fonte: Pohl e Rupp (2011, p. 157).
A saída da tarefa gerenciar a rastreabilidade de requisitos é um mapeamento do

relacionamento entre os requisitos, permitindo que sejam facilmente identificados os
impactos das mudanças propostas (IIBA, 2011).
Em um cenário de poucos requisitos, esses tipos de documentos de rastreabilidade são úteis

e trazem agilidade para as análises do projeto. Pohl e Rupp (2011) alertam para a complexidade
de um contexto de, por exemplo, dois mil requisitos. Só em uma matriz de rastreabilidade de
requisitos estamos falando em quatro milhões de células! Qual abordagem pode ser utilizada
para melhorar a manutenção e visualização desses relacionamentos no contexto apresentado?
2.3 Manter requisitos para reutilização

A ideia desse processo é a de que os requisitos sejam mantidos de forma a serem
reutilizados futuramente. É comum que vários requisitos sejam utilizados frequentemente
dentro de uma organização e, portanto, devem estar bem documentados, claramente
definidos e disponíveis para os todos os analistas. A denominação para esse tipo de requisito
é requisito recorrente (IIBA, 2011).
Para reutilizar requisitos, estes precisam estar claramente nomeados e definidos,

além de estarem facilmente disponíveis para outros analistas. Esses requisitos podem ser
armazenados em um repositório e uma pessoa deve ser designada para gerenciá-lo. Quando
um requisito existente precisa ser modificado, ele pode ser acessado do repositório para
reúso (IIBA, 2011).
Figura 4 - Como manter requisitos para reutilização
Entradas
*
Ativos de Requisitos
Processos
Organizacionais
4.3
Manter Requisitos
para Reutilização
4.3
Requisitos
(Mantidos e
Reusáveis)
Fonte: IIBA (2011, p. 75).
Os requisitos recorrentes são aqueles que uma unidade organizacional tem que atender
regularmente. Podem incluir obrigações contratuais, padrões de qualidade, acordos de nível
de serviço, regras de negócio, processos de negócio ou requisitos que descrevam os produtos
do trabalho que o grupo realiza.
Mesmo que um requisito já tenha sido atendido, ainda será um requisito enquanto
a parte interessada precisar dele. Manter esses requisitos ajuda a executar melhorias no
produto e futuras mudanças no sistema. Requisitos existentes também podem ser usados em
projetos de negócios relacionados.
A saída dessa tarefa são requisitos descritos de uma forma que possam ser utilizados em
longo prazo na organização, não dependendo de que as partes interessadas que os solicitaram
estejam disponíveis na organização (IIBA, 2011).

2.4 Preparar o pacote de requisitos

Preparar o pacote de requisitos é o processo de selecionar e estruturar um conjunto
de requisitos de uma forma adequada para garantir que os requisitos sejam efetivamente
comunicados, entendidos e aproveitáveis por um grupo ou grupos de partes interessadas.
Para o IIBA (2011), os requisitos devem ser apresentados em um formato compreensível

pelas partes interessadas, e o processo de preparar o pacote de requisitos descreve o
trabalho necessário para decidir quais formatos são mais apropriados para um projeto em
particular e suas partes interessadas. Eles devem ser claros, concisos, precisos e apresentar o
nível apropriado de detalhamento. A documentação de requisitos deve ser criada apenas na
extensão necessária para assegurar o claro entendimento pela equipe.
Pacotes de requisitos devem ser preparados por várias razões, incluindo, mas não
limitando, a avaliação antecipada da qualidade e do planejamento, verificação de possíveis
alternativas, aprovações e revisões formais, entradas no design da solução, conformidade a
obrigações regulatórias e contratuais e manutenção para a reutilização.
Figura 5 – Preparar o pacote de requisitos
Entradas
2.4 * 6.2
Plano de Ativos de Requisitos Estrutura de

Comunicação da Processos Requisitos
AN Organizacionais
4.4
Preparar o Pacote
de Requisitos
4.4
Pacotes de
Requisitos
Fonte: IIBA (2011, p. 78).

O formato desses pacotes pode ser a documentação formal, uma apresentação ou pode
ocorrer através de modelos, por exemplo, um mapa de processo.
2.5 Comunicar requisitos

O processo de comunicação de requisitos está vinculado a toda e qualquer iniciativa
de comunicação realizada no processo de requisitos e que deve ser feita de forma efetiva
e concisa, exigindo do engenheiro de requisitos tanto habilidades técnicas (de requisitos)
quanto interpessoais (de comunicação).
O principal objetivo dessa tarefa é garantir que as partes interessadas conheçam e

compreendam os requisitos e qual é a situação atual. Comunicar requisitos inclui conversas,
anotações, documentos, apresentações e discussões.
Nem toda comunicação pode ou deve ser planejada, e a comunicação informal de

requisitos provavelmente será necessária durante o desempenho de muitas tarefas de
análise. Em muitos casos, a comunicação de requisitos pode levar à elicitação de requisitos
adicionais.
Antes de fazer qualquer apresentação de requisitos para uma plateia, determine um

formato apropriado para a apresentação. Isto porque a formalidade da apresentação é
dirigida pelo objetivo da comunicação e pelas necessidades da plateia. Por exemplo, o analista
de negócios pode ser requisitado a apresentar pontos-chave, utilizando slides e material
impresso. Isto pode ser necessário ao apresentar para membros seniores que não estejam
envolvidos ativamente com o desenvolvimento do projeto, mas que precisam entender os
requisitos em um nível mais alto (IIBA, 2011).
Nesta aula pudemos verificar etapas importantes do processo de análise de negócios,
suas entradas, ferramentas e saídas.
Nosso estudo se concentrou na área de conhecimento de gerenciamento e comunicação

de requisitos e aprendemos as cinco tarefas que nos permitem realizar tais atividades com
segurança e organização.
Quanto mais aumenta nosso conhecimento dos processos que o BABOK® sugere, fica
eminente a certeza de que ele é o modelo que tem as melhores práticas mundiais para a área
de análise de negócios.
Finalizamos esta aula munidos de um conhecimento maior sobre os processos de análise

de negócios, o que nos permite aplicá-los na prática dentro das organizações em que atuamos.

Referências
IIBA. Um guia para o corpo de conhecimento de análise de negócios: Guia BABOK®. Versão
2.0. Toronto: Theiiba.org, 2011.
POHL, Klaus; RUPP, Chris. Requirements Engineering Fundamentals: A Study Guide for
the Certified Professional for Requirements Engineering Exam – Foundation Level. IREB
Compliant, Rocky Nook Inc., 2011.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

Aula 05
Análise de requisitos
• Compreender a análise, especificação, verificação e validação de requisitos.
Temas
Introdução
1 Modelagem de requisitos
2 Restrições
3 Verificação e validação de requisitos
Referências
Professor Autor
Introdução
Nesta aula temos a oportunidade de conhecer os mecanismos pelos quais poderemos
realizar o trabalho de análise de requisitos.
Começamos, então, apresentando os aspectos de modelagem de requisitos. O papel
fundamental dessa seção é apresentar os meios que devemos utilizar para realizar uma boa
documentação de requisitos. Conheceremos os dois tipos de documentação e também um
compêndio de boas práticas de documentação de requisitos.
Na sequência, veremos o conceito de restrições, que é dividido em negócio e técnicas e
é uma realidade em todo o projeto de desenvolvimento de software.
Para finalizar a aula, serão elucidados os conceitos de validação e verificação de requisitos,
trazendo uma série de dicas que podem ser usadas na prática.
1 Modelagem de requisitos
De acordo com o IIBA (2011), para permitir uma análise das necessidades impostas pelas
partes interessadas ou então da documentação do estado atual da organização avaliada,
é importante preparar documentos de requisitos que contenham uma combinação de
declarações textuais em linguagem natural, matrizes, diagramas e de modelos formais.
Pohl e Rupp (2011) consideram a tarefa de documentar os requisitos como obrigatória,

principal e a mais importante tarefa da engenharia de requisitos, pois consiste em documentar
os requisitos do sistema de forma adequada. Os autores nos dizem que uma especificação de
requisitos é uma coleção de requisitos representada de forma sistemática, característicamente
para um sistema ou componente, atendendo a determinados critérios.
Para entendermos melhor as razões para a importância da documentação de requisitos,

temos que considerar alguns pontos importantes:
01 muitas pessoas são envolvidas na documentação;
02 os requisitos formam a base para o desenvolvimento do sistema e têm relevância legal;
03 os documentos de requisitos têm uma forte tendência de se tornarem complexos;
devemos manter acessíveis os documentos de requisitos a todos os públicos de partes

04
interessadas; e
os envolvidos podem ter entendimentos diferentes de determinado assunto e a

05
documentação é uma forma de unificar o entendimento.

O IIBA (2011) apresenta um processo para especificar e modelar requisitos, que é

apresentado na Figura 1, a seguir. As entradas são os requisitos declarados, identificados
pelas necessidades apresentadas pelas partes interessadas no processo de levantamento de
requisitos, enquanto a estrutura de requisitos é a definição de como esse requisito se encaixa
na lista geral de requisitos, como ele se relaciona e se vincula aos demais. Como saída temos
uma relação de requisitos modelados e especificados.
Figura 1 – Entrada/Saída de Especificar e modelar requisitos
Entradas
3.3 6.2
Requisitos Estrutura de
(Declarados) Requisitos
6.3
Especificar e Modelar
Requisitos
6.3
Requisitos
(Analisados)
Gerenciamento e
6.1 6.5 Comunicação
Priorizar Requisitos Verificar Requisitos de Requisitos
+
Fonte: IIBA (2011, p. 114).
1.1 Tipos de documentação

Requisitos podem ser documentados utilizando-se uma linguagem natural ou modelos
conceituais. A utilização específica de cada um dos tipos precisa ser avaliada de acordo com o

projeto, mas uma combinação do uso de ambos é geralmente mais adequada, pois é possível
utilizar as melhores características de cada um (POHL; RUPP, 2011).
O IIBA (2011) diz que o tipo de informação a ser comunicada e os receptores da informação
são os fatores que irão definir qual o tipo de documentação a ser utilizada. Os modelos têm a
capacidade de definir um problema, definir as fronteiras de negócio, descrever pensamentos
e fluxos de ação, categorizar e hierarquizar itens, assim como apresentar o relacionamento
entre componentes e apresentar a lógica do negócio.
O IEEE (2014) ressalta a importância da utilização de gestão de configuração sob

os requisitos documentados e recomenda, inclusive, a utilização de uma ferramenta de
documentação e gestão de requisitos.
1.1.1 Linguagem natural
A linguagem natural, ou seja, o formato de prosa livre é, na prática, o formato de

documentação mais aplicado. Sua principal vantagem é a de estar centrada na experiência
que as partes interessadas têm na língua nativa, sem a necessidade de aprendizagem de
quaisquer notações de linguagem. Outro fator preponderante é a possibilidade de se
documentar praticamente qualquer tipo de requisito, considerando-se a versatilidade da
língua. A grande desvantagem ao utilizar a prosa livre é a possibilidade de gerar requisitos
ambíguos (POHL; RUPP, 2011).
1.1.2 Modelos conceituais
A utilização de modelos conceituais permite que os requisitos sejam documentados

de forma compacta, e a utilização de um modelo reduz a ambiguidade, considerando o
regramento de notações do modelo escolhido.
Portanto, é muito importante que o leitor desses requisitos seja treinado em tal modelo
para permitir que ele consiga interpretar os requisitos representados. Essa necessidade,
muitas vezes, exclui partes interessadas que não têm conhecimento técnico de modelagem
de requisitos.
Os tipos de diagramas mais utilizados para representação de requisitos são: Diagramas

de Caso de Uso, Diagrama de Classes, Diagrama de Atividades e Diagrama de Estados (POHL;
RUPP, 2011).
1.2 Como escrever um bom conjunto de requisitos

Preparamos aqui um conjunto de boas práticas na escrita de requisitos, de acordo com
o IIBA (2011) e Pohl e Rupp (2011):
01 Expressar apenas um requisito por vez;
02 Preocupar-se com a não ambiguidade e com a consistência;
03 Escrever de forma que não haja a necessidade de que o leitor tenha conhecimento prévio do domínio;
04 Escrever em voz ativa;
05 Manter requisitos rastreáveis;
06 Escrever requisitos que sejam verificáveis;
07 Expressos em verbo ou frase verbal;
08 Definição de frases curtas e de parágrafos curtos; e
09 Criação de um glossário de termos comuns.
O IIBA (2011) sugere também a utilização de diversas técnicas que podem ser utilizadas
para especificar ou modelar requisitos:
01 Definição dos critérios de aceite e de avaliação;
02 Análise de regras de negócio;
03 Dicionário de dados e glossário;
04 Diagramas de fluxo de dados;
05 Modelagem de dados;
06 Decomposição funcional;
04 Diagramas de fluxo de dados;
05 Modelagem de dados;
06 Decomposição funcional;
07 Análise de interfaces;
08 Modelagem da organização;
09 Modelagem de processos;
10 Prototipagem;
11 Cenários e casos de uso;
12 Diagramas de sequência;
13 Diagramas de estados; e
14 Histórias de usuários.
2 Restrições
As restrições são determinadas como limitações às soluções possíveis e é papel do analista
de negócios documentar todas as restrições ou limitações da solução. Essas limitações devem
especificar o aspecto atual e o estado futuro, que não podem ser mudados.
A documentação das restrições deve incluir seus atributos, por exemplo: data da
identificação, proprietário, impacto, se possui risco associado e quaisquer outras informações
complementares.
A principal entrada para esse processo são as preocupações das partes interessadas, que
podem ser obtidas através de entrevistas junto ao grupo (IIBA, 2011).
As restrições são divididas em dois tipos: de negócio e de técnicas. A seguir veremos o

que cada tipo significa e como impacta em um projeto.
Restrições de negócio
As restrições de negócio se vinculam a limitações do negócio. Essas restrições podem

estar vinculadas a restrições orçamentárias, legais ou até mesmo de tempo e de habilidades

das partes interessadas.
Restrições técnicas
O IIBA (2011) define as restrições técnicas como as vinculadas à arquitetura da solução,

que podem ter impacto nos requisitos. Pode, por exemplo, ser a definição de uma linguagem
de desenvolvimento que não permita o atendimento de uma necessidade expressada por
uma parte interessada. O analista de negócios deve ter o cuidado de procurar uma alternativa
junto à equipe do projeto para atendimento da necessidade de negócio associada.

De acordo com IIBA (2011), a verificação de requisitos garante que as especificações e os
modelos de requisitos atendam ao padrão necessário de qualidade para permitir que sejam
usados de forma efetiva para guiar o trabalho futuro, e a validação de requisitos consiste
em garantir que todos os requisitos entreguem valor para o negócio, cumpram suas metas
e objetivos e satisfaçam a uma necessidade de uma parte interessada. Sommerville (2011)
complementa, afirmando que a validação de requisitos é o processo em que se verifica que o
sistema é o que o cliente realmente almeja.
Verificar requisitos garante que eles foram definidos corretamente, isto é, que eles
possuem uma qualidade aceitável. Requisitos que não atendem aos padrões de qualidade
são defeituosos e devem ser revisados (IIBA, 2011).
Os documentos de requisitos servem como base para toda e qualquer etapa posterior
do desenvolvimento de um software. A fase de verificação e validação de requisitos evita a
proliferação de um erro, fazendo com que seja necessário corrigir apenas os documentos
de requisitos. Caso contrário, todos os artefatos envolvidos na construção de um software
precisariam ser corrigidos, tais como modelos de dados, códigos-fonte, documentos de
projeto e arquitetura e casos de testes (POHL; RUPP, 2011).
Pohl e Rupp (2011) propõem uma avaliação dos critérios de qualidade dos requisitos,
como é apresentado na tabela a seguir.

Tabela 1 – Aspectos de qualidade x Critérios de aceite
Aspectos de qualidade Critérios de aceite

Completude (no conjunto de todos os requisitos)
Completude (individualmente)
Rastreabilidade
Exatidão
Conteúdo
Consistência
Ausência de decisões de projeto prematuras
Verificabilidade
Adequação às necessidades
Conformidade com o formato especificado
Conforme com a estrutura da documentação
Documentação Inteligibilidade ou compreensibilidade
Não ambiguidade
Conformidade com as normas de documentação
Acordado
Acordo Acordado mesmo após alterações
Conflitos resolvidos
Fonte: Adaptado de Pohl e Rupp (2011).
De acordo com o IIBA (2011), a verificação de requisitos constitui-se de uma checagem

final executada pelo analista de negócios e as principais partes interessadas para determinar
que os requisitos estejam:
01 Prontos para revisão e validação formal pelos clientes e usuários;
02 Provendo toda a informação necessária para o trabalho que será realizado baseado nos requisitos.
Avaliar qual será o resultado para a parte interessada quando a sua necessidade for
satisfeita pode ser útil na validação dos requisitos. A implementação dos requisitos como
um todo deve ser suficiente para atingir o estado futuro desejado para clientes e usuários.
Em muitos casos, partes interessadas possuem necessidades e expectativas diferentes
ou conflitantes e que podem ser expostas através do processo de validação para serem
reconciliadas (IIBA, 2011).
Na abordagem do IIBA (2011), um requisito de alta qualidade deve apresentar, no

mínimo, as seguintes características:

01 Coesão:
um conjunto coeso de requisitos está relacionado a apenas uma coisa, seja ela um processo de
negócio, regra de negócio, unidade organizacional etc. Todos os requisitos, em um conjunto ou modelo,
devem apoiar o seu propósito e escopo geral.
02 Completude:
o conjunto total de requisitos deve representar todos os requisitos relevantes. Além disso, todo
requisito individual deve ser completo. É necessária a garantia de que cada requisito seja autocontido,
sem qualquer informação faltante.
03 Consistência:
garantia de que os requisitos individuais não conflitem entre si ou que descrevam o mesmo requisito
utilizando palavreado diferente. Além disso, o nível de detalhes fornecidos por cada requisito, em um
conjunto ou modelo, deve ser o mesmo.
04 Correção:
defeitos nos requisitos levarão a defeitos na solução resultante.
05 Viabilidade:
cada requisito deve ser implementável dentro da infraestrutura existente, dentro do orçamento existente, prazo
e recursos disponíveis para a equipe (ou o projeto deve desenvolver a capacidade para implementar o
requisito). O analista de negócios precisa trabalhar junto à equipe do projeto para tomar essas decisões.
06 Ajustabilidade/adaptação:
requisitos inter-relacionados devem ser mantidos agrupados a fim de que se tornem modificáveis. Essa
característica é demonstrada através de uma estruturação lógica dos requisitos.
07 Não ambiguidade:
requisitos individuais nunca podem ser pouco claros. Um requisito não pode permitir a formação de múltiplas e
divergentes interpretações válidas.
08 Testabilidade:
deve haver uma forma de provar que um requisito foi atendido. Cada requisito deve ser testável – isto é, deve
ser possível desenhar um teste que possa ser usado para determinar se uma solução atendeu ao requisito, ou
utilizar algum outro meio de determinar o aceite, ou não, de uma solução que atende ao requisito.
Para realizar a validação dos requisitos precisamos estar atentos aos seguintes critérios:
Identificar suposições
Em muitos casos pode não ser possível provar que a implementação do requisito
resultará no benefício desejado. Se uma organização está lançando um produto ou serviço
sem precedentes, pode ser necessário criar suposições a respeito da resposta dos clientes ou
das partes interessadas, uma vez que não há experiências similares nas quais se possa basear.
Em outros casos, pode ser difícil ou impossível provar que um problema particular derive de
uma causa-raiz identificada. Partes interessadas podem ter assumido que certos benefícios
irão resultar da implementação de um requisito e essas suposições devem ser identificadas e
definidas, de forma que os riscos associados possam ser gerenciados (IIBA, 2011).
Definir critérios de avaliação mensuráveis
Enquanto os benefícios previstos do negócio são definidos no business case, os critérios

de medição e processos de avaliação específicos podem não ter sido incluídos. Seguindo-se
a definição dos benefícios que irão resultar na implementação de um requisito, é necessário

definir o critério de avaliação que será usado para avaliar quanto sucesso a mudança resultante
teve, uma vez que a solução seja implantada, para informações sobre a seleção dos critérios
apropriados para detalhes sobre como essa avaliação é realizada após a implementação (IIBA,
2011).
Determinar o valor para o negócio

O business case, além de definir o valor entregue por uma solução que atenda ao seu
escopo, também possibilita avaliar requisitos ou funcionalidades individualmente para
determinar se eles também entregam valor para o negócio. Esboça algumas maneiras através
das quais um requisito pode entregar valor para o negócio. Um requisito que não entrega
valor direto ou indireto para uma parte interessada é um forte candidato à eliminação. O
valor não precisa ser monetário. Isto porque valor para o negócio pode ser entregue através
de requisitos que apoiam a conformidade com regulamentos ou outros padrões, alinhamento
junto a padrões e políticas internas da organização ou que aumentam a satisfação das partes
interessadas, mesmo se essas coisas não possuírem um benefício financeiro direto mensurável
(IIBA, 2011).
Determinar dependências para a realização dos benefícios
Nem todos os requisitos contribuem diretamente para o resultado final desejado pela
organização e que está descrito no business case; a finalidade dos requisitos é traçar um alvo
no qual podemos chegar perto dos objetivos finais (IIBA, 2011).
Avaliar o alinhamento com o business case e com o custo da oportunidade
Um requisito pode ter valor para uma parte interessada e, ainda assim, não ser uma
parte desejável de uma solução. Um requisito que não está alinhado ao business case deve ser
definido e aprovado em um business case à parte, ou considerado para remoção do escopo
da solução. Em última análise, cada requisito deve ser rastreável até os objetivos no business
case e deve também minimizar o custo da oportunidade da implementação (IIBA, 2011).
O IEEE (2014) sugere que os meios mais comuns de validação sejam por inspeção ou
revisões dos requisitos. Um grupo de colaboradores é atribuído para procurar erros, suposições
equivocadas, falta de clareza e desvio da prática normal. A composição do grupo que conduz
a revisão é importante (pelo menos um representante do cliente deve ser incluído para um
projeto, por exemplo, orientado para o cliente) e pode ajudar a fornecer orientações sobre o
que procurar no formato de checklists.
Os processos aqui apresentados são essenciais para ter uma boa qualidade do
desenvolvimento do software. É primordial considerar a importância dos requisitos dentro

de um projeto de software, lembrando que a fase de requisitos é preliminar às demais, o que

faz com que erros não reconhecidos nessa fase impliquem em uma necessidade de correção
em cascata.
A escrita de requisitos em um nível alto de qualidade eleva as chances de o projeto ter

sucesso. As fases de verificação e validação permitem que os deslizes sejam gerenciados e
corrigidos. Já o levantamento de restrições permite que se conheçam as limitações que irão
ocorrer no projeto, com o intuito de se preparar para as situações não contempladas.
Esta aula teve como objetivo preparar o aluno para garantir uma boa documentação
de requisitos nos projetos de que participa. O desafio lançado é aplicar, no seu dia a dia, as
técnicas aqui apresentadas e avaliar os resultados em curto, médio e longo prazos.
Referências
IEEE. Guide to the Software Engineering Body of Knowledge: SWEBOK® v. 3.0. IEEE Computer
Society, 2014.
2.0. Toronto: Theiiba.org, 2011.
POHL, Klaus; RUPP, Chris. Requirements Engineering Fundamentals: A Study Guide for
the Certified Professional for Requirements Engineering Exam – Foundation Level. IREB
Compliant, Rocky Nook Inc., 2011.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.

Aula 06
Avaliação e validação da solução
• Conhecer meios para a avaliação e validação da solução
Temas
Introdução
1 Avaliação e validação da solução
2 Avaliação da solução da proposta
3 Definição dos requisitos de transições
4 Validação da solução
5 Avaliar o desempenho da solução
Referências
Professor Autor
Introdução
Nesta aula, conheceremos os mecanismos para realizar a avaliação e a validação de
soluções de negócios.
Estas etapas são essenciais para que todo o trabalho realizado seja verificado, a fim de
que seja confirmado o atendimento as necessidades da organização.
Esta aula está dividida em uma conceituação inicial sobre a área de conhecimento
Avaliação e Validação da Solução, e posteriormente serão apresentadas quatro tarefas desta
área, que são: avaliação da solução proposta, definição dos requisitos de transição, validação
da solução e avaliar o desempenho da solução.
1 Avaliação e validação da solução

A área de conhecimento Avaliação e Validação da Solução do BABOK® descreve as
tarefas que são executadas para garantir que as soluções encontradas atendam à necessidade
do negócio e para facilitar o sucesso em sua implementação. Essas atividades podem ser
executadas para avaliar e validar processos de negócio, estruturas organizacionais, acordos
de terceirização, aplicações de software e quaisquer outros componentes da solução. A
análise de negócio desempenha um papel vital na garantia de que o processo de revisão,
seleção e desenho da solução seja realizado de uma forma que maximize o valor entregue
para as partes interessadas.
O analista de negócio conhece o ambiente do negócio e pode avaliar como cada solução
proposta poderia afetar esse ambiente. O analista de negócio é responsável por garantir que
as partes interessadas compreendam totalmente os requisitos da solução e que as decisões
de implementação estejam alinhadas com os requisitos relevantes.
De acordo com o IIBA (2011), a execução de todas as atividades de avaliação e

validação da solução é dirigida pelos planos da análise de negócio e métricas de
desempenho da análise de negócio devem ser rastreadas.
2 Avaliação da solução da proposta

Segundo o IIBA (2011), é papel do analista de negócios realizar a avaliação das soluções
propostas com o intuito de determinar o quanto elas atendem aos requisitos das partes
interessadas e da solução. Este processo de avaliação da solução pode ser executada para

uma única solução ou visando a comparação de diversas soluções propostas.
Quando o analista de negócio estiver realizando a avaliação de uma única solução, é

necessário determinar se a solução entrega valor de negócio suficiente para justificar sua
implementação. Este tipo de avaliação é mais comum quando uma solução customizada tiver
sido concebida para atender a uma necessidade específica do negócio.
Já nos casos em que esteja diante das diversas soluções alternativas, o analista de
negócio possui o desafio de procurar determinar qual a solução a ser entregue é de maior
valor do negócio.
Figura 1- Diagrama de Entrada/Saída de avaliar a solução da proposta
Entradas
4.1
6.4
6.1
Suposições e Requisitos Alternativa (s) de

Restrições (Priorizados e Solução
Aprovados)
7.1
Avaliar a Solução
Proposta
7.1
Avaliação da
Solução Proposta
Fonte: IIBA (2011, p. 132).
As Suposições e Restrições podem levar ao favorecimento de certas soluções, enquanto

restrições podem limitar as opções de soluções disponíveis, pois as soluções avaliadas podem
não ter requisitos mínimos determinados por estas restrições.
Através dos requisitos, é possível realizar as análises para identificar as escolhas que
atendem aos requisitos mais importantes. Os requisitos devem estar aprovados para que esta
decisão seja tomada.
Informações a respeito de cada solução proposta devem estar disponíveis. A informação

deve possuir um formato que facilite a comparação efetiva entre as opções disponíveis.

Na dificuldade de tomada de decisão, um sistema de pontuação pode ser usado,

atribuindo pesos a cada importância para organização, e as soluções com maior, ou melhor,
nota são as que receberão a investigação em maior detalhe.
É possível que as alternativas que se encontram apresentem capacidades que estão muito
acima da capacidade da organização, e elas não tragam valor imediato para a empresa, mas
podem ter um futuro potencial para apoiar o desenvolvimento das capacidades que sejam
requeridas (por exemplo, um aplicativo de software pode possuir recursos que a organização
planeja utilizar futuramente).
Quando uma alternativa está sendo provida de forma parcial ou completa por uma
terceira parte, a avaliação da solução deve ser combinada com uma avaliação do fornecedor
para garantir que todas as partes serão capazes de desenvolver e manter um relacionamento
de trabalho saudável.
A avaliação da solução proposta entrega o valor por cada solução proposta. Caso existam
várias soluções disponíveis, uma recomendação sobre a melhor solução deve ser feita.
Caso nenhuma solução entregue valor suficiente para justificar a sua implementação, uma
recomendação para abandono da iniciativa deve ser dada (IIBA, 2011).
3 Definição dos requisitos de transições

O objetivo desta tarefa é definir requisitos para as capacidades necessárias para a
transição entre uma solução existente e a nova solução. Esta etapa também é chamada de
migração (IIBA, 2011).
Na maioria dos casos, uma solução é implementada em uma corporação para aperfeiçoar
ou substituir uma solução existente. Durante o período de transição, a corporação pode
precisar operar as soluções em paralelo, transferir informações entre a solução nova e a
antiga, conduzir treinamentos para capacitar partes interessadas para operar efetivamente a
nova solução, e assim por diante. Além do desenvolvimento em si, a equipe de implementação
talvez tenha que desenvolver capacidades adicionais para apoiar essa transição.
Essas capacidades são requisitos, uma vez que as partes interessadas precisam ser
capazes de fazer essa transição com sucesso − contudo, elas são diferentes por natureza de
outros tipos de requisitos, uma vez que elas não podem ser definidas até que a solução tenha
sido desenhada. Esses requisitos também possuem um ciclo de vida diferente dos outros
tipos de requisitos, pois eles se mantêm relevantes somente durante o período de transição
entre soluções.
Os requisitos de transição são elicitados, analisados, gerenciados e comunicados através

da realização das mesmas tarefas utilizadas para outros requisitos. A diferença não está nos
métodos para defini-los, mas nas entradas, na natureza dos requisitos de transição e no fato
de que eles deixam de ser relevantes assim que a solução existente é desativada.
Naqueles casos em que não há solução existente e a nova solução está adicionando uma
capacidade completamente nova à corporação, os requisitos de transição não precisam ser
analisados (IIBA, 2011).
Figura 2 - Diagrama de Entrada/Saída de Definir Requisitos de Transição
Entradas
7.3 3.3
Avaliação da Requisitos Solução (Em Solução

Prontidão (Declarados) Operação (Desenhada)
Organizacional
7.4
Definir Requisitos
de Transição
7.4
Requisitos de
Transição
Fonte: IIBA (2011, p. 138)
Os dados e os metadados gerenciados pelo sistema antigo precisam ser avaliados para
determinar o arquivamento da informação ou a sua transferência para a nova solução. Regras
para a conversão dessas informações deverão ser desenvolvidas e regras de negócio podem
precisar ser definidas para garantir que a nova solução interprete os dados convertidos
corretamente.
É provável que um trabalho esteja sendo feito na versão antiga da solução, no momento
em que a nova versão é implementada. Opções para o gerenciamento deste trabalho podem
incluir a finalização do trabalho existente na solução atual, iniciando o novo trabalho na nova
solução, suspendendo o processamento do novo trabalho por um período de tempo ou
convertendo todo o trabalho no momento da implementação.
A avaliação da Prontidão Organizacional é usada para identificar áreas nas quais a

organização precisa adicionar novas capacidades para gerenciar e operar a nova solução,
em seguida, usamos os requisitos declarados, quando as partes interessadas identificarão a
informação e os processos que elas precisam durante a transição. A solução em operação será

investigada para compreender o que precisa ser transferido para a nova solução. Pode ser
necessário elicitar uma descrição das capacidades da solução e desempenhar algumas tarefas
de análise, no intuito de garantir que as capacidades atuais são totalmente compreendidas. O
desenho da nova solução deve estar suficientemente definido para permitir que as maiores
diferenças sejam identificadas.
O analista de negócio pode estar envolvido no desenvolvimento de um processo para

o gerenciamento do lado humano das mudanças relacionado à solução. O gerenciamento
de mudanças organizacionais geralmente refere-se a um processo e a um conjunto de
ferramentas para o gerenciamento da mudança em um nível organizacional. O analista
de negócio pode auxiliar no desenvolvimento de recomendações de mudanças na
estrutura organizacional ou no pessoal, uma vez que as funções de trabalho podem
mudar significantemente como resultado da automação do trabalho. Novas informações
podem ser disponibilizadas para as partes interessadas e novas habilidades podem ser
necessárias para a operação da solução.
Os requisitos de transição descrevem capacidades que devem ser desenvolvidas para que
uma organização faça a transição bem-sucedida entre soluções. Os requisitos de transição
são analisados por essa tarefa e devem ainda ser verificados, validados, gerenciados e
comunicados (IIBA, 2011).
4 Validação da solução
O papel da tarefa Validação da Solução é a garantia de que a solução atende a necessidade
do negócio e determinar a resposta mais apropriada para os defeitos identificados.
A validação da solução é necessária para garantir que a solução atenderá continuadamente

as necessidades de negócios daquela organização. Os problemas que forem encontrados
nesta tarefa devem ser identificados, priorizados e corrigidos. Estes problemas podem estar
vinculados a uma necessidade de uma parte interessada que não foi atendida, ou até mesmo
que não considerada no levantamento inicial (IIBA, 2011).
As entradas para a tarefa validação da solução são a própria solução construída e os

requisitos priorizados e validados. Através destas entradas será possível realizar a avaliação
da solução e se chegar a uma conclusão sobre a solução.
Como elementos para a tarefa validação da solução, temos de acordo com IIBA (2011):

01 Investigar saídas defeituosas:

Nesta etapa, primeiramente é determinado o que é saída defeituosa para o contexto daquela solução, e
posteriormente é identificado as saídas defeituosas, que podem ser requisitos parcialmente atendidos
ou não implementados.
02 Avaliar defeitos e incidentes:
Nesta etapa, com os defeitos predeterminados, é necessário revisá-los para identificar qual o impacto
que eles têm sobre a organização e a capacidade que a organização tem para absorver estes impactos.
Quando um defeito não tem viabilidade de ser resolvido em um prazo aceitável na perspectiva do
negócio, por diversos motivos, seja pela sua complexidade, ou quando a causa não pode ser
identificada, ou até porque não possui prioridade suficiente ou qualquer outra razão e as partes
interessadas não puderem aceitar o defeito, o analista de negócio é responsável por encontrar medidas
para mitigação dos defeitos.
Figura 3 - Diagrama de Entrada/Saída Validar a Solução
Entradas
4.1
6.6
Requisitos Solução
(Priorizados e (Construída)
Validados)
7.5
Validar a Solução
7.5 7.5 7.5
Defeitos Mitigação Avaliação da

Identificados Validação Solução
Tarefas que usam esta saída Saídas usadas também

7.6 Saídas usadas
Avaliar o também por
Desempenho
da Solução +
Fonte: IIBA (2011, p. 141)

5 Avaliar o desempenho da solução

O propósito de se avaliar o desempenho da solução é verificar através das soluções em
funcionamento o valor que elas entregam para o negócio e identificar as oportunidades de
melhoria que podem ser aplicadas.
Esta tarefa ocorre no pós-implantação, ou seja, depois que a solução já está em uso, e o
objetivo é verificar se todos estão utilizando a solução na sua plenitude, e se ela está trazendo
os resultados esperados para a organização. A ideia é avaliar o efeito tanto positivo, quanto
negativo a da solução em uso.
As soluções em uso podem sofrer modificações feitas pelos usuários finais, que podem
ser: paliativos manuais, registro adicionais e adoção de procedimento e políticas não formais
para resolver problemas imprevistos ou para permitir usos inéditos para a solução. Para
que o analista de negócios avalie a solução como um todo, deve considerar estes fatores
modificados, inclusive o quando e o como foram alterados.
Como elementos para executar a tarefa, o IIBA (2011) nos sugere:
01 Compreender o valor entregue pela solução:

É necessário vincular as métricas atuais que descrevem o desempenho da solução. Ferramentas
podem apresentar automaticamente algumas ou todas as métricas definidas, mas ainda é necessário
verificar o desempenho quantitativo e qualitativo de cada uma das métricas, para verificar se tem
alguma necessidade operada abaixo da expectativa, ou pelo contrário, com recursos em excesso.
02 Validar as métricas da solução:

Em alguns casos, o desempenho de uma solução pode ser considerado excelente, com base nas
métricas de desempenho definidas para a solução, mas as metas e objetivos de negócio, aos quais
aquelas métricas deveriam estar alinhadas, não estão sendo atingidos. Um esforço de análise para
identificar e definir métricas mais apropriadas, incluindo a modificação da solução para coletar e
reportar essas métricas pode ser necessário.

Figura 4 - Diagrama da Tarefa Avaliar o Desempenho da Solução
Entradas
* 7.5
Requisitos de Defeitos Solução Métricas de

Negócios Identificados (Em operação) Desempenho da
Solução
7.6
Avaliar o
Desempenho
da Solução
7.6
Avaliação do Desempenho
da Solução

5.2
Avaliar Gaps
(Lacunas)
de Capacidades
Fonte: IIBA (2011, p. 143)
Nesta aula, tivemos a oportunidade de conhecer as tarefas que o BABOK® apresenta para
permitir que o analista de negócios saiba se a solução aplicada é a que atende as expectativas
da organização.
As tarefas são criteriosas e permitem conhecer a real situação das soluções implantadas.
São critérios técnicos de avaliação, não apenas sentimentos das partes interessadas.
Neste ponto é importante salientar que é essencial para a continuidade de um bom

trabalho de análise de negócios, pois somente com a avaliação bem feita do trabalho é
possível caminhar rumo à melhoria contínua dos processos de negócio da organização.

Referências
2.0. Toronto: theiiba.org, 2011.

GESTÃO DA QUALIDADE
NO DESENVOLVIMENTO
DE SOFTWARE
Dados Internacionais de Catalogação na Publicação (CIP)
(Jeane Passos de Souza - CBR 8a/6189)
Halat, Angela
Modelos de gestão no varejo / Angela Halat. – São Paulo : Editora
Senac São Paulo, 2016. (Série Universitária)
Bibliografia.
e-ISBN 978-85-396-1065-5
1. Administração – vendas 2. Comércio varejista : Gestão de vendas

I. Título.
16-385s CDD-658.81
658.87
BISAC BUS0580010
Índice para catálogo sistemático

1. Administração de vendas 658.81
GESTÃO DA QUALIDADE
NO DESENVOLVIMENTO
DE SOFTWARE
Mauro de Mesquita Spinola e

Marcelo Schneck de Paula Pessôa
Administração Regional do Senac no Estado de São Paulo
Presidente do Conselho Regional
Abram Szajman
Diretor do Departamento Regional

Luiz Francisco de A. Salgado
Superintendente Universitário e de Desenvolvimento

Luiz Carlos Dourado
Editora Senac São Paulo

Conselho Editorial
Luiz Carlos Dourado
Darcio Sayad Maia
Lucila Mara Sbrana Sciotti
Jeane Passos de Souza
Gerente/Publisher
Jeane Passos de Souza (jpassos@sp.senac.br)
Coordenação Editorial
Márcia Cavalheiro Rodrigues de Almeida (mcavalhe@sp.senac.br)
Comercial
Marcelo Nogueira da Silva (marcelo.msilva@sp.senac.br)
Administrativo
Luís Américo Tousi Botelho (luis.tbotelho@sp.senac.br)
Acompanhamento Pedagógico
Nome
Designer Educacional
Jussara Cristina Cubbo
Revisão Técnica
Nome
Colaboração
Nome
Revisão de Texto
Nome
Projeto Gráfico
Alexandre Lemes da Silva
Emília Correa Abreu
Capa Proibida a reprodução sem autorização expressa.
Antonio Carlos De Angelis Todos os direitos desta edição reservados à
Editoração Eletrônica Editora Senac São Paulo
Michel Iuiti Navarro Moreno
Rua 24 de Maio, 208 – 3o andar
Ilustrações Centro – CEP 01041-000 – São Paulo – SP
Michel Iuiti Navarro Moreno Caixa Postal 1120 – CEP 01032-970 – São Paulo – SP
Tel. (11) 2187-4450 – Fax (11) 2187-4486
Imagens
E-mail: editora@sp.senac.br
iStock Photos
Home page: http://www.editorasenacsp.com.br
E-pub
Ricardo Diana © Editora Senac São Paulo, 2016
Sumário
Capítulo 1 Capítulo 4
Nome do capítulo, 1 Nome do capítulo, 4
1 Nome do título, 1 1 Nome do título, 4
2 ome do título, 1 2 ome do título, 4
Considerações finais, 1 Considerações finais, 4
Referências bibliográficas, 1 Referências bibliográficas, 4
Capítulo 1
Introdução aos
processos de
software
Este livro apresenta os conceitos fundamentais de qualidade no de-

senvolvimento de software.
O objetivo desta primeira aula é apresentar o tema qualidade de sof-

tware, bem como os elementos essenciais da disciplina, que serão de-
senvolvidos nos próximos capítulos.
Ao final desta aula, o aluno terá obtido os seguintes conhecimentos:
•• Conceito de qualidade de software.
•• Relevância do tema.
•• Fundamentos de processo de software, seus padrões e modelos

mais comuns.
7
O conhecimento e a prática voltados para a produção de software
de alta qualidade progrediram significativamente nas últimas décadas.
Estudos têm sido realizados nos mais importantes centros de pesquisa
do mundo (MAZHELIS; TYRVÄINEN; FRANK, 2013; MEYER; LEHNERD,
1997), e empresas e instituições têm aplicado esses conhecimentos na
prática e publicado as suas experiências. Modelos e normas têm sido
desenvolvidos, com destaque para a constelação CMMI (desenvolvida e
mantida pelo SEI – Software Engineering Institute) (CMMI, 2002) e para
a família de normas da ISO (mantidas pela International Organization for
Standardization, em parceria com a IEC – International Electrotechnical
Commission) (ISO, 2016).
1 Sistemas, software e processos

Entende-se por sistema uma coleção de componentes organizados
para atender a uma função ou conjunto de funções específico (IEEE,
1990). Sistema pode ser compreendido como uma coleção significativa
de componentes inter-relacionados, que trabalham em conjunto para
atingir algum objetivo (SOMMERVILLE, 2011). Os sistemas possuem,
eventualmente, um software como um de seus componentes.
Software, por sua vez, compreende três elementos essenciais

(PRESSMAN, 2002):
1. Instruções (programas de computadores) que quando executadas

fornecem as características, função e desempenho desejados.
2. Estruturas de dados que permitem aos programas manipular

adequadamente a informação.
3. Documentos que descrevem a operação e o uso do programa.
Quando entregamos a um cliente um pacote bem delimitado e identi-

ficado, podemos dizer que entregamos um produto. A definição da nor-
ma IEEE-STD-610 (IEEE, 1990) para produto de software é que se trata
8 Gestão da qualidade no desenvolvimento de software

de um conjunto completo, ou item individual do conjunto, de softwares,
procedimentos, documentação associada e dados específicos para a
liberação a um cliente ou usuário final (PAULK et al., 1995).
Durante o desenvolvimento produzimos códigos, documentos e

ferramentas que podem ou não ser inseridos no produto entregue ao
cliente. Por isso, o SEI diferencia produto de software de produto de
trabalho de software (ou produto de desenvolvimento de software), um
conceito mais amplo que engloba os produtos de software e também
todos os resultados de projetos. Segundo Paulk e colaboradores (1995),
o produto de trabalho de software pode englobar a descrição de pro-
cesso, os programas de computador, os planos, os procedimentos e
a documentação associada. Tudo isso pode ser destinado à liberação
para um cliente ou usuário final.
Todo produto de trabalho de software para ser gerado necessita de

um processo de software. O conceito de processo de software se ba-
seia na definição generalizada de processo, que pode ser definido como
uma sequência de estados de um sistema que se transforma.
O SEI da Carnegie Mellon University, nos Estados Unidos, propõe que

um processo é um conjunto de etapas realizadas tendo como meta um
dado propósito. Assim, processo é aquilo que se faz por meio de proce-
dimentos, ferramentas, equipamentos e métodos para transformar uma
matéria-prima (entrada) em produto (saída). Esta saída deve ter valor
para o cliente (PAULK et al., 1995).
O processo de software (PAULK et al., 1995; PESSÔA; SPINOLA,

1996), em particular, trata-se de um conjunto de atividades, transfor-
mações, métodos e práticas aplicadas ao desenvolvimento e manu-
tenção de software, produtos associados, códigos, casos de teste e
manual do usuário.
A figura 1 a seguir identifica os três componentes de qualquer proces-

so: as pessoas, as ferramentas e os procedimentos (PAULK et al., 1995).
Introdução aos processos de software 9

Figura 1 – Processo e seus componentes
Procedimentos e
B
métodos que definem a
relação entre as tarefas
A D
C
Processo
Ferramentas e
Pessoas habilitadas equipamentos
treinadas, motivadas
Fonte: adaptado de Paulk et al. (1995).
Dunn e Ullman (1994) identificam os seguintes passos no processo

de desenvolvimento de software:
•• Análise do papel a ser desempenhado pelo programa (concepção).
•• Desenvolvimento da solução.
•• Avaliação do programa em relação ao papel concebido no primei-

ro passo.
•• Documentação suficiente para as necessidades dos usuários e

para manutenção durante o ciclo de vida.
2 Ciclo de vida de sistemas e software: a

norma ISO/IEC 12207
Alguns modelos e normas estabelecem bases para a definição e a
melhoria dos processos de sistemas e software.
A Norma Internacional ISO/IEC 12207-2008 (ABNT, 2009) estabele-

ce uma estrutura comum para processos de ciclo de vida de sistemas
e software. Ela é aplicada para a aquisição de produtos de sistemas,

software e serviços; para o fornecimento, desenvolvimento, operação,
manutenção e desativação de produtos de software; e para a porção de
software de um sistema, seja desenvolvido interna ou externamente à
organização.
Os processos propostos pela Norma ISO/IEC 12207-2008 estão

classificados nas seguintes categorias:
Tabela 1 – Processos propostos pela Norma ISO/IEC 12207-2008
CONTRATUAIS com 2 processos
ORGANIZACIONAIS CAPACITADORES DE PROJETO com 5 processos
DE PROJETO com 7 processos
TÉCNICOS com 7 processos
DE IMPLEMENTAÇÃO DE SOFTWARE com 7 processos
DE APOIO A SOFTWARE com 8 processos
DE REUSO DE SOFTWARE com 3 processos
Fonte: adaptado de ABNT (2009).
A Norma ISO/IEC 12207 está estruturada em dois grandes grupos

de processos: os processos contextuais de sistema e os processos es-
pecíficos de software. Os processos contextuais de sistema fornecem
subsídios para lidar com um produto de software ou serviço ou com um
sistema de software independente. Este grupo de processos é dividido
em outros quatros subgrupos: processos contratuais, processos orga-
nizacionais capacitadores de projeto, processos de projeto e processos
técnicos (ABNT, 2009).
O grupo de processos específicos de software é utilizado na im-

plementação de um produto ou serviço de software como elemento de
um sistema maior. Ele está dividido em três subgrupos: processos de

implementação de software, processos de apoio ao software e proces-
sos de reuso de software (ABNT, 2009).
Figura 2 – Grupos de processos da Norma ISO/IEC 12207
Processos contextuais Processos específicos

de sistema de software
De implementação
Contratuais
de software
Organizacionais
capacitadores De apoio ao software
de projeto
De projeto De reuso de software
Técnicos
A seguir, detalharemos cada processo apresentado pela Norma ISO/

IEC 12207 (ABNT, 2009).
2.1 Processos contextuais de sistema
Contratuais:
•• Processo de aquisição: obter um produto e/ou serviço que satis-

faça à necessidade expressa pelo adquirente.
•• Processo de fornecimento: fornecer um produto e/ou serviço ao

adquirente que satisfaça aos requisitos combinados.
Organizacionais capacitadores de projeto:

•• Processo de gestão de modelo de ciclo de vida: definir, manter e
garantir a disponibilidade das políticas, dos processos de ciclo de
vida, dos modelos de ciclo de vida e dos procedimentos de uso
da organização.
•• Processo de gestão de infraestrutura: fornecer infraestrutura e

serviços a projetos de modo a apoiar os objetivos do projeto e da
organização.
•• Processo de gestão de portfólio de projetos: iniciar e sustentar

projetos adequados, suficientes e necessários a fim de satisfazer
aos objetivos estratégicos da organização.
•• Processo de gestão de recursos humanos: fornecer à organiza-

ção recursos humanos necessários para a execução dos projetos.
•• Processo de gestão da qualidade: garantir que os produtos, os

serviços e a implementação dos processos de ciclo de vida alcan-
cem os objetivos de qualidade definidos pela organização e que
gere satisfação ao cliente.
De projeto:
•• Processo de planejamento de projeto: produzir e comunicar pla-

nos de projetos viáveis e eficazes.
•• Processo de controle e avaliação de projeto: determinar o sta-

tus do projeto e garantir que ele seja realizado de acordo com os
planos e cronogramas, dentro do orçamento, e que atenda aos
objetivos estipulados.
•• Processo de tomada de decisão: selecionar o curso de ação

mais benéfico para o projeto dentre as alternativas existentes.
•• Processo de gestão de risco: identificar, analisar, tratar e monito-

rar os riscos do projeto de forma contínua.

•• Processo de gestão de configuração: estabelecer e manter a in-
tegridade de todos os produtos identificados de um projeto ou
processo, e torná-los disponíveis às partes interessadas.
•• Processo de gestão da informação: fornecer informações rele-

vantes, completas, válidas e confidenciais (quando for o caso).
•• Processo de gestão de medição: coletar, analisar e relatar da-

dos relacionados aos produtos desenvolvidos e processos
implementados.
Técnicos:
•• Processo de definição dos requisitos dos stakeholders: definir

os requisitos de um sistema.
•• Processo de análise dos requisitos do sistema: transformar os re-

quisitos dos stakeholders em um conjunto de requisitos técnicos.
•• Processo de projeto de arquitetura de sistema: identificar quais

requisitos do sistema serão alocados para cada elemento do
sistema.
•• Processo de implementação: realizar um elemento do sistema.
•• Processo de integração de sistema: integrar os elementos do

sistema.
•• Processo de teste de qualificação de sistema: garantir que a

implementação de cada requisito do sistema seja testada para
verificação de conformidade.
•• Processo de instalação de software: instalar o produto de

software.
•• Processo de suporte de aceitação de software: auxiliar o adqui-

rente a ter confiança de que o produto satisfaz aos requisitos.
•• Processo de operação de software: operar o produto de software

no seu ambiente e fornecer suporte aos clientes deste produto.

•• Processo de manutenção de software: realizar manutenção de
software.
•• Processo de desativação de software: concluir a existência de

uma entidade de software de sistema.
2.2 Processos específicos de software
De implementação de software:
•• Implementação de software: produzir um item de sistema espe-

cificado como um produto ou serviço de software.
•• Análise de requisitos de software: estabelecer os requisitos dos

elementos de software do sistema.
•• Arquitetura de software: fornecer um projeto para o software que

implemente e possa ser verificado com base em seus requisitos.
•• Processo de projeto de software: fornecer um projeto para o

software que implemente e possa ser verificado com base e
seus requisitos.
•• Construção de software: produzir unidades de software executá-

veis que refletem apropriadamente o projeto de software.
•• Integração de software: combinar as unidades de software e

componentes de software, produzindo itens de software inte-
grados, consistentes com o projeto de software, que demons-
trem que os requisitos funcionais e não funcionais de software
são satisfeitos.
•• Processo de teste de qualificação de software: confirmar que

o produto de software integrado atende aos requisitos definidos.
De apoio ao software:

•• Processo de gestão de documentação de software: desenvolver
e manter o registro das informações do software produzidas por
um processo.
•• Processo de gestão de configuração de software: estabelecer

e manter a integridade dos itens de software de um processo, e
disponibilizá-los para as partes envolvidas.
•• Processo de garantia de qualidade de software: fornecer garan-

tia de que os produtos e processos de trabalho estão em confor-
midade com os planos e as condições pré-definidos.
•• Processo de verificação de software: confirmar que cada produ-

to de trabalho e/ou serviço de software de um processo ou proje-
to reflete apropriadamente os requisitos especificados.
•• Processo de validação de software: confirmar se os requisitos

de um uso específico pretendido para o produto de software são
atendidos.
•• Processo de revisão de software: manter um entendimento co-

mum com os stakeholders a respeito do progresso obtido em re-
lação aos objetivos acordados.
•• Processo de auditoria de software: determinar a conformidade

dos produtos e processos selecionados com os requisitos, pla-
nos e contratos.
•• Processo de resolução de problema de software: assegurar que

todos os problemas sejam identificados, analisados, gerenciados
e controlados até sua resolução.
De reuso de software:
•• Processo de engenharia de domínio: desenvolver e manter mo-

delos, arquiteturas e ativos deste domínio.
•• Processos de gestão de reuso de ativos: gerenciar a vida dos

ativos (reusáveis) desde a concepção até a desativação.

•• Processo de gestão de programa de reuso: planejar, estabelecer,
controlar e monitorar os programas de reuso.
3 Modelos de processos de software

Um modelo de processo pode ser entendido como uma represen-
tação abstrata de um processo. Os modelos de processo de software
são próprios de cada organização ou mesmo de cada grupo de desen-
volvimento de software, mas em geral se baseiam em alguns modelos
genéricos. Alguns desses modelos de referência são:
•• Cascata: é considerado o modelo clássico de engenharia de

software. Compõe-se por fases sequenciais, sendo que as mais
típicas são análise de requisitos, projeto (design), implemen-
tação, testes, integração e operação/manutenção de software
(MUNASSAR; GOVARDHAN, 2010).
Figura 3 – Modelo cascata
Definição
de requisitos
Projeto de
sistema e software
Implementação e
teste de sistema
Integração e teste
de sistema
Operação e
manutenção
Fonte: adaptado de Sommerville (2011).

•• Desenvolvimento iterativo: visando obter resultados mais rápi-
dos do que os obtidos no modelo cascata, o desenvolvimento
iterativo promove a divisão do projeto em pequenas partes, pos-
sibilitando à equipe de desenvolvimento apresentar resultados
prévios. Cada iteração é geralmente um miniprocesso cascata.
Figura 4 – Desenvolvimento iterativo
de software
1
Interações de desenvolvimento de software
TAF
Teste de sistema TAF
TAS TAS
Demonstrações Releases de fases
Arquitetura TAF Teste de aceitação de fábrica

Desenvolvimento de unidade TAS Teste de aceitação de site
Integração
Fonte: adaptado de Munassar e Govardhan (2010).
•• V: modelo sequencial, como a cascata, mas com ênfase em tes-

tes (geralmente desenhado na forma da letra V); os procedimen-
tos de testes são definidos antes da codificação.
•• Espiral: similar ao incremental, este modelo enfatiza a análise de

riscos. Repetidamente, em várias iterações (espirais), o projeto
passa por quatro fases: planejamento, análise de risco, engenha-
ria e avaliação.

Figura 5 – Modelo espiral
Determinar objetivos, Avaliar alternativas,

alternativas e restrições identificar, resolver riscos
Análise
de risco
Análise
de risco
Análise
Protótipo
de risco de
Protótipo operação
Protótipo 3
Análise 2
de risco Protótipo
Revisão 1
Plano de requisitos Simulação, modelos, benchmarks
Plano de ciclo de vida Conceito de
operação Requisitos
de SW Projeto do
produto Projeto
detalhado
Plano de Validação de
requisitos Código
desenvolvimento
Teste de
Integração e V&V do unidade
plano de teste projeto Teste de
Teste de integração
Planejar próxima fase Operação aceitação Desenvolver, verificar
produto de próximo nível
Fonte: adaptado de Sommerville (2011).
•• Ágil: com base no desenvolvimento e na liberação de vários incre-

mentos de funcionalidade. A abordagem é de melhoria contínua
do código e de envolvimento do usuário na equipe e programação
aos pares. Um exemplo de modelo ágil é o extreme programming
(XP), cujo ciclo de vida é apresentado a seguir.
Figura 6 – Ciclo de vida XP
Selecione user stories Desdobre stories

Planeje o release
para este release em tarefas
Desenvolva / integre /
Avalie o sistema Libere o software
teste o software
Fonte: adaptado de Munassar e Govardhan (2010).

A Norma Internacional ISO/IEC 12207-2008 (ABNT, 2009) exige, para
sua efetiva aplicação, adaptação de suas práticas às necessidades e
características de cada organização. Pode-se afirmar que não existem
duas aplicações iguais desses processos, porque todas as organiza-
ções possuem peculiaridades referentes à organização, assim como
aos clientes, desenvolvedores e fornecedores.
4 Qualidade de software
Roger Pressman (2002) define qualidade de software como sendo
uma conformidade a requisitos funcionais e de desempenho declara-
dos de forma explícita, a padrões de desenvolvimento documentados
claramente e a características implícitas que são esperadas de todo
software definido profissionalmente.
Esta definição tem o mérito de considerar, além dos requisitos ex-

plícitos, a adequação aos requisitos implícitos comumente presentes.
No entanto, está longe de representar um conceito geral de qualidade
de software.
A exemplo do que ocorre há anos na manufatura, a gerência de pro-

cesso de software e a busca da sua melhoria contínua apresentam-se
como práticas necessárias para um melhor desempenho econômico
das empresas. Exemplos relatados na literatura, como o da Raytheon
(DION, 1993) e o da Federal Systems Company (uma divisão da Loral
Corporation que desenvolve o projeto Space Shuttle Onboard Software)
(BILLINGS et al., 1994), dentre outros, mostram que resultados efetivos
podem ser obtidos como resultado direto do investimento em melhoria
de processo de software.
A gerência do processo visa estabelecer uma infraestrutura para su-

portar e guiar os trabalhos dos diversos projetos de maneira uniforme
(HUMPHREY, 1989). A gerência inclui:

•• Definição do processo: estabelecer um padrão para implementa-
ção, avaliação e melhoria de cada tarefa.
•• Execução do processo: definir os métodos e técnicas usados

para produzir produtos com qualidade.
•• Coleta de dados e análise: tratar as medições realizadas pelos

produtos e processos de software, e o uso desses dados.
•• Controle do processo: estabelecer mecanismos para certificar o

desempenho do processo definido; monitorar e ajustar o proces-
so no qual melhorias forem necessárias.
David Card (1991), da Computer Science Corporation (CSC) e do SEI,

apresenta dois tratamentos básicos para a melhoria de processo de
software:
•• Tratamento analítico, que utiliza evidências quantitativas para de-

terminar onde as melhorias são necessárias e se uma iniciativa
de melhoria teve sucesso (exemplo: ciclo PDCA).
•• Benchmarking, que se baseia na identificação de uma organiza-

ção considerada excelente em determinado campo – de acordo
com alguns parâmetros –, e na documentação de suas práticas
e ferramentas (exemplo: a adoção do SW-CMM ou de qualquer
outro modelo de sistema ou de processo).
Estudos e trabalhos realizados pelo Software Engineering Laboratory

(SEL) – um esforço cooperativo da Nasa, por meio da Divisão de
Dinâmica de Voo (Flight Dynamics Division – FDD) em parceria com o
Departamento de Ciência da Computação da Universidade de Maryland,
nos Estados Unidos – demonstraram a importância da gerência do pro-
cesso para a obtenção de padrões cada vez mais elevados de qualidade.
Vitor Basili e colaboradores (1995) informam que o SEL investiu, duran-
te as duas últimas décadas, aproximadamente 11% de seu orçamento
na melhoria do processo. Os principais resultados obtidos na definição

dos processos do SEL foram (BASILI et al., 1995):
•• A institucionalização da mudança e da melhoria do processo

como práticas de negócio padrões.
•• O uso intensivo de medições: elas são esperadas, aplicadas e efe-

tivas, tendo se tornado uma maneira de fazer negócio.
•• O direcionamento das mudanças para processo e produto.
•• Mudança bottom-up, baseada, em grande medida, na experiência

do pessoal em desenvolvimento de projetos.
•• Maior ênfase a tecnologias orientadas mais a pessoas (people-o-

riented – revisões, inspeções, técnicas de sala limpa, etc.) do que
a automações.
O processo cleanroom recebeu no SEL um tratamento fundamenta-

do na experiência adquirida em seus projetos e tem como uma de suas
bases a ênfase em técnicas de leitura. O processo foi definido com qua-
tro elementos (BASILI; GREEN, 1994):
•• Separação entre as equipes de desenvolvimento e testes.
•• Dependência maior de revisões dos pares (peer reviews) do que

de testes de unidades como primeira técnica de verificação do
desenvolvedor (BASILI; GREEN, 1994).
•• Uso de máquinas de estado e funções informais para definir o

projeto do sistema.
•• Um tratamento estatístico para testes com base em cenários

operacionais.
Chama a atenção, entre as conclusões do SEL, a crescente consi-

deração do fator humano na melhoria dos processos, contrariando a
expectativa de tornar os processos independentes das pessoas, uma vi-
são necessária para a definição clara de procedimentos e ferramentas,

mas que se mostra limitada diante da constatação de que um processo
definido necessita ainda mais fortemente de pessoas preparadas para
implementá-lo.
Há estudos que criticam o modelo cleanroom: consideram que esta

prática é subdesenvolvida e minoritária (BELZER, 1997). A crítica de
Belzer focaliza os limites do modelo sob o ponto de vista de resultados,
mas não considera que os seus princípios sejam incorretos.
Perry, Staudenmayer e Votta (1994) também estudaram de forma

objetiva e quantitativa o papel das pessoas no processo de desenvolvi-
mento de software e chegaram a diversas conclusões sobre os fatores
humanos que afetam a produtividade, entre eles:
•• O trabalho é realizado, em média, em intervalos de duas horas.
•• Eventos não planejados e transitórios ocupam boa parte do tem-

po dos desenvolvedores (interações interpessoais, por exemplo,
despenderam em média 75 minutos por dia).
•• A comunicação por meio de e-mail mostrou-se pouco utilizada,

sobretudo se comparada com as comunicações diretas entre as
pessoas.
DeMarco e Lister (1990) avançam neste tema e propõem a qualida-

de do local de trabalho (organização do espaço, nível de barulho, etc.)
como instrumento para a qualidade do processo de desenvolvimento.
Já Humphrey (1995) propõe o personal software process (PSP – proces-
so de software pessoal), um modelo de processo focalizado no trabalho
do profissional de desenvolvimento de software.
Há pontos de vista diferentes sobre a melhor estratégia para me-

lhoria de processo: top-down ou bottom-up. A abordagem top-down se
baseia na comparação entre o processo de uma organização e um
processo padrão reconhecido. A melhoria se faz, nessa abordagem,
pela eliminação das diferenças entre esses processos. A abordagem

bottom-up, por outro lado, realiza mudanças a partir de um conjunto de
metas, características, características de produto e experiências locais,
do domínio da organização. Thomas (1994) defende a técnica top-down
e argumenta que o processo tem que ser fruto das necessidades iden-
tificadas. Segundo ele, o desenvolvimento de processo é como uma
construção de um artefato complexo criado para um propósito útil. Ao
se criar um software para negócios ou indústria é preciso considerar
muitos detalhes e requisitos específicos que devem ser implementados
precisamente e com grande atenção. Além disso, requisitos serão de-
senvolvidos, e o software deverá ser compatível com essas mudanças
sem perder a sua integridade.
Realmente, um risco potencial existente na melhoria por processo é

o de construir um processo voltado a si próprio, que sistematicamen-
te passa a desconsiderar as diversas mudanças externas ao ambiente
de desenvolvimento (sobretudo as novas necessidades dos clientes)
e a própria visão do cliente sobre os produtos em desenvolvimento
(CURTIS, 1993).
McGarry (1994), ao analisar as visões top-down e bottom-up, conside-

ra que toda organização deve inicialmente compreender completamen-
te seu processo, produtos, características de software e metas antes de
selecionar um conjunto de mudanças que signifiquem melhorias para
seu processo.
Cada uma dessas visões contribui para a compreensão dos cami-

nhos efetivos que as organizações podem utilizar para a melhoria de
seus processos. O tratamento objetivo da melhoria de processo de
software, por meio de medições – e métricas apropriadas –, é a mais
efetiva ferramenta para a gerência desse processo (SPINOLA; PESSÔA,
1996). Os processos de planejamento e acompanhamento de projetos,
por exemplo, ganham maior consistência quando baseados em estima-
tivas e avaliações de risco objetivas (BOEHM; DEMARCO, 1997; PAULK
et al., 1995).

A qualidade de software advém, sobretudo, da qualidade de proces-
so de software. Uma organização de software obtém reconhecimento a
partir de seus produtos sistematicamente produzidos com alta qualida-
de. Essa constância exige processos maduros, que garantem a qualida-
de dos vários produtos.
As aulas seguintes desenvolverão maiores detalhes sobre os aspec-

tos de processo e de modelagem que permitem obter um software de
alta qualidade.
Referências
ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/
IEC 12207:2009 – Engenharia de sistemas e software: processos de ciclo de
vida de software. Rio de Janeiro, 2009.
BASILI, V.; GREEN, S. Software process evolution at the SEL. IEEE Software, p.
58-66, jul. 1994.
BASILI, V. et al. SEL’s software process-improvement program. IEEE Software, v.

12, n. 6, p. 83-87, nov. 1995.
BELZER, B. A cleanroom process model: a critical examination. IEEE Software,

p. 14-16, mar. 1997.
BILLINGS, C. et al. Journey to a mature software process. IBM Systems Journal,

v. 33, n. 1, p. 46-61, 1994.
BOEHM, B. W.; DEMARCO, T. Software risk management. IEEE Software, maio

1997.
CARD, D. Understanding process improvement. IEEE Software, v. 8, n. 4, p. 102-

103, jul. 1991.
CMMI PRODUCT TEAM. Capability maturity model integration (CMMI): CMMI

for systems engineering, software engineering, integrated product and process

development, and supplier sourcing. Pittsburgh: Software Engineering Institute,
2002. Disponível em: <http://www.sei.cmu.edu/publications/documents/02.re-
ports/02tr011.html>. Acesso em: 2 fev. 2017.
CURTIS, B. Maturity from the user’s point of view. IEEE Software, v. 10, n. 4, p.
89-90, jul. 1993.
DEMARCO, T.; LISTER, T. Peopleware: como gerenciar equipes e projetos tor-

nando-os mais produtivos. Tradução K. A. Roque. São Paulo: Makron Books,
1990.
DION, R. Process improvement and the corporate balance sheet. IEEE Software,
v. 10, n. 4, p. 28-35, jul. 1993.
DUNN, R. H.; ULLMAN, R. S. TQM for computer software. 2. ed. New York:
McGraw-Hill, 1994. (McGraw-Hill System Design and Implementation Series).
HUMPHREY, W. S. Managing the software process. Salt Lake City: Addison-

Wesley, 1989. (SEI Series in Software Engineering).
HUMPHREY, W. S. A discipline for software engineering. Salt Lake City:

Addison-Wesley, 1995. (SEI Series in Software Engineering).
IEEE – INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. IEEE

Standard Glossary of Software Engineering Terminology, IEEE std 610.12-
1990. New York: IEEE, 1990.
ISO – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO

Standards, 2016. Disponível em: <http://www.iso.org/iso/home/standards.
htm>. Acesso em: 1 jun. 2016.
MAZHELIS, O.; TYRVÄINEN, P.; FRANK, L. Vertical software industry evolution:

the impact of software costs and limited customer base. Information and
Software Technology, v. 55, n. 4, p. 690-698, abr. 2013.
MCGARRY, F. Process improvement is a bottom-up task. IEEE Software, v. 11,

n. 4, p. 13, jul. 1994.
MEYER, M. H.; LEHNERD, A. P. The power of product platforms: building value

and cost leadership. New York: The Free Press, 1997. 267 p.

MUNASSAR, Nabil Mohammed Ali; GOVARDHAN, A. A comparison between
five models of oftware engineering. IJCSI International Journal of Computer
Science Issues, vol. 7, n. 5, set. 2010.
PAULK, M. C.; WEBER, C. V.; CURTIS, B.; CHRISSIS, M. B. The capability maturity
model: guidelines for improving the software process/CMU/SEI. Salt Lake City:
PERRY, D. E.; STAUDENMAYER, N. A.; VOTTA, L. G. People, organizations, and

process improvement. IEEE Software, v. 11, n. 4, p. 36-45, jul. 1994.
PESSÔA, Marcelo Schneck de Paula; SPINOLA, Mauro de Mesquita. Processo

de software: o que é isso? Boletim Fundação Vanzolini, ano IV, n. 24, p. 17, jul./
ago. 1996.
PRESSMAN, Roger. Engenharia de software. São Paulo: Makron, 2002.
SOMMERVILLE, Ian. Engenharia de software. Tradução Kalinka Oliveira e Ivan

Bosnic. 9. ed. São Paulo: Prentice Hall, 2011.
SPINOLA, M. M.; PESSÔA, M. S. P. Métricas de software: a busca da objetivida-

de. Boletim Fundação Vanzolini, ano IV, n. 23, jun./jul. 1996.
THOMAS, M. Process improvement is a top-down task. IEEE Software, v. 11, n.

4, p. 12, jul. 1994.

Capítulo 2
Engenharia de
requisitos
Este capítulo tem por objetivo discutir o tema requisitos de software

e apresentar a análise de negócios e a engenharia de requisitos – áreas
que tratam desse tema.
•• Conceito de requisitos.
•• Processo de requisitos de software.
•• Algumas técnicas para levantamento de requisitos.
1
1 Os requisitos no ciclo de desenvolvimento
de software
Uma das etapas do processo do ciclo de vida de software é a elabo-
ração dos requisitos. Esta talvez seja, hoje, uma das etapas mais impor-
tantes, pois refere-se à definição de o que o software fará.
Como base para este estudo são utilizadas neste capítulo duas refe-
rências conceituais muito importantes para que se possam desenvolver
os requisitos de forma adequada: a análise de negócios (IIBA, 2015) e a
engenharia de requisitos (HULL, 2011).
2 Conceitos fundamentais
Neste item serão apresentados alguns conceitos fundamentais refe-
rentes ao desenvolvimento de software: requisito, stakeholder e domínio
do problema e da solução.
2.1 Requisito
Um software sempre faz parte de um sistema maior. Por isso, é ne-

cessário conhecer como o sistema funciona e compreender a operação
à qual o software vai atender para retirar as necessidades de informa-
ção e, portanto, os requisitos de software.
Mas o que é um requisito? Um requisito é uma característica do sis-

tema ou a descrição de algo que o software é capaz de realizar para
atingir seus objetivos. Os requisitos são definidos no início do desenvol-
vimento de um sistema como uma especificação do que deve ou não
deve ser implementado (SOMMERVILLE, 2003).
Dessa forma, o escopo do software é definido por meio de uma cole-

ção de requisitos que devem ser atendidos.

A figura 1 a seguir mostra o esforço dedicado à atividade de requisi-
tos: no início do projeto há uma intensa atividade de levantamento de re-
quisitos cujo resultado é um documento (a ser detalhado mais à frente)
denominado especificação de requisitos. O gerenciamento de requisitos
é um processo intenso em determinados momentos e que se mantém
hibernado em outros. Quando há alterações de requisitos esta atividade
volta à tona e é executada.
Figura 1 – Esforço dedicado à atividade de requisitos

Esforço dedicado à atividade de requisitos
Etapas do ciclo de vida de software
2.2 Stakeholder
O que é stakeholder? O termo do anglicismo se refere a um projeto de

sistema que contém diversas pessoas, diversos stekeholders, que têm al-
gum tipo de interesse, algum relacionamento com o software (IIBA, 2015).
No momento de desenvolver um projeto de software, devem ser le-

vantados os requisitos dos stakeholders, pois o software deve atender
às necessidades de todos eles. Muito comum é desenvolver uma apli-
cação em que são levantadas apenas as funcionalidades do software
Engenharia de requisitos 3
sem se preocupar com essa visão mais abrangente, mais sistêmica,
procurando observar o software integrado dentro de seu ambiente real
de funcionamento (IIBA, 2015).
2.3 Domínio do problema e da solução
Um último conceito importante é o domínio do problema e da so-

lução. Domínio do problema é o domínio no qual o sistema será utili-
zado. É importante conhecer os requisitos por meio de um ponto de
vista operacional. Com o desafio de levantar requisitos, há que se fazer
a seguinte pergunta para os potenciais usuários: “O que você quer que
o sistema faça?”. Alguns usuários têm pouca ou nenhuma ideia da res-
posta. Aqueles que já possuem um sistema existente são capazes de
indicar melhorias, mas, se não existe nada, essa fonte de inspiração não
está disponível (HULL, 2011).
Domínio da solução, por sua vez, se refere ao conhecimento utilizado

pelos engenheiros para resolver determinado problema. A primeira dife-
rença em relação ao domínio do problema é que, invariavelmente, no do-
mínio da solução a engenharia de requisitos começa com um conjunto
de requisitos. No domínio do problema o trabalho se inicia com um vago
objetivo ou uma lista de desejos (HULL, 2011).
A passagem do domínio do problema para o domínio da solução é

uma dificuldade, pois geralmente são utilizadas linguagens e terminolo-
gias diferentes em cada etapa, e nem sempre o profissional responsável
por identificar os requisitos está atento a isso. Pressman (1992, p. 54)
cita uma frase que ilustra esse problema: “Eu sei que você acredita que
você entendeu o que você acha que eu disse, mas eu não tenho certeza
que você percebeu que o que você ouviu não é o que eu quis dizer”.
Assim, a transição de um domínio para o outro trata-se de um proble-

ma de comunicação entre dois profissionais de áreas diferentes, e um
descuido pode levar a problemas e a uma compreensão errada do que

deve ser feito. A redação dos requisitos de forma clara e o retorno aos
stakeholders para eles confirmarem o que vai ser feito são ações muito
importantes. Portanto, todo cuidado é pouco.
3 Análise de negócios
Conforme já explicitado, todo software faz parte de um sistema
maior. Esse sistema maior tem alguma finalidade e deve atender algu-
ma necessidade de negócio da organização.
Por exemplo, um sistema de controle de estoque pertence a um sis-

tema maior, provavelmente a área de almoxarifado de uma organização.
O almoxarifado, por sua vez, pertence a um sistema maior como uma
manufatura que compra matérias-primas para executar a produção e
as armazena no sistema de estoque. Portanto, é necessário entender
quais as necessidades de informação das pessoas que trabalham com
essa movimentação de materiais para que seja construído o software
de mateira adequada.
A análise de negócios é o conjunto de atividades e técnicas utilizadas

para servir de ligação entre os stakeholders com o objetivo de compre-
ender a estrutura, as políticas e as operações de uma organização para
recomendar soluções que podem entregar valor. A análise de negócios
é a prática para habilitar mudanças em uma empresa (IIBA, 2015).
A compreensão do contexto é o principal objetivo da análise de ne-

gócios, a qual foi desenvolvida por um grupo de especialistas que criou
um modelo denominado BABOK (Business analysis body of knowledge),
que estabelece uma série de tarefas e técnicas para o desenvolvimento
dessa atividade.
Figura 2 – Áreas de conhecimento do BABOK
Planejamento e
monitoramento da
análise de negócios
Análise estratégica e definição de
projetos
Elicitação e Ciclo de vida

colaboração de requisitos
Avaliação
da solução
Competências
fundamentais
Fonte: IIBA (2015, p. 5).
O BABOK propõe as áreas de conhecimento acima listadas. O mode-

lo também sugere, para cada uma dessas tarefas, um conjunto de téc-
nicas que podem ser usadas para a sua implementação. A partir disso é
possível definir um processo de análise de negócios. Existe uma grande
variedade de possibilidades na definição desse processo e cada empre-
sa deve escolher um que esteja alinhado com sua forma de trabalho.
A atividade de identificação e tratamento dos requisitos é considera-
da uma disciplina especial denominada engenharia de requisitos. Hull
(2011) a define como o subconjunto da engenharia de sistemas focada
na descoberta, desenvolvimento, rastreamento, análise, qualificação,
comunicação e gerenciamento de requisitos que definem o sistema em
níveis sucessivos de abstração.

Requisitos mal definidos levam a sistemas com problemas e, infe-
lizmente, é muito comum sistemas serem definidos sem a necessária
compreensão das necessidades dos stakeholders. Requisitos que apa-
recem durante o andamento do projeto podem levar à necessidade de
retrabalho. Bem sabemos que é muito difícil definir todos os requisitos
de um software no início do projeto; por isso a necessidade de um pro-
cesso de engenharia de requisitos, que organizará essas atividades e
garantirá o atendimento às necessidades dos stakeholders.
5 Engenharia de requisitos versus análise de

negócios
Em um primeiro momento, a análise de negócios e engenharia de
requisitos parecem ser a mesma coisa, mas alguns aspectos as tor-
nam distintas.
A engenharia de requisitos surgiu por meio de profissionais de com-

putação que identificaram uma necessidade de melhor definir os requi-
sitos para serem traduzidos em código. Assim, poderíamos dizer que a
engenharia de requisitos despontou de uma preocupação com os requi-
sitos para se chegar ao código.
A análise de negócios, por sua vez, surgiu da necessidade de profis-

sionais de negócio de obterem sistemas que atendessem às necessi-
dades das organizações ou empresas. Ou seja, ela é resultado de uma
preocupação de profissionais de negócio para se chegar aos requisitos.
Há, portanto, uma superposição entre as atividades das duas abor-

dagens, mas há também preocupações que são específicas de cada
uma. Por exemplo, a análise estratégica é uma preocupação específica
da análise de negócios.
Não cabe aqui discutir mais essas diferenças, mas destacar a exis-
tência de ambas e a possibilidade de uso daquela mais conveniente em
determinado momento.
6 Processo para a engenharia de requisitos
A seguir é apresentado um processo para a engenharia de requisi-
tos que compreende todas as atividades necessárias dentro do ciclo
de vida de software. Este processo envolve também as atividades de
análise de negócios (IIBA, 2015; CMMI, 2010).
Figura 3 – Processo de engenharia de requisitos até a especificação
Planejamento Análise Levantamento Análise Verificação e Especificação

das atividades de de de validação de de
de requisitos negócios requisitos requisitos requisitos softrware
Gerenciamento de requisitos Comunicação de requisitos
O processo de engenharia de requisitos cobre todo o ciclo de vida de

software, apresentando uma atividade mais intensa no início do projeto
e com participação em outras etapas, a ser detalhado a seguir.
6.1 O caso da loja de pet shop Cãobalhota
Com o objetivo de ilustrar a aplicação dos conceitos da engenharia de

requisitos, será usado um estudo de caso de uma loja de pet shop. Dessa
forma, cada atividade será ilustrada com o detalhamento deste caso.
Há um pet shop chamado Cãobalhota no pequeno centro comercial

de um bairro residencial de uma cidade. O proprietário é Pedro Souza;
por gostar muito de animais, ele decidiu, há alguns anos, abrir essa loja.
Os negócios estão indo bem e Pedro quer organizar melhor suas ativi-
dades com o desenvolvimento de um sistema que possa dar suporte às
suas atividades. Pensa também em expandir seu negócio e abrir uma
segunda loja em outro bairro da cidade. O que ele tem atualmente são
diversos controles feitos em planilhas eletrônicas, mas é muita informa-
ção e ele está perdendo o controle das coisas.

7 Planejamento das atividades de requisitos
O planejamento das atividades de requisitos trata de identificar quais
são as pessoas envolvidas com o projeto em estudo (stakeholders) e
mapear as atividades a serem desenvolvidas para se chegar à especifi-
cação de requisitos (IIBA, 2015). Geralmente esse planejamento possui
atividades padronizadas que não dependem muito de qual sistema está
sendo desenvolvido. Dessa forma, pode-se ter um plano padrão e, no
planejamento de um projeto específico, são identificadas as pessoas,
ajustadas as datas e detalhada a sequência de atividades.
Os stakeholders deverão ser identificados com o objetivo de compre-

ender qual seu interesse no projeto, como deve ser feito seu engajamen-
to e como mantê-lo informado sobre o projeto. Devem ser identificados
quais stakeholders deverão aprovar determinados requisitos a serem
levantados. Para isso é construída a matriz de responsabilidades.
O mapeamento das atividades consiste na elaboração de um plano

contendo todas as atividades a serem desenvolvidas até o final do proje-
to. Para isso é necessário saber a precedência das atividades (o que vem
primeiro e o que pode ser feito em paralelo), estimar o esforço de cada
uma delas (número de horas necessárias) e representá-las no tempo.
7.1 Planejamento das atividades da Cãobalhota
Na loja Cãobalhota podem ser identificados os seguintes stakehol-

ders: o proprietário, a atendente da loja (vendedora), o caixa, o cliente e
a analista (de negócios e de requisitos).
Para cada um deles deve ser identificado seu papel e que tipo de
participação deve ter no projeto. Para isso é usado um modelo deseno-
minado matriz RACI – uma matriz de responsabilidades no projeto –,
representado no quadro 1 (IIBA, 2015).
R – Responsible: responsável, quem realiza o trabalho.
A – Accountable: acusável, quem toma a decisão.
C – Consulted: consultado, quem fornece informações sobre as

atividades.
I – Informed: informado, deve ser notificado sobre o resultado.
Observe que alguns desses stakeholders poderão ser entrevistados

diretamente, enquanto outros (como o cliente) não, e é necessário de-
finir alguma forma de obter os requisitos desse stakeholder. Todos os
identificados precisam ser envolvidos no projeto.
Quadro 1 – Matriz de responsabilidades
PROPRIETÁRIO ATENDENTE CAIXA CLIENTE ANALISTA
Cronograma A I I - R
Documento visão R C C - I
Mapeamento dos processos A C C C R
Requisitos do negócio C C C - R
Requisitos funcionais A C C C C
Requisitos não funcionais A C C C R, C
Prova de conceito A C C C R
Fonte: IIBA (2015, p. 333).
O mapeamento das atividades consiste na elaboração de um plano

contendo todas as atividades a serem desenvolvidas até o fim do proje-
to. Ao final, a validação dos requisitos é realizada para identificar se os
requisitos especificados foram implementados no software.

8 Processos de apoio
Durante o desenvolvimento do projeto são necessários os processos
de gerenciamento de requisitos e a comunicação de requisitos.
Gerenciamento de requisitos é um processo que cuida do registro

e da rastreabilidade dos requisitos, além de identificar o status de cada
um. A cada momento do projeto deve-se saber quais são os requisi-
tos válidos, como os requisitos se relacionam entre si (dependências
ou mesmo conflitos), quais requisitos foram implementados e onde
foram implementados. A rastreabilidade dos requisitos permite saber
o status de cada requisito e onde foi implementado. A rastreabilidade
bidirecional significa o reverso: dado um módulo de software, que re-
quisitos ele implementa. Deve-se usar algum tipo de ferramenta para
o gerenciamento de requisitos, a qual pode ser tão simples como uma
planilha eletrônica ou até funcionalidades de um ambiente integrado de
desenvolvimento de software (IIBA, 2015; CMMI, 2010).
Comunicação de requisitos é um processo importante principal-

mente em projetos grandes que envolvem diversos stakeholders que
precisam se manter informados sobre o que está ocorrendo no projeto.
Uma solicitação feita precisa ser informada se vai ser implementada,
quando vai ser implementada ou se não foi aprovada. Mecanismos de
comunicação precisam ser definidos para essa finalidade. A comuni-
cação de requisitos pode ser tão simples como documentos em uma
pasta na intranet que possuem a descrição dos requisitos, das reuniões
para discutir e comunicar requisitos ou ferramentas mais sofisticadas
(IIBA, 2015; CMMI, 2010).
9 Compreensão do negócio
A compreensão do negócio tem por objetivo entender as necessida-
des do negócio para que o levantamento de requisitos seja feito de for-
ma consistente e que realmente agregue valor ao negócio. Geralmente
procura-se saber como a organização funciona, quais são seus objeti-
vos e quais serão os benefícios que o novo sistema deve trazer.
9.1 Compreensão do negócio da Cãobalhota
1. Descrição geral da organização
Nome da empresa: Pet Shop Cãobalhota Ltda
Proprietário: Pedro Souza
Localização: Rua do Bosque, 312 – bairro Elói Chaves
Descrição sucinta dos produtos e serviços: o Cãobalhota é uma loja

de pet shop que vende rações, acessórios para animais de estimação e
produtos veterinários e que presta serviços de banho e tosa. Portanto,
as atividades do Cãobalhota são comércio e prestação de serviço.
2. Estrutura da organização
A Cãobalhota possui quatro pessoas envolvidas diretamente com o

negócio: o proprietário, um vendedor e um caixa, que é uma espécie de
gerente da loja quando Pedro não está. Os dois vendedores fazem tam-
bém o serviço de banho e tosa. Nos dias de grande movimento, como
sábado, há mais duas pessoas que trabalham como avulsos. A loja tra-
balha de segunda a sábado, das 9h às 18h.
3. Objetivos, metas e fatores críticos de sucesso
O objetivo da Cãobalhota é atender bem para atender sempre. A

Cãobalhota procura sempre aperfeiçoar seu atendimento e está sem-
pre buscando maneiras de fidelizar os clientes. As metas da Cãobalhota
são aumentar em 25% o faturamento em relação ao ano passado, orga-
nizar os processos e desenvolver um sistema de informação neste ano.
Os fatores críticos de sucesso são: disponibilidade de produtos na loja,
fidelização dos clientes e a realização dos trabalhos com produtividade.

4. Identificação dos principais processos
A Cãobalhota possui as seguintes grandes atividades:
•• Atendimento ao cliente (sem venda): explicação sobre produtos

e serviços, fornecimento de preços. Esse atendimento pode ser
pessoalmente, por telefone ou pela internet.
•• Venda: fechamento da venda propriamente dita, com todas as in-

formações pertinentes.
•• Compra de produtos: reposição de estoque e compra de mate-

riais de uso interno.
•• Banho e tosa: tratamento dos animais e controle da demanda

como marcação de horário, espera na fila, etc.
Para cada um desses processos de negócio é feita uma pequena des-

crição por meio de diagramas para representá-los, por exemplo o BUC
(Business usecase), que são os casos de uso de negócio. Importante
fazer essas atividades pensando sempre em quais as informações que
os stakeholders vão precisar para desenvolver suas atividades.
10 Levantamento de requisitos
O levantamento de requisitos é a atividade que obtém como resulta-
do o conjunto de requisitos do software a ser desenvolvido. Não é uma
tarefa fácil, pois exige que seja entendido com clareza o domínio do pro-
blema, como funcionam as coisas e as necessidades de cada stakehol-
der. Por essa razão, geralmente existe certo grau de especialização das
empresas de software que costumam atender a um determinado tipo
de mercado para terem um conhecimento melhor do domínio do pro-
blema e realizarem o levantamento de requisitos com maior facilidade.
10.1 Técnicas para levantamento de requisitos
Existem diversas técnicas para o levantamento de requisitos: análi-

se de documentos, avaliação de outros softwares, entrevista, brainstor-
ming, grupo focal, observação, entre outras (IIBA, 2015). A seguir serão
brevemente descritas as técnicas citadas. O profissional que realiza o
levantamento de requisitos será chamado de forma de engenheiro de
requisitos ou analista de negócio, indiferentemente.
A análise de documentos e a avaliação de outros softwares são uma

fonte importante de informações para identificar requisitos. A análise de
documentos é usada para extrair informações de análise de negócios,
incluindo a compreensão e os requisitos contextuais, examinando ma-
teriais disponíveis que descrevem tanto o ambiente de negócios quanto
os ativos organizacionais existentes (IIBA, 2015). Importante destacar
que a legislação precisa ser consultada em casos de aplicações que
devam atender a determinados requisitos legais.
A entrevista talvez seja a forma mais comum de levantar requisitos.

Ela é uma abordagem sistemática destinada a recolher informações
de análise de negócios de uma pessoa ou grupo de pessoas por meio
de uma conversa com o entrevistador, que faz perguntas pertinentes
e documenta as respostas. A entrevista também pode ser usada para
estabelecer relações e construir confiança entre analistas de negócios
e stakeholders, a fim de aumentar o seu envolvimento ou obter apoio
para uma solução proposta (IIBA, 2015). Há técnicas para isso: as en-
trevistas devem ser feitas com um roteiro pré-definido no qual o ana-
lista de negócio deve abrir a seção com uma explicação da finalidade
da entrevista. Perguntas padronizadas devem ser realizadas, algumas
genéricas e outras específicas. Ao final deve ser perguntado se foram
cobertos todos os aspectos do objeto de estudo e se há mais alguma
coisa que o entrevistado gostaria de explanar. Tudo deve ser registrado
de maneira que nenhuma informação relevante obtida seja perdida. É
conveniente que depois de transcritas as informações obtidas, os entre-
vistados aprovem os requisitos descritos.

Brainstorming é uma excelente maneira de promover o pensamento
criativo sobre um problema. O objetivo do brainstorming é produzir inú-
meras novas ideias, e delas extrair temas para análise posterior (IIBA,
2015). Também deve ser uma atividade estruturada com agenda de
atividades, limite de tempo para cada seção e definição de critérios de
avaliação para se chegar a uma lista final de ideias obtidas.
Um grupo focal é um meio para elicitar ideias e opiniões sobre um

produto específico, serviço ou oportunidade em um ambiente de grupo
interativo. Os participantes, guiados por um moderador, partilham suas
impressões, preferências e necessidades (IIBA, 2015). Um caso particular
de grupo focal é denominado reuniões JAD (Joint application design), uma
técnica desenvolvida pela IBM canadense em 1980. Trata-se de uma téc-
nica importante, que permite fazer o levantamento de requisitos de forma
relativamente rápida com uma equipe de profissionais que conheçam o
problema com profundidade (SOLTYS; ROMAN; CRAWFORD, 1999).
A observação é usada para levantar requisitos por meio da visualização

e compreensão das atividades em seu contexto. É utilizada como base
para a identificação de necessidades e oportunidades, compreendendo
o processo de negócio, definindo padrões de desempenho, avaliando o
desempenho-solução ou dando apoio ao treinamento e desenvolvimento.
O analista de negócio vai ao ambiente onde são desenvolvidas as ativida-
des e fica observando o que ocorre, sem interferir; então analisa e anota o
processo de trabalho e as necessidades de informação.
10.2 Descrição dos requisitos
A descrição dos requisitos deve ser elaborada de forma estruturada

para facilitar a sua classificação e organização. Dessa forma, algumas
regras devem ser seguidas no momento de redigir a descrição de um
requisito (HULL, 2011):
•• Cada requisito deve ser identificado de forma única. Portanto
deve ter um código de identificação.
•• Cada requisito deve ter definida sua origem: quem e quando o

declarou.
•• Cada requisito deve ser rastreado: quando foi criado, quando foi
alterado, por quem, quando foi usado e qual seu status.
•• Cada requisito deve ser classificado e priorizado.
•• Cada frase deve descrever um, e somente um, requisito. A descri-

ção do requisito deve ser feita usando linguagem consistente e de
forma padronizada, por exemplo:
◦◦ O <tipo de stakeholder> deve ser capaz de <descrição>.
◦◦ O <tipo de stakeholder> deve ser capaz de <descrição> den-

tro de <desempenho> de <evento> enquanto <condição
operacional>.
◦◦ Exemplo: O <operador da arma> deve ser capaz de <atirar em

um míssil> dentro de <três segundos> de <detecção do radar>
enquanto <em condições severas no mar>.
◦◦ O <tipo de stakeholder> não deve ser considerado violando <re-

gra aplicável>.
◦◦ Exemplo: O <motorista da ambulância> não deve ser conside-

rado violando <as leis de trânsito>.
◦◦ O <tipo de stakeholder> deve <funcionalidade> não menos que

<quantidade> <objeto> enquanto <condição operacional>.
◦◦ Exemplo: O <sistema de comunicação> deve <manter o tele-

fone funcionando> não menos que <8 horas> enquanto <faltar
energia>.

Hull (2011) recomenda que sejam utilizadas frases padrão (clichês)
na descrição dos requisitos. Assim, deve-se ter uma coleção de frases
padronizadas, e a descrição de um novo requisito passa a ser uma ta-
refa de selecionar a frase padrão que mais se encaixa e substituir os
símbolos < e > pelas informações específicas.
Os requisitos devem também atender aos determinados critérios:
•• Atomicidade: cada requisito compreende um único elemento

rastreável.
•• Unicidade: cada requisito pode ser identificado de forma única.
•• Viabilidade: tecnicamente possível dentro do custo e cronograma.
•• Clareza: cada requisito deve ser claramente entendido.
•• Precisão: cada requisito deve ser preciso e conciso.
•• Verificabilidade: cada requisito deve ser verificável.
•• Abstração: não impõe uma solução ou um projeto específico

para a camada inferior.
10.3 Levantamento de requisitos da Cãobalhota
Depois de entrevistados os stakeholders e realizada a atividade de

compreensão do negócio foram levantadas diversas informações sobre
o novo sistema. Cada entrevista deve ser registrada para que se saiba
quem forneceu qual informação.
11 Análise de requisitos
Nesse momento do projeto os requisitos estão mapeados. Torna-se
necessária esta fase para realizar a organização e a análise dos requi-
sitos (IIBA, 2015). Portanto o resultado desta fase é um conjunto de
requisitos organizados, classificados, agrupados e priorizados, ou seja,
trata-se de um trabalho para lidar com o grande número de informações
descobertas na fase anterior.
Para tanto, torna-se necessário estabelecer algumas diretrizes reo-

mendadas por Hull (2011) para fazer essa organização:
•• Minimizar o número de requisitos.
•• Compreender uma grande quantidade de informações.
•• Encontrar conjuntos de requisitos relativos a tópicos particulares.
•• Detectar omissões e duplicações.
•• Eliminar conflitos entre requisitos.
•• Gerenciar interações (por exemplo, requisitos atrasados).
•• Rejeitar requisitos pobres.
•• Avaliar se os requisotos são testáveis.
•• Avaliar os requisitos.
•• Reusar requisitos entre projetos.
•• O analista de negócios precisa criar uma estrutura para classifi-

car os requisitos e organizá-los.
•• Classificação quanto à categoria de requisito (por exemplo, requi-

sito do módulo X).
•• Classificação quanto à abstração (camada de descrição mais ge-

ral ou específica). Os requisitos mais gerais se desdobram em
requisitos mais específicos.
•• Classificação quanto à prioridade Moscow (IIBA, 2015):
◦◦ Must: requisitos que precisam ser atendidos para o sucesso

da solução.

◦◦ Should: requisitos de alta prioridade que devem ser incluídos
na solição, se possível.
◦◦ Could: requisito desejável e não necessário.
◦◦ Won´t: houve acordo para não implementar esse requisito

nesta versão, mas sim em uma versão futura.
Uma classificação de requisitos muito usada é: funcional, reverso, não

funcional e de sistema:
•• Os requisitos funcionais descrevem O QUE o sistema deve fazer.
•• Os requisitos reversos são aqueles que definem o que o sistema

NÃO deve fazer.
•• Os requisitos não funcionais dizem respeito a outras caracterís-

ticas, como desempenho e facilidade de uso.
•• Os requisitos de sistema são aqueles que se referem às caracte-

rísticas técnicas do sistema de computação, como uso de recur-
sos, compatibilidade com ambiente.
Uma técnica muito utilizada para os elementos persistentes (dados

e informações que serão armazenados) é a criação do CRUD, cuja si-
gla significa: create (criação), read (leitura), update (atualização) e delete
(remoção) (BARTELI, 2015). Trata-se da definição para cada elemento
a ser armazenado e para quem pode fazer o que nesse processo. Uma
tabela deve ser feita para cada elemento de dado ou informação indi-
cando que tipo de usuário pode fazer cada uma das quatro operações.
Uma boa prática de desenvolvimento de software é nunca apagar nada:
qualquer item, uma vez armazenado, deve ser mantido no sistema por
questões de segurança e rastreabilidade. Assim, um lançamento errado
deve ser extornado, ou seja, deverá ser realizada uma operação igual de
sinal contrário para registrar o que foi lançado e retirado. Um usuário
que não existe mais deve ser desativado, ou seja, deve existir um cam-
po que é apresentado como comando para apagar, mas, na verdade,
desativa e não mostra mais. Ferramentas de busca desses elementos
podem ser feitas para efeito de auditoria nos sistemas.
Outra classificação de requisitos muito utilizada está definida na

Norma ISO/IEC 25000 (ISO, 2014) que estabelece atributos da qualida-
de para um software:
•• Funcionalidade: são os requisitos funcionais.
•• Confiabilidade: refere-se à tolerância a falhas, à capacidade de

recuperação e ao funcionamento sem falhas.
•• Usabilidade: diz respeito à facilidade de uso e de aprendizagem.
•• Eficiência: refere-se à velocidade de processamento e à utiliza-

ção de recursos da máquina.
•• Manutenibilidade: diz respeito à facilidade de manutenção.
•• Portabilidade: tem relação com a capacidade de operar em diver-

sos ambientes.
Pode ser que, durante o levantamento de requisitos, os requisitos

não funcionais anteriormente apresentados não tenham sido declara-
dos pelos stakeholders. Isso não significa que eles devam ser ignorados.
Pelo contrário, devem ser identificados quais stakeholders podem ser
questionados com relação a esses requisitos para sua incorporação à
coleção. Muitos desses requisitos podem ser definidos pela equipe de
tecnologia da informação da empresa (que também são stakeholders).
Para os requisitos como um todo, é necessário avaliar a sua harmo-

nia sistêmica com os seguintes pontos (HULL, 2011):
•• Completeza: todos os requisitos estão descritos.
•• Consistência: não deve haver conflito entre requisitos.

•• Não redundância: nenhum requisito deve estar declarado mais
de uma vez.
•• Modularidade: declarações de requisitos que operam juntos es-

tão próximos um do outro.
•• Estrutura: há uma estrutura clara no documento de requisitos.
•• Qualificado: o grau apropriado de cobertura de rastreabilidade foi

atingido.
11.1 Análise de requisitos da Cãobalhota
Na Cãobalhota, os requisitos são de alto nível e ainda não podem ser

implementados. Por exemplo, no quadro a seguir, o requisito REQ_01
deverá se desdobrar em incluir cliente, desativar cliente e editar cliente,
que, por sua vez, deverão ser definidos em uma fase mais avançada da
definição de requisitos.
Quadro 2 – Exemplo de planilha de requisitos de alto nível
PLANILHA DE REQUISITOS DO PROJETO CÃOBALHOTA: SISTEMA DE GESTÃO DE LOJA PET SHOP
Item Descrição Tipo Status MOSCOW Origem
REQ_01 Gestão de clientes F A M E1
REQ_02 Gestão de animais F A M E1
REQ_03 Gestão de vendas F A M E1
REQ_04 Gestão de estoque F A M E1
REQ_05 Gestão de compras F A M E1
REQ_06 Gestão de fornecedores F A M E1/E2
REQ_07 Gestão de caixa F A M E1
REQ_08 Gestão de usuários do sistema S A M E4
Possíveis siglas numa planilha de alto nível:
Tipo – F: requisito funcional; NF: não funcional; RV; reverso; S: requisito de sistema
Status – A: Ativo; I: implementado; D: desativado
MOSCOW – M: obrigatório; S: prioridade alta; C: desejável; W: não implementar
Origem: numeração das entrevistas
Ao final do mapeamento, da organização e da priorização dos requi-

sitos, é realizada a tarefa de verificação e validação de requisitos com a
equipe técnica e com os stakeholders, descrita a seguir.

A verificação de requisitos é uma atividade que tem por objetivo iden-
tificar possíveis erros cometidos durante o processo (CMMI, 2010) (ISO,
2008). Com ela, é definido em quais pontos do processo devem ser fei-
tas verificações. Por exemplo, após as entrevistas, o analista de negócio
faz uma primeira versão dos requisitos e a submete ao entrevistado:
isto é uma verificação se o que foi registrado é o que foi relatado. Outro
ponto natural de verificação é logo após a fase de análise de requisitos,
na qual pode ser confirmado se todas as diretrizes foram obedecidas.
Assim, a validação de requisitos é a tarefa de verificar se os requi-

sitos estão atendendo à finalidade do sistema. Uma primeira atividade
de validação que pode ser realizada é logo após a análise de requisi-
tos, que obtém o conjunto completo de requisitos organizados, clas-
sificados e priorizados. Os stekholders podem tomar conhecimento e
aprovar (validar) se esses requisitos atendem às suas expectativas do
ponto de vista do negócio. Em outras palavras, trata-se de avaliar se o
conjunto de requisitos vai produzir um software que resolverá o proble-
ma da empresa.

12.1 Verificação e validação de requisitos da Cãobalhota
A atividade de verificação tem por objetivo eliminar erros de elabora-

ção, enquanto a atividade de validação objetiva garantir que a solução
atenda às necessidades de negócio (CMMI, 2010) (ISO, 2008).
Embora a Figura 3 mostre Verificação e Validação no mesmo qua-

dro, estas são atividades separadas com objetivos diferentes e ocor-
rem no tempo em momentos diferentes. O capítulo 5 vai detalhar estes
dois processos.
Os pontos de verificação são os seguintes:
•• Verificação do primeiro documento de compreensão do negócio.
•• Depois das entrevistas com os stakeholders quando se retorna

para eles com as anotações feitas das entrevistas.
•• Depois da análise de requisitos para verificar se foram atendidas

todas as orientações para elaboração dos requisitos, tais como:
◦◦ Todos os requisitos estão identificados de forma única? (Têm

código?)
◦◦ A origem de cada requisito está definida? (Quem forneceu e

quando?)
◦◦ Alterações estão registradas? (Solicitação, aprovação, etc.)
◦◦ Os requisitos estão descritos de forma clara?
◦◦ Os requisitos foram classificados? (Categoria, abstração,

priorização.)
◦◦ Os requisitos são testáveis?
◦◦ Os requisitos foram analisados quanto à qualidade?

(Funcionalidade, confiabilidade, etc.)
◦◦ Os requisitos foram avaliados quanto à harmonia sistêmica?
(Completeza, consistência.)
•• Verificação do documento de especificação e Requisitos que é,

na verdade, o documento final da coleção de requisitos depois de
analisado e organizado.
•• Os testes de software também são uma atividade de verificação.

Uma das verificações a ser realizada é se todos os requisitos es-
pecificados foram implementados.
Os pontos de validação são:
•• Validação do primeiro documento de compreensão do negócio.
•• Validação da análise de requisitos para verificar se os documen-

tos refletem as necessidades dos stakeholders.
•• Validação do documento de especificação e requisitos.
•• Validação do software implementado (se os requisitos atendem

ao desempenho esperado).
13 Especificação de software
O conjunto de requisitos gerado criará um documento denominado
especificação de software ou especificação de requisitos. Esse documen-
to é a entrada para a equipe de desenvolvimento realizar sua atividade
de projeto de software. Conforme já explicado, pode-se entender que
o processo de requisitos fica hibernado durante a fase de codificação.
Esse processo é somente retomado quando houver alguma alteração
de requisito. Uma situação que ocorre muitas vezes em projeto é, du-
rante o seu detalhamento, surgirem dúvidas que levam à criação de no-
vos requisitos que resolvem questões que não tinham sido pensadas
anteriormente. Nesses casos é feita uma atualização do documento de
requisitos, incluindo novos e/ou alterando alguns existentes. No final do

processo, quando o software estiver pronto, há uma atividade intensa
para a verificação e validação de requisitos (CMMI, 2010).
13.1 Especificação de requisitos de software da

Cãobalhota
A especificação de requisitos é o documento resultante da fase de

análise, depois de verificado e validado. Assim, após realizadas todas as
atividades descritas no item 11.1, é feita a verificação de erros ou faltas.
Depois, é realizada a validação desse documento e obtido o documento
de especificação de requisitos.
No caso da Cãobalhota, a especificação de requisitos deve refletir a

coleção organizada em pacotes de requisitos, que podem ter datas de
entrega a serem definidas no cronograma.
A engenharia de requisitos trata de um dos temas mais importantes
na engenharia de software: definir o escopo e os requisitos do software
a ser desenvolvido.
Neste capítulo, foi apresentado um processo para o desenvolvimen-

to dos requisitos com as seguintes etapas: compreender o negócio, rea-
lizar o levantamento de requisitos, analisar os requisitos e elaborar a es-
pecificação de requisitos. Além dessas etapas, há também as atividades
de verificação e validação para controlar a qualidade dos requisitos e as
atividades de apoio de gerenciamento de requisitos e comunicação de
requisitos. Todas estas atividades são orquestradas pelo planejamento
das atividades de requisitos que realiza sua organização e controle.
Evidentemente o processo de engenharia de requisitos depende da

complexidade e do tamanho do projeto, pois isso implica na quantidade
de requisitos a serem manipulados, na quantidade de horas a serem
trabalhadas e no número de pessoas envolvidas. Quanto maiores os
números, mais necessidade de controle.
Por outro lado, projetos pequenos não precisam ter processo mui-
to complexo de engenharia de requisitos. É necessário, entretanto, que
tenham minimamente algumas atividades, como documento de requi-
sitos e rastreabilidade de requisitos. Sem isso, aumenta-se o risco de
existirem problemas com o gerenciamento de requisitos.
No mercado há ferramentas de apoio que podem ajudar no desen-

volvimento dessas atividades.
Referências
BARTELI, A. Creating CRUD. IBM Systems Magazine, 2015. Disponível em:
<http://www.ibmsystemsmag.com/ibmi/developer/general/creating-crud/?pa-
ge=1>. Acesso em: 10 ago. 2016.
CMMI Product Team. CMMI for development, version 1.3. Pittsburgh: CMMI
Institute, 2010. Disponível em: <http://cmmiinstitute.com/resources/cmmi-de-
velopment-version-13>. Acesso em: 10 ago. 2016.
HULL, Elizabeth; JACKSON, Ken; DICK, Jeremy. Requirements engineering. 3.

ed. London: Springer, 2011.
IIBA – International Institute of Business Analysis. A guide to the business

analysis body of knowledge (BABoK). Whitby: IIBA, 2015.
ISO – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO12207,

2008. Systems and software engineering – software life cycle processes.
Disponível em: <http://www.iso.org/iso/catalogue_detail?csnumber=43447>.
Acesso em: 10 ago. 2016.
______. ISO25000, 2014. Systems and software engineering – systems and

software quality requirements and evaluation (SQuaRE). Disponível em: <http://
www.iso.org/iso/catalogue_detail.htm?csnumber=64764>. Acesso em: 10 ago.
2016.

PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, méto-
dos e padrões. 3. ed. São Paulo: LTC, 2011.
SOLTYS, Roman; CRAWFORD, Anthony. JAD for business plans and designs,
1999. Disponível em: <http://www.thefacilitator.com/htdocs/article11.html em
27/03/2016>. Acesso em: 10 ago. 2016.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. Tradução Kalinka Oliveira e

Ivan Bosnic. 9. ed. São Paulo: Prentice Hall, 2011.
Capítulo 3
Processo unificado/
RUP
O objetivo deste capítulo é apresentar o Processo Unificado

(Unified Process – UP), um nome genérico que abarca um conjunto de
modelos de processo crescentemente utilizados pelas organizações
que desenvolvem software. As suas fases e artefatos são apresenta-
dos e discutidos, assim como as referências bibliográficas que deta-
lham esses elementos.
O UP é o modelo de processo orientado a objetos mais frequente-

mente usado. Ele é iterativo, incremental e orientado a casos de uso, e
visa tratar os riscos o mais cedo possível durante o desenvolvimento.
1
•• Conceitos fundamentais do UP.
•• Fases, iterações e disciplinas do UP.
•• Artefatos do UP.
•• Apresentação sucinta do Processo Unificado Rational.
1 Histórico
A origem e a base essencial do UP vêm da proposta de Ivar
Jacobson denominada Objectory Process, apresentada inicialmente em
1988. Posteriormente, Jacobson se uniria a James Rumbaugh e Grady
Booch, proponentes do RUP, e eles uniriam os seus produtos com esta
última marca.
Figura 1 – História do UP e do RUP (AMBLER, 2013)
nUP
o
oad
Ope
rfeiç
0.9
mo
ape
nUP
o co
RUP
Ope
ead
vida
om
0e
006 : RM P
004
de 2 2005 F & BU
ren
e
F 1.
C
3
lo d
Ma bro d 005: E UP
P v2
5.0
200
Pé
: EP
:A
: cic
v1.0
v3.8
P
RUP
: EU
UP
: BU
Nov o de 2005
006
999
3: R
004
tory
tory
88:
de 2
e
e
de 1
em 2
200
e 19
de 2
bjec
bjec
Out bro d
bro
e
bro
8: O
5: O
ho d
eiro
io d
em
ubr
em
rço
u
198
199
Set
Out
Jun
Ma
Jan
Set
Fonte: Adaptado de Ambler (2013, p. 1).
Os principais marcos da história do UP e do RUP são descritos a se-

guir e resumem a sua história (AMBLER, 2013 RUMBAUGH et al., 1990):
•• 1988: Objectory v1.0 é definido pela empresa Ivar Jacobson’s

Objectory AB.

•• 1995: Rational Corporation compra a Objectory AB.
•• 1996: Rational Objectory Process (ROP) 4.0 é desenvolvido, com

extensões do Objectory e introdução do conceito de iteração.
•• Junho de 1998: RUP 5.0 é liberado. Descreve como aplicar os dia-

gramas UML (Unified Modeling Language).
•• Fevereiro de 1999: o UP é publicado e detalhado.
•• Outubro 1999: um ciclo de vida aperfeiçoado do RUP, inicialmente

proposto por Scott Ambler, é publicado.
•• Fevereiro de 2000: RUP 2000 é liberado. Inclui modelagem de ne-

gócio e aperfeiçoamento na atividade de requisitos.
•• Maio de 2003: RUP 2003 é liberado. Alguns tópicos já presentes

no UP, como agilidade, são incorporados.
•• Janeiro de 2004: Enterprise Unified Process (EUP) v2004 é

liberado.
•• Setembro de 2005: o produto Agile Unified Process (AUP) é anun-

ciado no Software Development Best Practices, em Boston.
•• Outubro de 2005: o Eclipse Project Framework (EPF) e o Basic

Unified Process (BUP) são anunciados pela IBM.
•• Novembro de 2005: o Rational Method Composer (RMC) é anun-

ciado pela IBM.
•• Março de 2006: o BUP é renomeado OpenUP.
•• Setembro de 2006: o EPF 1.0 e o OpenUP 0.9 são liberados.
•• Junho de 2012: Disciplined Agile Delivery (DAD) book released.
Processo unificado/RUP 3
2 Características do processo unificado
O Processo Unificado compreende atividades combinadas em dis-
ciplinas (chamadas workflows) que descrevem como uma atividade
alimenta a outra. As disciplinas são organizadas em iterações (repeti-
ções); cada iteração identifica algum aspecto do sistema a ser conside-
rado. Os detalhes de como são feitas são retardados para mais tarde.
As iterações são organizadas em fases que se repetem (requisitos, aná-
lise, design, implementação). As fases, por sua vez, são agrupadas em
ciclos. Os ciclos geram as liberações (releases) sucessivas do sistema,
nas suas várias versões.
Figura 2 – Características essenciais do Processo Unificado
Interativo e
incremental
Reconhece PROCESSO Orientado a

risco UNIFICADO caso de uso
Centrado em
arquitetura
2.1 Iterativo e incremental
O UP é iterativo e incremental, e o seu desenvolvimento envolve vá-

rias repetições de atividades. Ele possui ciclos de desenvolvimento re-
petitivos, desde os requisitos até a entrega, produzindo várias entregas
incrementais do produto. Esse modelo contrasta com o tradicional mo-
delo cascata, que percorre cada atividade apenas uma vez e apresenta
muitos riscos.
A atividade de desenvolvimento pode ser vista como uma sequência

de iterações, realizadas da seguinte forma (HUNT, 2003; JACOBSON;
BOOCH; RUMBAUGH, 1999):

•• Planejar um pouco.
•• Especificar, projetar (design) e implementar um pouco.
•• Integrar, testar e rodar.
•• Obter feedback após cada iteração.
Trabalhando assim é possível antecipar os riscos de cada iteração e

tratá-los antecipadamente.
2.2 Orientado a caso de uso
O UP é orientado a caso de uso. Esse modelo (HUNT, 2003;

JACOBSON et al., 1999; OMG, [s.d.]):
•• Identifica os usuários do sistema e seus requisitos.
•• Apoia a definição de casos e procedimentos de testes.
•• Direciona o planejamento de iterações.
•• Orienta a criação da documentação de usuário.
•• Direciona a implantação do sistema.
•• Sincroniza o conteúdo dos diferentes modelos.
•• Orienta a rastreabilidade dos diferentes modelos.
O modelo de casos estabelece as funcionalidades do sistema e

orienta todas as atividades do processo.
2.3 Centrado em arquitetura
O modelo UP é centrado em arquitetura, que estabelece uma base

comum para os grupos trabalharem de forma integrada, mesmo que
um esteja trabalhando em uma implementação enquanto o outro já tra-
balha no design da iteração seguinte. A arquitetura é refinada durante o
processo (HUNT, 2003; JACOBSON et al., 1999).
2.4 Reconhece risco
O UP reconhece explicitamente os riscos inerentes ao desenvolvi-

mento de software. Os aspectos de risco avaliados em cada iteração
são tratados e gerenciados tão logo sejam identificados (HUNT, 2003;
JACOBSON et al., 1999).
3 Fases, iterações e disciplinas do processo

unificado
O UP está estruturado por fases e disciplinas, como mostra a figura 3.
As fases indicam a ênfase que é dada em um projeto em cada mo-

mento e, desta forma, estabelecem a dimensão do tempo do projeto.
As disciplinas identificam os fluxos de atividades e agrupam atividades
correlacionadas.
Figura 3 – Visão integrada do Processo Unificado
Fases
Fluxo de trabalho Concepção Elaboração Construção Transição
Modelagem de negócios
Requisitos
Análise e design
Implementação
Teste
Implantação
Gerência de configuração
e mudança
Gerência de projeto
Ambiente
Inicial Elab no1 Elab no2 Const no1 Const no2 Const no3 Trans no1 Trans no2
Iterações
Fonte: adaptado de Kruchten (2003).

3.1 Fases do Processo Unificado
O Processo Unificado divide o projeto em quatro fases: concepção,

elaboração, construção e transição. Cada fase é concluída por meio de
um marco (milestone) (KRUCHTEN, 2003).
A fase de concepção tem por objetivo estabelecer o entendimento

da necessidade e da visão do projeto. Ela define o escopo do projeto.
Nela a análise de negócio é desenvolvida e a viabilidade do projeto é
estabelecida (possivelmente desenvolvem-se protótipos para análise).
Seu principal resultado é a visão do sistema, o que inclui o modelo de
casos de uso de negócio, uma arquitetura preliminar, os riscos mais
importantes e o planejamento da fase de elaboração.
A fase de elaboração levanta os requisitos funcionais e não funcio-

nais do sistema (veja o capítulo 2). O principal resultado é a arquitetura,
que passa a servir de referência para o desenvolvimento (baseline). O
modelo de casos de uso é detalhado nesta fase. São também estabele-
cidos os planos para a fase de construção.
A fase de construção completa a análise do sistema e desenvolve

a maior parte das atividades de design e implementação. É nesta fase
que o produto é majoritariamente construído e testado. O principal re-
sultado desta fase é o produto implementado e testado, com todos os
modelos associados.
A fase de transição é a última fase do ciclo. Ela move o sistema para o

ambiente do usuário, o que inclui a implantação e a manutenção. O prin-
cipal resultado é a entrega do produto final com a qualidade garantida.
3.2 Disciplinas do Processo Unificado
O Processo Unificado possui nove disciplinas: seis são de engenha-

ria de software e três de apoio de software (KRUCHTEN, 2003). São dis-
ciplinas de engenharia de software:
•• Modelagem de negócios: estabelece compreensão e canal de co-
municação entre analistas de negócios, engenheiros de software
e usuários. Descreve uma visão da organização na qual o sistema
será implantado, envolvendo estrutura, processos, papéis e res-
ponsabilidades. O principal resultado é modelo de casos de uso
de negócio.
•• Requisitos: identifica e modela os requisitos funcionais e não fun-

cionais do sistema. O principal produto é o modelo de casos de
uso. É estabelecida e mantida concordância com os stakeholders
sobre os requisitos. O modelo de casos de uso oferece base para
planejar o conteúdo técnico das iterações, o esforço, o custo e o
tempo. São atividades típicas: encontrar atores e casos de uso,
priorizar e detalhar casos de uso, prototipar interface com o usu-
ário e estruturar o modelo de casos de uso.
•• Análise e design: transforma os requisitos em um projeto (de-

sign) do sistema a ser criado, pronto para implementação. Os
principais produtos são o modelo de análise, o modelo de design
e o modelo de implantação. O modelo de análise transforma os
requisitos externos em um modelo interno. Suas atividades típi-
cas são: realizar análise arquitetural, analisar casos de uso, explo-
rar classes e encontrar pacotes. O modelo de design desenvolve
compreensão acerca de aspectos de requisitos não funcionais e
restrições sobre linguagens de programação, sistemas operacio-
nais, SGBDs, aspectos de distribuição, etc. São atividades típicas:
desenvolver o design arquitetural, rastrear casos de uso, refinar e
projetar classes e pacotes. O modelo de design deve ser adapta-
do para corresponder ao ambiente de implementação e atender
aos requisitos de desempenho. O modelo de implantação, por
sua vez, descreve a distribuição física da funcionalidade do siste-
ma nos nós computacionais.

•• Implementação: codifica o design em uma linguagem de progra-
mação apropriada (que inclui compilação, empacotamento, im-
plantação e documentação do software). O principal produto é
modelo de implementação. São atividades típicas: implementar
arquitetura, classes, interfaces e subsistemas; realizar testes de
unidades e integrar sistemas. Os subsistemas de implementação
são organizados em camadas; as classes e os objetos são imple-
mentados em termos de componentes. A implementação inclui
ainda a integração dos resultados produzidos por implementado-
res individuais (ou equipes) ao sistema executável.
•• Teste: prepara e executa as atividades voltadas para a avaliação

do sistema, visando encontrar defeitos. O principal resultado é o
modelo de teste. Cobre as atividades de verificação e validação.
São atividades típicas: planejar e projetar testes, implementar tes-
tes, realizar testes de integração e sistema, e avaliar testes. Os
requisitos funcionais e não funcionais são a referência principal.
Os testes de integração e de sistema são planejados em cada
iteração. Os casos e os procedimentos de teste são preparados,
os testes são realizados, os defeitos são localizados e documen-
tados, e os resultados são analisados.
•• Implantação (deployment): garante que o produto de software

será disponibilizado a seus usuários finais. O software é empaco-
tado, distribuído e instalado. O principal resultado é o conjunto de
versões de entrega (releases). A assistência ao usuário é provi-
da, e as atividades de migração de software e dados fazem parte
do escopo dessa disciplina.
São disciplinas de apoio de software (KRUCTHEN, 2003):
•• Gerência de configuração e mudança: realiza a estruturação sis-

temática dos artefatos, como documentos e modelos, para man-
ter a integridade do produto e o controle de versões (gerência de
configuração) e das propostas de mudanças (gerência de mu-
danças). Os dados e o status de cada item de configuração são
gerenciados continuamente durante o projeto. A baseline do siste-
ma é definida e gerenciada. Responsabilidades são definidas para
decisões relativas a mudanças. Os principais resultados são as
baselines de configuração.
•• Gerência de projeto: planeja, acompanha e controla o projeto.

Envolve planejamento do projeto iterativo (com baixa granularida-
de nos planos de fases e alta nos planos de iterações), acompa-
nhamento, métricas e gestão de riscos. Os principais resultados
são os planos e os registros de acompanhamento.
•• Ambiente: provê à organização de desenvolvimento de software

os processos e as ferramentas que darão suporte à equipe de
desenvolvimento. O objetivo é configurar o processo para um
projeto como uma instância do UP. Isso permite que o proces-
so de adaptação fique mais leve para os usuários do processo.
Ferramentas desenvolvidas pela Rational, como o IBM Rational
Method Composer, ou ferramentas livres, como o OpenUP/Basic,
podem apoiar essa atividade. O principal resultado é um proces-
so configurado.
4 Artefatos do Processo Unificado

O quadro a seguir apresenta um conjunto de típicos artefatos do
Processo Unificado. Eles estão apresentados por fase. O processo da
organização, definido como uma adaptação do UP, deve definir os arte-
fatos e suas características.

Quadro 1 – Artefatos típicos do Processo Unificado
FASE ARTEFATOS
Visão
Business case
Lista de riscos
Concepção Plano de software
Plano de iteração
Principais casos de uso
Ambiente de gerência de configuração
Protótipos
Requisitos funcionais (atores, casos de uso, modelo e casos de uso)
Requisitos não funcionais
Ferramentas
Arquitetura
Elaboração Modelo de componentes
Modelo de design
Modelo de dados
Modelo de implementação
Orçamento e cronograma
Glossário
Produto de software
Test suite
Manual de usuário
Refinamento dos requisitos funcionais (Modelo de use case)
Construção Refinamento do modelo conceitual (Modelo conceitual)
Refinamento do projeto arquitetural
Refinamento do glossário
Projeto de baixo nível (Modelo de projeto)
Planos de testes
Planos de publicação
Transição Planos de testes alfa, beta
Planos de treinamento
Fonte: adaptado de Kruchten (2003).
5 Processo Unificado Rational
O Processo Unificado Rational (Rational Unified Process – RUP) é um
refinamento do Processo Unificado que foi criado pela Rational Software
(atualmente pertencente a IBM). Ele usa uma série de ferramentas ao
longo da estrutura de processo para definir como realizar as atividades
necessárias para rodar um projeto de software, dando condições para
adaptar (tailor) o processo às necessidades específicas da organização,
da equipe e do projeto (AMBLER, 2005; KRUCHTEN, 2003; IBM, 1998).
As organizações mais maduras trabalham com processos definidos.
O Processo Unificado oferece uma estrutura de processo iterativo e in-
cremental orientada a objetos que pode ser adaptada para as necessi-
dades de cada organização, contribuindo para o desenvolvimento de
software de alta qualidade.
A adaptação do UP e do RUP é, sem dúvida, o maior desafio para

os desenvolvedores, pois há que se considerar aspectos de tamanho
das organizações, características e dimensões dos projetos, exigências
específicas dos clientes, grau de formalismo necessário, etc. Definido o
processo, o projeto segue com maior grau de qualidade, pois os riscos
são gerenciados e os resultados se tornam mais previsíveis.
Referências
AMBLER, Scott W. History of the Unified Process. Enterprise Unified Process,
2013. Disponível em: <http://www.enterpriseunifiedprocess.com/essays/his-
tory.html>. Acesso em: 1 jul. 2016.
______. Introduction to the Enterprise Unified Process (EUP), 2005. Disponível

em: <http://www.enterpriseunifiedprocess.com/downloads/eupIntroduction.
pdf>. Acesso em: 1 jul. 2016.

HUNT, John. Guide to the Unified Process featuring UML, Java and Design
Patterns. New York: Springer, 2003.
IBM – INTERNATIONAL BUSINESS MACHINES. Rational Unified Process: best

practices for software development teams. Rational Software White Paper,
1998. Disponível em: <https://www.ibm.com/developerworks/rational/library/
content/03July/1000/1251/1251_bestpractices_TP026B.pdf>. Acesso em: 1
jul. 2016.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The unified software de-
velopment process. Salt Lake City: Addison-Wesley, 1999.
KRUCHTEN, Philippe. Introdução ao RUP: Rational Unified Process. Rio de

Janeiro: Ciência Moderna, 2003.
OMG – OBJECT MANAGEMENT GROUP. Unified modeling language (UML)

version 2.5, [s.d]. Disponível em: <http://www.omg.org/spec/UML/2.5/>.
Acesso em: 1 jul. 2016.
RUMBAUGH, James et al. Object-oriented modeling and design. Upper Saddle

River: Prentice Hall, 1990.
Capítulo 4
Análise e projeto
orientados a objeto
O desenvolvimento de software de alta qualidade tem por base pro-

cessos bem definidos, aplicados, controlados e continuamente melho-
rados. Uma questão central na busca da qualidade é o uso de métodos
de modelagem de sistemas que garantem a integridade conceitual nas
mais diferentes fases.
Entre esses métodos, destaca-se a modelagem orientada a objeto

(OO). Esse método busca facilitar a comunicação entre desenvolvedor
e usuário, utilizando símbolos, conceitos e ferramentas que permitem
manter uma relação clara e natural com o mundo real.
1
O objetivo deste capítulo é apresentar a metodologia de análise e
projeto orientados a objetos.
Ao final do capítulo você estará apto a:
•• Compreender os conceitos fundamentais de OO.
•• Identificar os principais conceitos e modelos da linguagem UML.
•• Identificar o objetivo e os modelos típicos das atividades de análi-

se e projeto orientados a objetos.
A modelagem orientada a objetos (OO) é um paradigma de análise,
projeto e programação de sistemas e de software com base na com-
posição e interação entre diversas unidades de software chamadas
de objetos.
Quadro 1 – Conceitos fundamentais da modelagem OO
CONCEITO DEFINIÇÃO
O relacionamento semântico entre dois ou mais classificadores que envolvem conexões

Associação
entre suas instâncias.
Um classificador para entidades externas a um sujeito que interagem diretamente com

Ator o sujeito. Um ator interage com um caso de uso ou um conjunto coerente de casos de
uso para alcançar um propósito geral.
O descritor de um conjunto de objetos que compartilham os mesmos atributos,

Classe operações, métodos, relacionamentos e comportamento. A classe representa um
conceito dentro do sistema que está sendo modelado.
Um elemento do modelo que descreve características estruturais e de comportamento.

Classificador Os tipos de classificadores incluem ator, associação, comportamento, componente,
interface e classe, entre outros. Classes são os mais gerais tipos de classificadores.
Uma parte modular de um projeto (design) de sistema que oculta sua implementação de
Componente
sob um conjunto de interfaces externas.

CONCEITO DEFINIÇÃO
A especificação de como o estado de um classificador muda no tempo. Descreve a

Comportamento
dinâmica do classificador.
Os mecanismos pelos quais elementos específicos incorporam estrutura e

Herança comportamento definidos por elementos gerais. Por esse mecanismo, uma classe pode
herdar características de uma superclasse.
Interface Uma declaração de um conjunto coerente de características e obrigações públicas.
Uma entidade discreta, com limite e identidade bem definidos que encapsula estado e
Objeto
comportamento. Um objeto é uma instância de uma classe.
Fonte: Rumbaugh, Jacobson e Booch (2004).
A modelagem orientada a objetos constitui um processo sistemático

e semanticamente cuidadoso de abstração da realidade, análise e de-
senvolvimento de solução voltada para sistema de informação.
2 Linguagem de modelagem unificada

A Linguagem de modelagem unificada (Unified modeling langua-
ge – UML) é uma linguagem de modelagem visual de propósito geral
usada para especificar, visualizar, construir e documentar artefatos de
um sistema de software ( RUMBAUGH et al., 2004). A UML permi-
te representar sistemas de forma padronizada. Desenvolvida a partir
dos anos 1990, já teve várias versões, sempre buscando incluir as me-
lhores contribuições dos pesquisadores e desenvolvedores dedicados à
modelagem. Ela busca unificar a experiência acumulada sobre técnicas
de modelagem e incorporar as melhores práticas correntes em uma
abordagem padronizada (FOWLER, 2003).
A UML possui uma notação gráfica e especifica os seus significados

(semântica). Não define processos, apenas apresenta uma simbologia
para representar as decisões, podendo assim ser utilizada para diversas
concepções de processos.
Análise e projeto orientados a objeto 3

Visando manter a UML como um padrão para os desenvolvedores,
o Object Management Group (OMG) publica e mantém versões renova-
das e atualizadas da UML (OMG, [s.d.]).
Os modelos são descritos por intermédio de diagramas. Cada dia-

grama oferece uma visão de um modelo, uma representação parcial do
sistema em desenvolvimento.
Figura 1 – Diagramas da UML 2.5
Diagrama UML 2.5
Diagrama de estrutura Diagrama comportamental

(estático) (dinâmico)
Diagrama de classe Diagrama de caso de uso
Diagrama de objeto Diagrama de atividade
Diagrama de pacote Diagrama de máquina

de estados
Diagrama de
estrutura composta Diagrama de interação
Diagrama de componente Diagrama de sequência
Diagrama de implantação Diagrama de comunicação
Diagrama de perfis Diagrama de tempo
Diagrama de interação geral
Fonte: adaptado de Fakhroutdinov (2013).
Os diagramas estruturais mostram a estrutura estática do sistema

e suas partes nos diferentes níveis e de abstração e implementação, e

como essas partes se relacionam. Já os diagramas comportamentais
mostram o comportamento dinâmico dos objetos de um sistema, que
pode ser descrito como uma série de mudanças do sistema através
do tempo.
3 Análise e projeto orientados a objetos:

visão geral
O desenvolvimento de sistemas de software requer processos defi-
nidos, como já discutido em capítulos anteriores. Qualquer que seja o
processo, algumas atividades são consideradas essenciais: requisitos,
análise, projeto, construção e avaliação (testes).
O objetivo da análise é obter uma representação do domínio do

problema. A análise orientada a objetos (AOO) empenha-se em enten-
der e modelar um problema em seu domínio, utilizando objetos, clas-
ses e herança.
Larman (2006) mostra que o principal papel da análise é investigar o

problema. Há ênfase na descoberta e descrição dos conceitos do domí-
nio do problema (objetos e classes). Exemplos de conceitos: mesa, sala
de aula, professor, apostila. Já no projeto, segundo esse autor, a ênfase
está na definição de elementos lógicos de software, que serão depois
implementados. Definem-se os atributos e os métodos das classes.
Para a classe apostila, por exemplo, podemos ter os atributos identifica-
ção, tamanho, etc. Um método pode ser imprimir.
Na atividade de projeto é desenvolvida a representação abstrata de

uma implementação específica do sistema, levando em consideração
as restrições de custo e desempenho especificadas. O projeto orientado
a objeto (POO) realiza a decomposição orientada a objeto, utilizando a
UML para descrever os modelos lógico e físico, bem como os modelos
estático e dinâmico do sistema.

Na atividade de construção, o desenvolvimento físico do software se
inicia, com produção de códigos e os primeiros testes em ambiente de
desenvolvimento (testes alfa).
Este capítulo tem foco central nas práticas de análise e projeto. As ati-
vidades de requisitos e testes são tratadas em capítulos próprios. A ati-
vidade de construção não é especificamente desenvolvida neste curso.
Há várias abordagens possíveis para a modelagem de análise e pro-

jeto. Nos itens a seguir, apresenta-se uma delas, a qual permite compre-
ender as decisões que são tomadas em cada uma das fases.
4 Modelagem de análise
A análise visa conhecer melhor o problema que se pretende resolver.
Ela parte do modelo de requisitos, que se utiliza dos diagramas de ca-
sos de uso, e descreve os requisitos funcionais e não funcionais.
A análise visa atingir os seguintes objetivos:
•• modelar de forma precisa os conceitos relevantes do domínio do

problema;
•• verificar a qualidade dos requisitos obtidos anteriormente;
•• detalhar os conceitos envolvidos nos requisitos de forma que per-

mitam o desenvolvimento do sistema.
De certa forma, a análise estabelece uma ponte entre o domínio

puramente de negócio, representado pelos requisitos, e o desenho do
sistema. Deve-se, contudo, evitar um nível de detalhe na análise que en-
volva aspectos funcionais do sistema.

4.1 Classes
O primeiro passo na análise é identificar os conceitos, representa-

dos pelos objetos, e as classes do sistema. As classes são conceitos
do domínio do negócio que devem ser representados no sistema. Uma
maneira prática de identificar as classes é procurar substantivos nos
textos que descrevem o funcionamento esperado do sistema. Nem to-
dos os substantivos são classes, mas as coisas do sistema são classes
e, no texto, as coisas são substantivos. Por exemplo:
O vendedor faz o pedido para o cliente. Para cada item do pedido é

feita a baixa da quantidade vendida daquele produto no estoque.
Deve-se tomar bastante cuidado com ambiguidades da linguagem.

Muitas vezes, duas palavras diferentes são usadas para designar algo
que, na verdade, é uma única classe. É bastante comum, também, ha-
ver confusão entre elementos e atores do negócio que não são classes
verdadeiras. Por exemplo: vendedor pode ser uma classe se for impor-
tante que o sistema armazene e opere informações sobre vendedores,
mas se isto não for importante, então vendedor pode ser somente um
ator do sistema. Como regra (salvo exceções) pode se considerar o
seguinte: classes representam coisas a respeito das quais o sistema
deve armazenar e operar informações. Cada classe deve ser represen-
tada por um retângulo.
Figura 2 – Classes
vendedor pedido cliente
produto estoque

4.2 Relacionamentos
As classes se relacionam entre si de diferentes maneiras. Algumas

classes estão ligadas a outras por uma relação que descreve uma de-
pendência semântica entre elas. No texto do exemplo anterior, vê-se
que a classe vendedor relaciona-se semanticamente com pedido.
Figura 3 – Relacionamento entre classes
faz pedido
vendedor
Os relacionamentos podem ser dos seguintes tipos:
•• agregação;
•• composição;
•• associação simples;
•• generalização.
Os relacionamentos simples foram descritos anteriormente. As

agregações representam uma relação todo-parte na qual o todo pode
existir sem as partes. Por exemplo: um clube agrega associados, o es-
toque agrega produtos, um departamento agrega funcionários e a em-
presa agrega departamentos.
Os relacionamentos de composição refletem também uma relação

todo-parte, porém o todo não pode existir sem as partes: cardume é
composto de peixes, uma reta é composta de pontos.
As associações refletem uma classe que é formada a partir da rela-

ção entre duas outras classes e que é chamada classe associada. Por
exemplo: uma empresa emprega funcionários e, deste fato, deriva-se a
classe emprego.

As generalizações descrevem relacionamentos do tipo é um, dizendo
que uma classe maior (mais abrangente ou geral) generaliza classes
mais especializadas. Neste tipo de relacionamento, as propriedades da
classe maior são comuns com as das classes especializadas, mas as
propriedades de cada classe especializada são concernentes somente
a elas mesmas. Por exemplo: a classe polígono generaliza as classes
retângulo, triângulo e pentágono. Pode-se ler esta relação na forma: um
triângulo é um polígono, um retângulo é um polígono, etc.
Figura 4 – Notação utilizada para representação de relacionamentos entre classes
estoque produto
Estoque agrega zero ou mais produtos
reta ponto
Uma reta é composta por pontos
polígono
empresa funcionário
emprego triangulo retângulo
Uma empresa emprega funcionários Polígono generaliza triângulo e retângulo

e gera empregos
4.3 Atributos e métodos na análise
Os atributos representam as propriedades ou qualidades da classe.

São utilizados para armazenar os dados referentes às classes, garantin-
do o armazenamento da informação no sistema. Uma classe pode pos-
suir um conjunto ilimitado de atributos, mas é possível também haver
classes sem nenhum atributo.

No modelo de análise devem ser representados somente os atribu-
tos realmente relevantes no contexto do negócio. Atributos cuja finali-
dade seja puramente voltada para a implementação do software não
devem ser representados.
Figura 5 – Classe e atributos
cliente
Nome
RG
Atributos da classe cliente
Os métodos representam as ações que a classe realiza, ou seja, o

aspecto comportamental e dinâmico do sistema. No modelo de análise
devem ser definidos os métodos mais importantes de cada classe.
Figura 6 – Classe, atributos e métodos
cliente
Nome
RG
Cadastrar cliente ()
Editar cliente ()
Atributos e operações da classe cliente
Um diagrama de classes deve ser elaborado contendo todas as clas-

ses identificadas para o sistema e o relacionamento entre elas. O diagra-
ma de classes representa um modelo estático do sistema, ou seja, as
coisas do sistema são independentes ao tempo e às atividades execu-
tadas. Outros diagramas também podem ser desenvolvidos na análise.

Figura 7 – Exemplo de diagrama de classes
livro
ISBN
Título autor
Sumário
1 .. * 1 .. * Nome
Editor
Bibliografia
Data de publicação
Número de páginas
Linguagem
item de livro conta
Código de barras emprestado Número

Tag RFID História
reservado
Referência Aberta – data patrocinador
Situação
Nome
*
Endereço
registra
biblioteca bibliotecário
Nome Nome
catálogo Endereço Endereço
Posição
Fonte: adaptado de Fakhroutdinov (2013).
5 Modelagem de projeto
O projeto (design) tem como principal função definir a estrutura so-
bre a qual o software vai ser construído. No projeto devem ser detalha-
das a estrutura de informações do sistema e a sua dinâmica.
O projeto estabelece uma ponte entre a análise (domínio semânti-

co) e a implementação, permitindo que os elementos definidos em ní-
veis mais abstratos na análise possam ser implementados em alguma

tecnologia de desenvolvimento. Enquanto na análise devia-se evitar um
nível de detalhe que envolvesse aspectos funcionais do sistema, estes
devem estar presentes no design.
Em desenvolvimentos que exigem a implementação em linguagem

não orientada a objetos, o projeto realiza também a passagem da visão
orientada a objetos para a visão de banco de dados relacional. Assim,
as classes do modelo de análise e projeto são convertidas em tabelas
no banco de dados. Mas, para isso, são necessárias várias adaptações
que não são discutidas neste módulo.
O diagrama de colaboração é uma típica produção da fase de análise.
5.1 Atributos e métodos no projeto
Alguns atributos das classes do sistema podem ser definidos na fase

de análise; ao menos os óbvios já devem ter sido pensados, como atri-
buto preço para uma classe de produtos ou nome para uma classe de
clientes. No projeto, entretanto, todos os atributos precisam ser defini-
dos e detalhados. A definição dos atributos corresponde a encontrar um
nome para eles que seja autoexplicativo, ou seja, que permita entender
o que aquele atributo representa somente pelo nome. O detalhamento
do atributo corresponde à definição do seu tipo e formato.
Por tipo, entende-se, por exemplo, se o atributo é numérico, textual,

data e/ou horário, moeda, etc. Os tipos de atributos podem ser gené-
ricos no nível de análise (como textual ou numérico), mas no projeto
é importante definir tipos específicos, de acordo com a tecnologia de
implementação do sistema utilizada.
Os formatos dos tipos decorrem de algumas restrições ou padrões

existentes: tipos textuais sofrem restrições do número de caracteres
permitidos; tipos numéricos sofrem restrições como inteiro ou real
(ponto flutuante) e de representação de decimais com vírgula (padrão
brasileiro) ou com ponto (padrão inglês), ou ainda de diferentes padrões
monetários; tipos de data e hora sofrem restrições também no padrão

adotado (inglês, nacional ou outro), além de formato de separação. As
restrições de tipos geralmente são causas de grandes problemas de
desenvolvimento, portanto, precisam ficar bem definidas no projeto. Um
cuidado extra deve ser tomado se o sistema em questão tiver integra-
ção de dados com outros sistemas.
5.2 Modelo dinâmico
Os métodos são também desenvolvidos e detalhados no projeto.

Seus algoritmos e características de implementação são definidos.
O projeto detalha o modelo dinâmico do sistema. Um diagrama típi-

co para esse detalhamento é o de sequência, ilustrado na figura 8, que
mostra as interações entre objetos na forma de cercas.
Figura 8 – Exemplo de diagrama de sequência de projeto para o caso de uso Comprar itens
Ator Comprar itens versão 1 o sistema como

uma caixa-preta
Caixa
Repetir até não ter Sistema

mais itens
entrar item (UPC, quantidade)
Texto que esclarece

terminar Venda ()
o controle, a lógica,
a iteração, etc.
registrar Pagamento (quantia)
Pode ser obtido
do caso de uso.
evento de sistema
dispara uma operação
de sistema
Fonte: Larman (2006).

A figura 9 mostra um exemplo de diagrama de colaboração, também
típico da fase de projeto. Os diagramas de colaboração ilustram as inte-
rações na forma de grafo ou rede.
Figura 9 – Exemplo de diagrama de colaboração: Registrar pagamento
primeira mensagem
direção da mensagem
interna
registrar Pagamento registrar Pagamento

POST Venda
(dinheiro fornecido) (dinheiro fornecido)
primeira linha de 1:1 criar

mensagem ligação (dinheiro fornecido)
Pagamento
instância
parametro
Fonte: Larman (2006).
Neste capítulo apresentamos os conceitos fundamentais e alguns
exemplos de modelos. Os processos definidos estabelecem os mode-
los que são utilizados e, como consequência, os diagramas da UML que
devem ser utilizados.
O RUP, por exemplo, apresentado no capítulo 3, está descrito inteira-

mente com o uso de conceitos e diagramas da UML.

Referências
FAKHROUTDINOV, Kirill. The unified modeling language, 2013. Disponível em:
<http://www.uml-diagrams.org/>. Acesso em: 1 ago. 2016.
FOWLER, Martin. UML distilled: a brief guide to the standard object modeling
language. Salt Lake City: Addison-Wesley, 2003.
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao proje-

to orientados a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman,
2006.
OMG – OBJECT MANAGEMENT GROUP. Unified modeling language (UML)

version 2.5, [s.d]. Disponível em: <http://www.omg.org/spec/UML/2.5/>.
Acesso em: 1 jul. 2016.
RUMBAUGH, James; JACOBSON, Ivar; BOOCH, Grady. The unified modeling

language reference manual. 2. ed. Salt Lake City: Addison-Wesley, 2004.

Capítulo 5
Modelo V,
verificação e
validação
A qualidade de software se obtém por processos bem definidos de

modelagem e construção, por um lado, e por sistemática atividade de
avaliação, por outro. A verificação e a validação são as atividades de
avaliação de software em suas várias etapas de desenvolvimento. Elas
contribuem sobremaneira para a entrega de produtos de alta qualidade.
O objetivo deste capítulo é apresentar os conceitos e as práticas vol-

tadas para a verificação e a validação de software. Ao final do capítulo
você estará apto para:
1
•• Identificar as atividades de verificação e validação para a qualida-
de de software, o seu papel e as diferenças entre elas.
•• Identificar as práticas mais comuns relacionadas a essas ativi-

dades, entre elas a Verificação e validação independentes (IV&V).
•• Conhecer o modelo V, que busca sistematizar as atividades de

avaliação no processo de desenvolvimento.
Os processos de verificação e validação (V&V) são usados para de-
terminar se os produtos de desenvolvimento de uma dada atividade
estão de acordo com os requisitos da atividade e se os produtos satis-
fazem ao uso pretendido e às necessidades dos usuários (IEEE, 2012).
Essas avaliações envolvem sistemas, software, hardware, interfaces e
documentação.
Verificação é a confirmação de que os produtos de desenvolvimento

refletem os requisitos especificados para eles. Em outras palavras, ve-
rificação assegura que você constrói o produto corretamente (“you built it
right”) (CMMI Product Team, 2010).
Validação, por sua vez, é a confirmação de que o produto ou servi-

ço, como fornecido (ou como será fornecido) atende completamente
ao seu uso pretendido. Em outras palavras, a validação assegura que
você constrói o produto certo (you built the right thing) (CMMI PRODUCT
TEAM, 2010).
As atividades típicas dos processos de V&V são: análise, avaliação,

revisão técnica, inspeção e testes. As seguintes práticas são utilizadas
para V&V (SPINOLA, 1999):
•• revisão técnica: inspeção e/ou análise realizada sobre produto ou

componente desenvolvido;

•• prototipação: construção de versão preliminar do sistema ou de
parte dele, para permitir avaliação;
•• simulação: utilização de um ambiente de software para auxiliar ava-

liação de um sistema, ou parte dele, durante o desenvolvimento;
•• teste: operação de elementos do sistema já implementados, iso-

ladamente ou em conjunto, para encontrar erros.
Roger Pressman (2002) mostra que a estratégia de teste de sof-

tware está relacionada ao ciclo de desenvolvimento do projeto de sof-
tware, ou seja, as fases de desenvolvimento determinam as etapas de
testes realizados.
As atividades de V&V de um projeto devem ser planejadas. O pla-

nejamento é realizado no início do desenvolvimento, em sintonia com
o planejamento do projeto e de acordo com os padrões de desenvolvi-
mento estabelecidos (COLLOFELLO, 1988). O planejamento de V&V é
tratado em tópico à parte neste capítulo e inclui as seguintes práticas
distribuídas em todo o processo de desenvolvimento: revisões técnicas,
protótipos, simulações, testes de unidades, testes de integração e tes-
tes de validação.
2 O modelo V
O modelo V foi originalmente desenvolvido para engenharia de sis-
temas. Esse modelo é muito interessante para se compreender os
testes de software de uma maneira mais abrangente (SPILNER; LINZ;
SCHAEFER, 2007). O projeto inicia-se na definição de requisitos, evoluin-
do para o projeto funcional do sistema. O projeto técnico é elaborado,
seguido da especificação de cada componente de software. Na figura
1 a seguir, do lado esquerdo está a fase de decomposição e definição
das partes que compõem o sistema; do lado direito está a etapa de inte-
gração e recomposição na qual o sistema é construído e são realizadas
verificações, além de testes e validações.
Modelo V, verificação e validação 3

Pode-se verificar a correspondência entre os lados esquerdo e di-
reito. Da especificação de componente sai o plano de teste de compo-
nente (ou teste unitário) que é realizado no lado direito. O teste de inte-
gração é realizado a partir do projeto técnico do sistema. Com base no
projeto funcional do sistema, é definido e realizado o teste de sistema.
Finalmente o teste de aceitação (validação) é feito a partir da definição
de requisitos.
Figura 1 – Modelo V
Definição Teste
de requisitos de aceitação
Projeto funcional Teste

do sistema de sistema
o
Decom
posiçã
Projeto técnico Teste
posiçã
recom
do sistema de integração
o e de
ção e
Especificação Teste
Integra
finição
de componente de componente
Programação
Implementação Verificação
e integração e validação
Linha do tempo
Fonte: adaptado de Craig e Jaskiel (2002 apud CAETANO, 2008, p. 60).
Esse modelo apresenta a abrangência dos testes e como eles po-

dem ser organizados até se chegar ao sistema como um todo e realizar
a validação.

3 Atividades de verificação
A verificação é realizada durante todo o processo de desenvolvimen-
to por meio de revisões técnicas, simulações e testes.
O CMMI (capability maturity model – integration ou modelo de maturi-

dade em capacitação – integração) propõe os seguintes objetivos para
as atividades de verificação (CMMI PRODUCT TEAM, 2010):
1. Preparar a verificação. Para isso, as práticas exigidas são:
•• selecionar os produtos de trabalho e os métodos para verificação;
•• estabelecer e manter o ambiente para verificação;
•• estabelecer e manter procedimentos e critérios para verificação.
2. Realizar revisões por pares. Práticas exigidas:
•• preparar revisões por pares de produtos de trabalho selecionados;
•• conduzir revisões por pares de produtos selecionados e identifi-

car questões resultantes dessas revisões;
•• analisar dados referentes à preparação, à condução e aos resulta-

dos de revisões por pares.
3. Verificar produtos de trabalho selecionados. Envolve as seguin-

tes práticas:
•• realizar verificação de produtos de trabalho selecionados;
•• analisar resultados de todas as atividades de verificação.
Algumas das práticas citadas são apresentadas nos subtópicos a

seguir.
O quadro 1 apresenta os critérios para as atividades de verificação

nas várias fases do desenvolvimento de software:

Quadro 1 – Atividades de verificação
TAREFA DE
CRITÉRIOS
VERIFICAÇÃO
Os requisitos são consistentes, realizáveis e testáveis.

Os requisitos de sistema foram apropriadamente alocados a itens de hardware, itens de
software e operações manuais de acordo com critérios de design.
Verificação de
Os requisitos de software são consistentes, realizáveis, testáveis e refletem acuradamente
requisitos
os requisitos de sistema.
Os requisitos de software relacionados à segurança (safety & security) e criticidade são
corretos como mostrado por métodos rigorosos.
O design está correto,consistente e rastreável com os requisitos.

O design implementa uma sequência própria de eventos, entradas, saídas, interfaces, fluxo
Verificação de lógico, alocação de orçamento apropriada e definição, isolamento e recuperação de erro.
design Design selecionado pode ser derivado a partir dos requisitos.
O design implementa segurança (safety & security) e outros requisitos críticos
corretamente, como mostrado por métodos rigorosos.
O código é rastreável para o design e os requisitos são testáveis, corretos e em

conformidade com os padrões de requisitos e código.
O código implementa sequência própria de eventos, interfaces consistentes, dados
Verificação de corretos e fluxo de controle, completude, alocação de orçamento apropriada, e definição,
código isolamento e recuperação de erro.
Código selecionado pode ser derivado do design ou requisitos.
O código implementa segurança (safety & security) e outros requisitos críticos
corretamente, como mostrado por métodos rigorosos.
Os componentes e unidades de cada item de software foram completa e corretamente

integrados no item de software.
Verificação da
Os itens de hardware, itens de software e as operações manuais do sistema foram
integração
completa e corretamente integradas no sistema.
As tarefas de integração foram realizadas de acordo com o plano de integração.
A documentação é adequada, complete e consistente.

Verificação da
A preparação da documentação é tempestiva.
documentação
A gestão de configuração dos documentos segue procedimentos especificados.
Fonte: adaptado de ABNT (2009), Adrion (1982) e Kung (2008).
Os subitens a seguir apresentam típicas formas de realizar as ativi-

dades de verificação.

3.1 Verificação por meio de revisões técnicas
As revisões técnicas avaliam, durante o desenvolvimento, o progres-

so do produto em relação aos requisitos técnicos e contratuais (BATE
et al., 1995). Elas envolvem as seguintes atividades (PRESSMAN, 2002;
HUMPHREY, 1995):
•• Revisão de defeitos ou aos pares (peer review) (BATE et al., 1995;

PAULK et al., 1995; ELLISON, 1994): utiliza a técnica de inspeção
visual e análise para identificar fontes de erros em produtos de
trabalho gerados durante o processo de desenvolvimento. Pode
ser vista como uma técnica pela qual alguns colegas auxiliam ou-
tros em seus projetos. Apresenta certo grau de formalismo, o sufi-
ciente para garantir a clara identificação e descrição dos defeitos
encontrados, e o necessário suporte para as atividades de corre-
ção. Uma sessão de revisão pode contar com três a seis pessoas,
envolvendo um líder, o desenvolvedor do produto a ser revisado e
os revisores. Os revisores recebem os documentos a serem revi-
sados com antecedência e levam para uma reunião formal suas
observações e questões. O líder faz um relatório das conclusões
da reunião e encaminha-o à gerência de projeto. Algumas revi-
sões podem reunir pares de produtos que possuam funções inte-
gradas – dois módulos de software ou mesmo um componente
de hardware e um de software, por exemplo –, devendo a reunião
contar neste caso com os desenvolvedores dessas partes e com
um dos revisores, pelo menos, com conhecimento da tecnologia
envolvida em cada uma das partes.
•• Walkthrough (FREEDMAN; WEINBERG, 1993; HUMPHREY, 1995):

o desenvolvedor de um produto ou subproduto apresenta-o, mos-
trando como realiza o que é dele requerido. A audiência é com-
posta por outros desenvolvedores e, possivelmente, pelo cliente
e/ou potenciais usuários do sistema. Os participantes levantam

questões, contribuindo para identificar e resolver possíveis omis-
sões e diferenças de entendimento.
•• Revisão informal: realizada por um único revisor sobre o trabalho

realizado por um desenvolvedor, sem o recurso de reunião. São
registradas observações e questões sobre o produto revisado, e
encaminhadas ao desenvolvedor e à gerência de projeto. Por en-
volver menor esforço, podem ser utilizadas com maior frequên-
cia, de maneira a garantir que todos os componentes do sistema
sejam submetidos a revisão, em todas as fases do projeto.
•• Revisão técnica formal (formal technical review – FTR)

(PRESSMAN, 2002; ELLISON, 1994): é realizada com a participa-
ção da gerência de projeto, no final de cada fase do ciclo de vida
ou periodicamente. O objetivo é avaliar problemas, riscos e ques-
tões com impacto gerencial, que podem comprometer o anda-
mento do projeto.
As revisões técnicas se utilizam de listas de verificação (checklists)

previamente preparadas, encaminhadas aos participantes e utilizadas
como roteiro das reuniões.
3.2 Verificação por meio de simulações
Jean P. Calvez (1993) define os simuladores de forma abran-

gente, como uma ferramenta de software simples que auxilia o
desenvolvimento.
No contexto deste trabalho consideramos como simuladores os am-

bientes que auxiliam a avaliação das várias alternativas de projeto. Eles
se baseiam necessariamente em um modelo – uma representação abs-
trata simplificada, parcial ou total – do ambiente ou do sistema.
Há dois tipos principais de simulações de sistemas (GUPTA; LIAO,

1997):

•• simulação orientada a evento, baseada em modelo de sistema
orientado a um evento e um escalador, que gera os eventos a se-
rem tratados pelo sistema de acordo com regras preestabelecidas;
•• simulação orientada a processo, em que alguns processos ve-

rificam se são geradas as mudanças de sinais e de condições
esperadas.
3.3 Verificação por meio de testes
Os testes de verificação são realizados durante o desenvolvimento.

Embora seja comum e generalizada a utilização de testes nas empre-
sas, pode-se observar que ela ocorre sobretudo nas etapas finais do
projeto, e apenas o teste de aceitação é formal. Sistemas melhores po-
dem ser obtidos com maior formalidade para os testes de desenvolvi-
mento (ELLISON, 1994). O capítulo 6 será dedicado aos testes.
Há dois níveis de testes de desenvolvimento (PRESSMAN, 2002;

ELLISON, 1994):
•• Testes de unidade: um componente é exercitado em ambiente

simulado pelo próprio desenvolvedor e sem alto grau de formali-
dade. Podem ser realizados, paralelamente, vários testes de uni-
dade. Para cada teste, desenvolve-se um plano e, durante a sua
execução, registram-se os resultados no relatório de teste.
•• Testes de integração: para cada conjunto de componentes es-

tabelecido planejam-se e realizam-se os testes. Eles podem
ser utilizados para a validação do sistema contra os requisitos
especificados.

Quando uma modificação é realizada em um projeto, determinando
uma nova versão do software (e possivelmente do sistema), realizam-
-se testes de regressão, ou seja, a reexecução de algum conjunto de tes-
tes, que já tenham sido realizados, para verificar se as mudanças pro-
pagaram efeitos colaterais não previstos (PRESSMAN, 2002). Podem
ser considerados de uma categoria diferente dos testes anteriores por
exigirem um tratamento diferente. A melhor solução nesse caso seria
testar tudo novamente, mas esse trabalho árduo nem sempre é viável,
e existem técnicas para determinar um conjunto de testes que reali-
zem cobertura dos componentes modificados (ELLISON, 1994; WONG;
MALDONADO; DELAMARO, 1997).
As características do projeto desenvolvido, incluindo sua estrutura

lógica e de informações, bem como a sua documentação, podem deter-
minar a alta ou a baixa testabilidade, interferindo, portanto, no resultado
efetivo da tarefa.
Os testes de verificação envolvem os seguintes elementos (a forma-

lidade é maior nos testes de integração):
•• Planos dos testes de verificação, que detalham, para cada teste:
◦◦ o objetivo;
◦◦ os componentes envolvidos;
◦◦ as pessoas responsáveis e/ou envolvidas;
◦◦ o ambiente necessário;
◦◦ os casos de teste;
◦◦ as ferramentas.
•• Realização dos testes.
•• Registros dos resultados, em relatórios de testes.

4 Atividades de validação
As atividades de validação são realizadas em várias etapas do projeto.
A visão que se sobrepõe, nessas atividades, é a do cliente ou usuário final.
O CMMI propõe os seguintes objetivos para as atividades de valida-

ção (CMMI PRODUCT TEAM, 2010):
1. Preparar a validação, com as seguintes práticas:
•• selecionar os produtos e os componentes de produtos para vali-

dação, e os métodos de validação a ser usados;
•• estabelecer e manter ambiente para validação;
•• estabelecer e manter procedimentos e critérios para validação.
2. Validar o produto e os componentes do produto, envolvendo as

práticas:
•• realizar validação sobre produtos e componentes de produtos;
•• analisar resultados de validação.
Algumas das práticas citadas são apresentadas nos subtópicos a

seguir.
Uma tarefa fundamental é a de especificar os critérios de validação,

baseados na especificação do sistema. Esses critérios são desenvolvi-
dos nas primeiras etapas do projeto e são aprovados pelo cliente. Eles
visam estabelecer os instrumentos e os critérios a serem adotados para
validar o sistema, incluindo o método para resolver possíveis deficiên-
cias encontradas (PRESSMAN, 2002; ELLISON, 1994).
Os subitens a seguir apresentam formas típicas de realizar as ativi-

dades de verificação.

4.1 Validação por meio de prototipação
A prototipação consiste em construir uma versão preliminar do sis-

tema ou de parte dele, para permitir avaliação e análise junto ao clien-
te, determinar se o produto é realizável ou investigar aspectos técnicos
específicos, tais como a interface homem-máquina ou a concorrência.
A técnica de storyboarding basicamente corresponde a qualquer téc-

nica que expressa o comportamento do sistema, projeto ou intenção de
implementação pela perspectiva do usuário. Essa técnica foi utilizada
inicialmente no cinema e desenhos animados, representando um esbo-
ço dos personagens e da história.
Os storyboards podem ser categorizadas em três tipos

(LEFFINGWELL; WIDRIG, 2003):
•• Passivo: são constituídos de quadros, fotos, esboços, etc. Neste

caso são apresentadas ao usuário as regras do sistema em sua
sequência, com uma explanação do tipo Quando você faz isto,
acontece isto.
•• Ativo: corresponde a uma sequência de figuras que mostram uma

descrição automatizada do modo como o sistema se comporta
em um uso típico ou em um cenário operacional, por exemplo, em
uma apresentação automática de slides.
•• Interativo: permite ao usuário interagir sobre o sistema de um

modo mais realístico, exigindo sua participação. Pode ser uma
simulação dos possíveis cenários (protótipo não funcional), ou
mesmo um protótipo funcional simplificado do sistema.
A prototipagem funcional implementa parte dos requisitos do siste-

ma por meio da construção de um protótipo que executa o comporta-
mento real desse sistema (com a implementação de algoritmos e banco
de dados), podendo valer-se de ferramentas especialmente construídas

para a confecção deste tipo de protótipo (BOAR, 1984). Posteriormente
este protótipo é descartado, passando-se para o efetivo desenvolvimen-
to do sistema pela sequência tradicional (análise, design, implementa-
ção e testes), de posse de um conjunto de requisitos bem refinados.
Já a prototipagem não-funcional obtém o comportamento dos usu-

ários, stakeholders e do sistema através de interações com estes, por
meio de um conjunto de interfaces gráficas simulando o comporta-
mento real do sistema, sem a implementação de algoritmos e banco
de dados.
O uso de storyboards interativos, que na realidade são protótipos do

sistema (funcionais ou não) permite uma série de vantagens (BOAR,
1984; LEFFINGWELL; WIDRIG, 2003):
•• Redução da distância entre os participantes do projeto: a comuni-

cação é um problema fundamental no desenvolvimento. Mesmo
quando uma pessoa sabe o que quer, sempre ocorrem mudanças
quando as necessidades se transformam em requisitos.
•• Aumento da participação e interesse dos atores: sistemas com-

plexos que envolvem várias áreas de uma empresa requerem um
compromisso, concordância e consenso entre vários atores para
poderem operar corretamente.
•• Validação de requisitos.
•• Testar as interfaces desde o início.
4.2 Validação por meio de testes
Os testes de validação de sistema, ou simplesmente testes de sis-

tema, são o principal instrumento para validação. Constituem uma
complementação dos testes de integração, considerando o sistema
como um todo e tendo como referência a especificação de requisitos
do sistema.

Quando o sistema é desenvolvido para um único cliente, ou um pe-
queno grupo de clientes, esses testes recebem o nome de testes de
aceitação e contam com a efetiva participação do cliente. Quando uma
gama diferenciada de clientes é visada em um único projeto, uma estra-
tégia possível é a de realizar testes alfa e beta. Os testes alfa são reali-
zados por clientes (ou clientes potenciais) no local de desenvolvimento,
enquanto os testes beta são realizados em ambientes de clientes por
usuários finais (PRESSMAN, 2002).
Os testes de validação são necessariamente formais e envolvem os

seguintes elementos:
•• Planos dos testes de validação, que detalham, para cada teste:
◦◦ o objetivo;
◦◦ os componentes envolvidos;
◦◦ as pessoas responsáveis e/ou envolvidas;
◦◦ o ambiente necessário;
◦◦ as ações;
◦◦ as ferramentas;
◦◦ os critérios de validação aplicáveis.
•• Realização dos testes.
•• Registros dos resultados, em relatórios de testes.
•• Os seguintes aspectos são considerados, entre outros, nos testes

de validação: funcionalidade, limites e desempenho.
4.3 Validação por meio de revisões técnicas formais
Revisões técnicas formais realizadas durante e ao final do desenvol-

vimento, e com a participação do cliente, são também instrumento de
validação do sistema.

Os seguintes produtos de trabalho podem ser objetos de revisões
formais de validação:
•• Documentos do sistema, em especial a especificação de requi-

sitos, podendo aqui incluir revisões específicas para validar os
casos de uso e cenários, por exemplo. Revisões referentes ao es-
calonamento de tarefas, em sua fase de definição no projeto do
sistema, podem também ser realizadas (BALARIN et al., 1997).
•• Plano de avaliações, em especial no que se referem à validação

do sistema.
•• Critérios para validação.
•• Planos de testes de validação.
•• Configuração do sistema (essas revisões visam assegurar que os

componentes foram desenvolvidos e integrados) (PRESSMAN,
2002).
5 IV&V: Verificação e validação

independentes
Um conceito crescente em projetos complexos e de grande porte,
mas também perfeitamente aplicável a pequenos projetos, é o de ve-
rificação e validação independentes (independent verification and vali-
dation – IV&V). Essa abordagem consiste em V&V realizadas por uma
organização de terceira parte, contratada pelo fornecedor ou pelo ad-
quirente, não envolvida no desenvolvimento. Em fases bem definidas,
os seus resultados (artefatos), também bem definidos, são avaliados
formalmente, as análises são documentadas e ações corretivas são es-
tabelecidas (LEE, 2012).
A Nasa utiliza IV&V em seus processos de desenvolvimento de siste-

mas há vários anos e estabeleceu um conjunto de conceitos norteado-
res para essa atividade (NASA, 2016):

1. É importante examinar o software em sua interação com o siste-
ma do qual ele faz parte. Isso exige uma compreensão do siste-
ma, dos seus objetivos e do seu ambiente.
2. Há certas perspectivas que devem ser consideradas durante to-

das as análises de IV&V. São análises através de todas as con-
dições operacionais normais e anormais. Essas perspectivas
podem ser identificadas na forma das seguintes questões: (a) O
software do sistema fará o que se supõe que fará? (b) O software
do sistema não fará o que se supõe que não fará? (c) O software
do sistema responderá como esperado sob condições adversas?
3. É importante reconhecer que os requisitos não podem ser avalia-

dos isoladamente, ou seja, devem ser avaliados como um conjun-
to. O mesmo vale para elementos de design, módulos de código,
segurança, etc.
4. Quando uma tarefa de IV&V é completada, considerar os seus

efeitos sobre os resultados de análises prévias. Novas informa-
ções podem afetar resultados anteriores.
5. Em todas as análises de IV&V, o conteúdo sob avaliação deve ser

relacionado retroativamente com as necessidades, objetivos de
sistema e segurança da informação do adquirente para assegurar
que coincidem.
6. Sempre focar nos objetivos da tarefa e nos objetivos de alto nível

do projeto de IV&V.
6 Planejamento de V&V
O planejamento de verificação e validação é essencial para o suces-
so de um projeto e deve ser realizado em sintonia e concomitantemente
ao planejamento do projeto.

O SEI, que publica o CMMI, propõe os seguintes elementos essen-
ciais para o plano de V&V (COLLOFELLO, 1988):
1. Identificação dos objetivos de V&V, a partir dos requisitos e es-

pecificações, visando a atender às expectativas do cliente.
2. Seleção das técnicas de V&V, aplicáveis a cada produto a ser

avaliado, em cada fase do desenvolvimento: requisitos, especifi-
cação, design, implementação (código) e mudanças.
3. Responsabilidades organizacionais, identificando as estruturas

organizacionais necessárias para realizar V&V com a eficácia, efi-
ciência e independência adequadas: organização de desenvolvi-
mento, organização de teste independente (externa ou interna) e
organização de quality assurance.
4. Integração das atividades de V&V, identificando as ações volta-

das para alinhar as várias atividades de V&V no processo de de-
senvolvimento do projeto.
5. Rastreamento de problemas, criando meios para documentar,

acompanhar e resolver problemas de V&V.
6. Avaliação, registrando dados que permitam avaliar o produto e as

técnicas utilizadas para desenvolvê-lo.
Neste capítulo apresentamos os conceitos, os objetivos, as práticas
e os critérios para a realização das atividades de verificação e validação.
A observação de empresas que buscam galgar melhores níveis de

maturidade constata o papel relevante que ocupam as atividades de
V&V. Elas contribuem para que padrões e resultados dos processos e
dos produtos sejam aperfeiçoados continuamente, e, assim, a cultura
da qualidade se consolide nas organizações que a aplicam.

Referências
ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO/
IEC 12207:2009 – Engenharia de sistemas e software: processos de ciclo de
vida de software. Rio de Janeiro: ABNT, 2009.
ADRION, W. Richards; BRANSTAD, Martha A.; CHERNIAVSKY, John C. Validation,

verification, and testing of computer software. Computing Surveys, v. 14, n. 2,
1982.
BALARIN, Felice et al. Scheduling for embedded real-time systems. IEEE Design
& Test of Computers, p.71-82, Jan-Mar 1998.
BATE, Roger. et al. A systems engineering capability maturity model (ver-

sion 1.1). Technical report SECMM-95-01|CMU/SEI-95-MM-003. Pittsburgh:
Software Engineering Institute/Carnegie Mellon University, 1995.
BOAR, B.H. Application prototyping. John Wiley & Sons. New York: 1984.
CAETANO, Cristiano. Gestão de testes: ferramentas open source e melhores

práticas na gestão de testes. DevMedia: Engenharia de Software Magazine, n.
3, p. 58-66, 2008.
CALVEZ, Jean P. Embedded real-time systems: a specification and design

methodology. Hoboken: Wiley, 1993.
CMMI PRODUCT TEAM. CMMI for development (version 1.3). Pittsburgh:

CMMI Institute, 2010. Disponível em: <http://cmmiinstitute.com/resources/cm-
mi-development-version-13>. Acesso em: 1 set. 2016.
COLLOFELLO, James S. Introduction to software verification and validation.

SEI Curriculum Module SEI-CM-13-1.1, 1988. Disponível em: <http://www.sei.
cmu.edu/reports/89cm013.pdf>. Acesso em: 1 set. 2016.
ELLISON, Karen. Developing real-time embedded software in a market-driven

company. Hoboken: Wiley, 1994.
FREEDMAN, Daniel P.; WEINBERG, Gerald M. Manual de walkthroughs: inspe-

ções e revisões técnicas de especificações de sistemas e programas. Trad. R.
Castello. Rev. Téc. R. S. Cassiolato. São Paulo, Makron Books, 1993.

GUPTA, Rajesh K.; LIAO, Stan Y. Using a programming language for digital sys-
tem design. IEEE Design & Test of Computers, p.72-80, Apr-Jun 1997.
HUMPHREY, Watts. S. A discipline for software engineering. Salt Lake City:

IEEE – INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. IEEE 1012

(2012): standard for system and software verification and validation. New York:
IEEE, 2012.
KUNG, David; ZHU, Hong. Software verification and validation. Wiley encyclope-
dia of computer science and engineering. Hoboken: Wiley, 2008.
LEE, Joon Ku; KIM, Yang Mo. Lessons learned from practical independent ver-
ification and validation based on IEEE 1012. Journal of software engineering
and applications, 2012, 5, 810-815. Disponível em: <http://dx.doi.org/10.4236/
jsea.2012.510093>. Acesso em: 1 set. 2016.
LEFFINGWELL, Dean; WIDRIG, Don. Managing software requirements: a use

case approach. Addison-Wesley. 2. ed. Boston: 2003.
NASA – NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. IVV 09-1

independent verification and validation technical framework, 2016. Disponível
em: <www.nasa.gov/sites/default/files/atoms/files/ivv_09-1_-_ver_p.pdf>.
Acesso em: 1 set. 2016.
PAULK, Mark et al. The Capability Maturity Model. Addison-Wesley, 1995.
SPILNER, Andreas; LINZ, Tilo; SCHAEFER, Hans. Software testing foundations.

2. ed. Santa Barbara: Rocky Nook Inc., 2007.
SPINOLA, Mauro de Mesquita Diretrizes para o desenvolvimento de sof-

tware de sistemas embutidos. Tese de doutorado – Escola Politécnica da
Universidade de São Paulo, São Paulo, 1999.
WONG, Eric; MALDONADO, José Carlos; DELAMARO, Márcio Eduardo. Reducing

the cost of regression testing by using selective mutation. In: Conferência
Internacional de Tecnologia de Software, 8. Anais. Curitiba: CITS, 1997.

Capítulo 6
Testes de software
Este capítulo trata do tema testes de software, e o objetivo desta

aula é apresentar como os testes devem ser tratados dentro do proces-
so do ciclo de vida de software.
Ao final desta aula, o aluno terá obtido conhecimentos sobre: bases

conceituais de teste de software; testes de software no ciclo de vida;
normalização dos processos de testes; classificação dos testes; pro-
cesso de teste e ambiente de testes.
1
O processo de testes de software tem se tornado uma atividade
mais estruturada a partir dos desafios impostos pelo Bug do Milênio1.
Na virada de 1999 para 2000 foi feito um grande esforço mundial para
a realização de testes dos sistemas existentes para verificar se ocorre-
riam erros. A partir de então houve vários movimentos que estruturaram
melhor as atividades de testes: associações, empresas e certificações.
Com relação às associações, podem ser citadas várias entidades

cuja finalidade é trabalhar com testes:
•• Associação Latino-Americana de Testes de Software (ALATS).
•• Associação Brasileira de Teste de Software (ABRAT).
•• Associação Brasileira de Melhoria em TI (ABRAMTI).
•• Instituto Brasileiro de Qualidade em Testes de Software (IBQTS).
•• International Software Testing Qualifications Board (ISTQB).
•• Brazilian Software Testing Qualification Board (BSTQB).
•• Quality Assurance Institute – Global Institute (QAI GLOBAL).
•• Quality Assurance Institute – Brasil (QAI Brasil).
Com relação às empresas, pode-se dizer que foram criadas diversas

empresas focalizadas na realização de testes. Tonini (2012), em sua
tese de doutorado, estudou o desenvolvimento do negócio de testes de
software como forma independente de avaliação da qualidade do pro-
duto de software.
Com relação a certificações, existem diversas certificações profis-

sionais para quem deseja se especializar no tema. Geralmente esses
certificados são emitidos pelas associações citadas anteriormente.
1 Bug do Milênio foi o nome dado ao problema de os computadores armazenarem o ano com dois dígitos.
Na virada de 1999 para 2000, ocorreu o risco de o computador interpretar que o ano passaria a ser 1900, e
não 2000, por não existirem os dois primeiros dígitos.

1 Bases conceituais de teste de software
Conforme descrito no capítulo anterior, os testes são uma importan-
te atividade de verificação e validação e, portanto, uma das etapas do
controle da qualidade.
Conceitualmente, se fossem utilizadas técnicas que garantissem a

construção do software “certo da primeira vez”, não haveria a necessi-
dade da realização de testes. Na manufatura há casos de produção de
produtos que não são testados depois de prontos: são realizados testes
de partes do equipamento, mas o equipamento montado como um todo
é ligado pela primeira vez pelo usuário final. Para softwares ainda não
há tecnologia suficiente para garantir isso, mas essa deve ser uma meta
a ser conquistada.
Antigamente, o software era construído de qualquer jeito, sem qual-

quer técnica, e acreditava-se que, testando bastante, seria possível reti-
rar os erros. Essa abordagem tem alguns problemas, começando pela
afirmação de Boehm, Rombach e Zelkowitz (2005): “encontrar e corrigir
erros de software depois da entrega é frequentemente 100 vezes mais
caro do que encontrar e corrigir durante as fases de requisitos e projeto”.
Nos dias atuais, a abordagem, conforme já afirmado diversas vezes,

é procurar fazer certo da primeira vez com técnicas adequadas nas fa-
ses de projeto e com verificações nos pontos adequados. Teoricamente,
se eu faço uma verificação em um determinado ponto do processo do
ciclo de vida, erros não devem seguir para as fases seguintes. Esta é
a importância das verificações, particularmente dos testes abordados
neste capítulo.
Outra questão importante para os testes de software é o grande

número de caminhos possíveis que podem ser percorridos, tornando
praticamente impossível a tarefa de realizar testes 100% e garantir a
ausência de erros:
Testes de software 3
•• O número de entradas possíveis é muito grande.
•• O número de saídas possíveis é muito grande.
•• O número de caminhos dentro do software é muito grande.
Além disso, os testes podem identificar problemas referentes à es-

pecificação elaborada incorretamente, levando à construção de um có-
digo errado do ponto de vista do negócio. Embora essa seja muito mais
uma questão de análise de negócios ou de engenharia de requisitos, é
nos testes onde, muitas vezes, são identificados esses problemas.
1.1 Objetivo das atividades de testes
Segundo Pressman (2002) e Myers (2012), as atividades de testes

são assim definidas:
•• Teste é o processo de execução de um programa com o objetivo

de encontrar erros.
•• Um bom caso de teste é aquele que tem alta probabilidade de

encontrar um erro ainda não descoberto.
•• Um teste bem-sucedido é aquele que identifica um erro ainda não

descoberto.
Portanto, o objetivo de um testador é encontrar erros o mais cedo

possível e garantir que eles sejam corrigidos.
Deve-se entender que o teste é uma técnica do processo de veri-

ficação e sempre realizado com o código, executando o programa ou
fazendo uma análise de seu conteúdo. Alguns autores consideram que
analisar um documento de requisitos é uma atividade de testes, contu-
do, na definição deste livro não é: trata-se uma atividade de verificação
porque não é o código que está sendo analisado.

1.2 Erro e falha
Há uma diferença entre o termo erro e o termo falha (MUSA; IANINI;

OKUMOTO, 1987; SPILNER; LINZ; SCHAEFER, 2007):
•• Erro é alguma coisa feita no código que provoca uma saída não
esperada do software (em inglês error, bug).
•• Falha é a manifestação do erro quando o software é executado

(em inglês failure).
Um erro pode não se manifestar: basta um software, ao ser executa-

do, nunca passar por esse trecho de código.
Um erro (bug) ocorre quando:
•• O software não faz algo que, na especificação do produto, está

definido que deveria fazer.
•• O software faz algo que, na especificação do produto, está defini-

do que não deveria fazer.
•• O software faz algo que, na especificação do produto, nada está

mencionado.
•• O software não faz algo que, na especificação do produto, nada

está mencionado, mas deveria.
•• O software é difícil de entender, difícil de usar, lento – na visão do

testador –, e será visto pelo usuário final como pleno e não correto.
2 Testes de software no ciclo de vida
Uma forma de organizar as atividades de testes é defini-las dentro
do ciclo de vida de software. Cada empresa pode definir um ciclo de
vida específico. No capítulo 1 foram apresentados diversos ciclos de
vida que podem ser definidos para um projeto de software, como cas-
cata, iterativo, V, espiral e ágil. Observe nas figuras do primeiro capítulo
que, em alguns deles, é explícita a atividade de testes e em outras está
embutida em V&V.
Particularmente o modelo V, descrito no capítulo 5, que trata das

atividades de verificação e validação, mostra de forma muito clara as
atividades de teste que evoluem do teste de componente para teste de
integração, teste de sistema e teste de aceitação.
2.1 Processo de testes
O processo de testes, segundo Bastos et al. (2007) é formado por

seis etapas, conforme representado na figura 1. Os procedimentos es-
peciais tratam das definições da abordagem a ser dada nas atividades
de testes. É um guia operacional de testes que estabelece os objetivos,
a equipe, as responsabilidades, a avaliação de riscos, o nível de serviço,
entre outros. O planejamento define o plano propriamente dito e esta-
belece a estratégia de testes. A preparação é uma atividade técnica que
prepara tudo que é necessário para a realização dos testes. A espe-
cificação elabora e revisa os casos de testes. Um caso de teste é a
especificação de um teste a ser realizado com os passos que devem
ser seguidos e que dados devem ser utilizados. Portanto, a execução é
a realização dos diversos casos de testes seguindo o plano elaborado.
A entrega conclui o ciclo de testes. Não está nesse fluxo, mas os testes
reprovados retornam para a área de desenvolvimento e retornam para
um novo ciclo até o completo sucesso dos testes.

Figura 1 – Processo de testes
Planejamento
Procedimentos
Especificação Execução Entrega
iniciais
Preparação
Observando o ciclo de vida de software e o processo de testes, pode-

-se estabelecer um relacionamento entre eles da seguinte forma:
•• Os procedimentos iniciais e o planejamento podem ser realizados

juntamente com o plano do projeto em seu início.
•• A especificação dos casos de testes pode ser elaborada junto

com a etapa de requisitos de software.
•• A execução é realizada na etapa de testes.
•• A entrega é realizada a cada ciclo de testes, retornando os defei-

tos identificados para a etapa de codificação para depois sofrer
um novo ciclo de testes.
3 Normalização e maturidade de testes

Com o objetivo de padronizar as atividades de testes surgiram diver-
sas normas aqui mencionadas, bem como o conceito de maturidade
em testes com diversos modelos propostos.
3.1 Normalização dos processos de testes

Com a consolidação das atividades de testes começaram a surgir
diversas normas que estabelecem diversas orientações para esta ativi-
dade. Podem ser citadas:
•• Norma IEEE 829 Test Documentation.
•• Norma IEEE 1008 Unit Testing.
•• Norma BS 7925-1 Vocabulary of Terms in Software Testing

(British Standards – BS).
•• Norma BS 7925-2 Software Component Testing Standard.
A ISO utilizou as iniciativas acima citadas para elaborar a série de

Normas 29119 para testes. São elas:
•• ISO/IEC 29119-1:2013 – Software and System Engineering –

Software Testing – Part 1: concepts & definitions (publicada em
29 de agosto de 2013). O objetivo dessa norma é apresentar o vo-
cabulário que é utilizado em todas as demais normas do conjun-
to 29119. Ela formaliza as definições e descreve os conceitos de
teste de software e também formas de aplicação de processos,
técnicas e documentos.

Software Testing – Part 2: test processes (publicada em 29 de
Agosto de 2013). O objetivo dessa norma é definir um modelo
genérico de processo para o teste de software que pode ser utili-
zado com qualquer ciclo de desenvolvimento de software. O mo-
delo especifica processos de teste que podem ser utilizados para
governar (nível organizacional), gerenciar (nível gerencial) e im-
plementar (nível operacional) os testes de software em qualquer
organização, projeto ou atividade de teste.
O processo de teste é tem base em um modelo de processo em três

camadas:
a. Especificações de teste organizacional, contendo as políticas de

teste da organização, a estratégia organizacional de teste, entre
outros detalhes do nível organizacional.

b. Gerenciamento de teste, que contém as políticas e as diretrizes de
testes relativas ao projeto em si que são de interesse da gestão.
c. Testes dinâmicos, contendo os processos de realização dos tes-

tes dinâmicos, aplicáveis a software. Os testes estáticos, embora
reconhecidos na parte 1 da norma, não foram considerados nes-
sa parte do documento, uma vez que não há como padronizar
o processo de execução dos testes estáticos (investigação do
código).
d. Por outro lado, é feita uma abordagem de teste fundamentado

em risco. Teste com base em risco é uma melhor prática para
gerenciamento de teste, uma vez que essa abordagem permite
que o teste seja priorizado com base nas funcionalidades e carac-
terísticas mais importantes do sistema sob teste.

Software Testing – Part 3: test documentation (publicada em 29
de agosto de 2013). Esta norma contém modelos e exemplos de
documentação de teste. Os modelos (ou templates) estão dis-
postos na mesma ordem dos processos a que se referem e que
estão descritos na parte 2. Essa norma suporta os documentos
utilizados para o teste dinâmico, os testes funcionais e os não
funcionais, e para o manual e os testes automatizados, de script
e improvisados.
•• Os detalhes de cada documentação são tratados também nos

anexos:
◦◦ anexo A: contém sinteticamente o conteúdo de cada

documento;
◦◦ anexo B: contém detalha os processos ligando-os aos

documentos;
◦◦ anexo C: contém exemplos de documentos e de processos;
◦◦ anexos D até S: contêm exemplos da aplicação dos modelos;
◦◦ anexo T: fornece mapeamentos das normas existentes.

Software Testing – Part 4: test techniques (publicada em 12 de
março de 2015). Esta norma define as técnicas de projeto de tes-
te que podem ser usadas durante o processo de projeto de teste
e implementação (a implementação é o foco da parte 2). O públi-
co-alvo dessa norma, mas não se limitando a eles, são os testa-
dores, os gerentes de teste e os desenvolvedores, especialmente
os responsáveis pela gestão e execução de testes de software.
•• ISO/IEC 29119-5 (em produção – julho 2016) – Working draft

(Final Draft International Standard – FDIS) – Software and System
Engineering – Software Testing – Part 5: keyword driven testing.
Esta norma fornece uma solução eficiente e consistente para tes-
tes dirigidos por palavra-chave, dando uma introdução aos testes
conduzidos por palavra-chave. Ela trata também dos requisitos
envolvidos em testes dessa natureza, facilitando o entendimento
e o compartilhamento dos itens de trabalho, tais como: casos de
teste, dados de teste, palavras-chave ou especificações comple-
tas do teste. Ajuda também na definição dos requisitos mínimos
do ferramental a ser utilizado e, por conseguinte, trata também da
troca de dados entre ferramentas.
No Brasil, a ABNT possui um grupo de trabalho que participa da ela-

boração dessas normas e realiza a tradução para o português.
3.2 Maturidade em testes de software
Diversos modelos de maturidade de testes foram desenvolvidos de

maneira similar ao CMMI. De uma maneira geral, os modelos de ma-
turidade de testes de software surgiram com o intuito de avaliar e me-
lhorar o nível de qualidade dos processos de testes aplicados em uma

organização que realiza testes de software (MOREIRA FILHO; RIOS,
2003).
Ao avaliar a maturidade dos processos, a preocupação é saber se o

atingimento da qualidade ocorre devido ao acaso ou, então, se é fruto de
um trabalho planejado e melhorado continuamente (SWINKELS, 2000;
KULKARNI, 2006). Para tanto, um modelo de maturidade deve consi-
derar o que é realizado (processo), os papéis e as responsabilidades
(atribuição às pessoas) e se a forma de execução está alinhada com as
melhores práticas. Atualmente, os três principais modelos de maturida-
de em testes de software são: TIM, TPI e TMM.
3.2.1 Test improvement model (TIM)
O test improvement model (TIM) tem como objetivos: identificar o

estado atual da prática nas áreas chaves; ser um guia para implemen-
tação dos pontos fortes que a equipe tem; identificar, mitigar e até eli-
minar os pontos fracos. O modelo foi elaborado por Thomas Ericson,
Anders Subotic e Stig Ursing (ERICSON; SUBOTIC; URSING, 1998) e suas
áreas-chave são: a organização, o planejamento e o monitoramento; o
ambiente de teste; os casos de teste e as revisões de código e scripts
de testes. Cada uma dessas áreas pode ser composta por tantas ativi-
dades quantas forem consideradas importantes e necessárias. Cada
unidade (atividade de uma área-chave) é classificada conforme um dos
possíveis níveis de qualidade: nível básico, nível eficiente (reduz custo),
nível eficaz (reduz risco) e em melhora contínua.
3.2.2 Test process improvement (TPI)
O test process improvement (TPI) é um modelo que mede a maturida-

de das atividades de teste de uma organização com base no resultado
de avaliação (básico, controlado, eficiente e em melhoria contínua) de
vinte áreas-chave referente aos testes: planejamento, estratégias, casos
de testes, scripts, etc. O modelo foi desenvolvido por Jari Andersin, da
Universidade de Helsinki, na Finlândia (ANDERSIN, 2004).
Para cada uma das vinte áreas-chave, pode-se associar tantos che-
ckpoints quanto necessários, bem como tantas recomendações para
a melhoria.
3.2.3 Test maturity model (TMM)
O test maturity model (TMM) é um modelo elaborado pelo Illinois

Institute of Technology, nos Estados Unidos, com base nos conceitos do
CMMI, admitindo cinco níveis de maturidade (inicial, gerenciado, defini-
do, gerenciado quantitativamente e otimizando) (KOOMEN; POL, 1999).
Ele contém objetivos, áreas de processos de testes e um conjunto de
boas práticas. Com esses modelos pode-se implementar os processos
de testes e seguir os modelos de maturidade propostos.
4 Classificação dos testes

Os testes podem ser classificados segundo diversos critérios. Serão
apresentados aqui os tipos de testes segundo os seguintes critérios: visi-
bilidade, dinâmica, fase do projeto, funcionalidade, estrutura e finalidade.
4.1 Tipo de teste quanto à visibilidade
O termo visibilidade refere-se à visibilidade do código, ou seja, trata-

-se dos testes do tipo caixa preta ou caixa branca.
Os testes caixa preta são realizados considerando apenas as espe-

cificações de entrada e saída, sem entrar no mérito construtivo do sof-
tware. Portanto, como o código foi construído não é considerado. Dada
a especificação do que o software deve fazer, neste tipo de teste são
aplicados dados na entrada e é verificado o resultado obtido na saída.

Os testes caixa branca, por sua vez, são realizados considerando
como o software foi construído e observando que caminhos realiza. Os
testes são selecionados para provocar a passagem em determinados
pontos do código.
4.2 Tipo de teste quanto à dinâmica e quanto à fase do

projeto
Quanto à dinâmica, os testes podem ser estáticos ou dinâmicos.
•• Os testes estáticos são realizados sem a execução do programa.

Consistem, por exemplo, em examinar e rever um documento de
especificação ou um código sem executar o programa.
•• Os testes dinâmicos são realizados no computador, executando

o programa em condições preestabelecidas.
A abrangência refere-se à quantidade de código envolvida na realiza-

ção dos testes. Os testes podem ser: unitários, de integração, de siste-
ma e de regressão.
•• Os testes unitários são realizados em cada módulo isoladamente.
•• Os testes de integração são realizados integrando os módulos

para funcionarem em conjunto. Pode ser que dois módulos fun-
cionem isoladamente, mas não consigam interagir.
•• Os testes de sistema são realizados no sistema completo com

todas as partes já incorporadas.
•• Os testes de regressão são a repetição de testes do sistema todo

ou parte dele. Quando ocorre uma alteração em um módulo, é
necessário repetir os testes com o objetivo de verificar se não
houve efeito colateral (interferência de uma alteração em outra
parte do software).
4.3 Tipo de teste quanto à funcionalidade
Quando nos referimos à funcionalidade, trata-se dos testes funcio-

nais e não funcionais.
Os testes funcionais verificam o funcionamento de cada função des-

crita na especificação do software. Esses testes são realizados com um
conjunto de dados (massa de dados) escolhido especificamente para
verificar determinadas situações de funcionamento. Para tanto, devem
ser considerados os seguintes pontos: partição de equivalência, análise
do valor limite e fluxo lógico.
•• A partição de equivalência identifica os dados a serem testados

e os classifica em categorias. Quais seriam, por exemplo, as ca-
tegorias de uma especificação na qual a idade de um empregado
é válida de 15 a 80 anos? Nesse caso existem três categorias de
dados: os valores de dados entre 15 e 80, abaixo de 15 e acima
de 80.
•• A análise do valor limite seleciona como dados os valores limites

das partições de equivalência para a realização dos testes. No
exemplo anterior, a massa de dados deve ter os seguintes valo-
res: 14, 15, 80 e 81 anos.
•• O teste do fluxo lógico do software escolhe uma sequência de

operações para a realização das funcionalidades. Esse fluxo lógi-
co refere-se à lógica da aplicação, ou seja, à caixa preta. Assim,
não se chega ao detalhe da lógica do código, mas sim ao teste de
alternativas no fluxo da operação.
Os testes não funcionais avaliam outras características do softwa-

re. Nesse caso devem ser considerados testes de desempenho, de con-
trole de dados, de qualidade e de sistema. A realização dos testes de
qualidade tem técnicas específicas para sua realização.

•• Os testes de desempenho examinam o comportamento em con-
dições extremas de operação, tais como número de usuários si-
multâneos e volume de informação tratada.
•• Os testes de controle de dados armazenados verificam itens

como frequência de uso, restrições de acesso, requisitos de guar-
da e retenção de dados.
•• Os testes de qualidade examinam características de operação,

tais como: confiabilidade (funciona sempre sem apresentar fa-
lha), usabilidade (facilidade de uso), manutenibilidade (facili-
dade de manutenção) e portabilidade (operação em diferentes
plataformas).
•• Os testes de sistema examinam características de operação, tais

como: instalabilidade (facilidade de instalação), integridade de
banco de dados (proteção de dados e robustez) e recursos de
suporte (atendimento a usuários e à equipe).
4.4 Tipo de teste quanto à estrutura e quanto à finalidade
O objetivo dos testes estruturais é garantir que o produto seja es-

truturalmente sólido e que funcione corretamente. As técnicas usadas
para esse tipo de teste não objetivam as funcionalidades corretas, mas
sim a estrutura robusta. Trata-se de um teste caixa branca no qual se
analisam os caminhos que o software pode fazer (estrutura) para que
todos os outros sejam testados.
Já os tipos de testes quanto à finalidade são os realizados para pas-

sar (test-to-pass) ou para falhar (test-to-fail).
•• No teste para passar (test-to-pass) é verificado se o software mi-

nimamente funciona nas situações normais de operação. Esse
teste é também chamado de “teste de fumaça” (smoke test).
•• No teste para falhar (test-to-fail) é verificado até onde o software
funciona forçando situações extremas de operação, como dados
inválidos, maior carga de dados, número de usuários, entre outras.
5 Exemplo de um processo de teste

Será apresentado um exemplo de processo de teste para software
de pequeno porte e discutida a elaboração de um processo de testes
para software de maior porte.
5.1 Processo de testes para software de pequeno porte
No processo de teste apresentado na figura 2 não estão represen-

tados os detalhes de testes unitários que formam um fluxo de diversos
testes que, depois de executados com sucesso, evoluem para a etapa de
integração. Porém, o processo é sempre o mesmo: testes com sucesso
seguem, testes com problemas retornam. Nesse retorno é necessário
realizar uma análise para decidir se são necessários novos testes ou
testes de regressão, dependendo da gravidade das falhas encontradas.
Um exemplo de plano de testes está estruturado no quadro 1 com

seis colunas: caso de teste, ação a ser tomada, procedimento passo a
passo, parâmetros a serem usados, OK e observação.
A elaboração desse plano de testes é feita pelo especificador em

tempo de elaboração de requisitos de software. Para cada requisito, um
ou mais casos de teste. Torna-se necessário refletir como deve ser tes-
tado cada item e que dados de teste devem ser selecionados. É realme-
te uma tarefa trabalhosa, porém importante.

Figura 2 – Exemplo de processo de testes
Testador
Executar Realizar a
os testes entrega NÃO
TEM BUG? Relatório
de testes
SIM
Programador
Fazer a Corrigir NÃO

codificação erros
Precisa de novo
PROCESSO DE TESTES
Plano de Testes?
Analista
Elaborar arquitetura
e projeto de software
Especificador
Elaborar a especificação Elaborar o plano

de software de testes
Plano de
testes
de projeto
Gerente
Elaborar plano Elaborar os Planejar as

do projeto procedimentos atividades
iniciais de testes
Cada caso de teste deve ser registrado. A figura 2 mostra que, para
o teste de um cadastro é necessário realizar, na verdade, três testes:
dados válidos, dados incompletos e dados errados para verificar o com-
portamento dos sistemas nessas condições.
Todos os testes devem ser numerados para facilitar a referência no

caso necessidade de correção e essa numeração deve ter vínculo com
o número do requisito implementado. Na coluna OK deve ser registrado
o resultado: OK ou NOK. No caso de NOK, anotar na observação o que
houve de errado.
O resultado do teste deve ser tabulado para efeito de estatística

de qualidade de software (porcentagem de defeitos encontrados). O
programador deve receber os resultados a serem corrigidos, corrigir e
devolver ao testador. O testador repete o teste e registra o resultado até
o fechamento completo do software.
Quadro 1 – Exemplo de plano de testes
Data Testador
Caso Ação Procedimento Parâmetros OK Observação
1. Preencher todos
1.1 Cadastro os campos.
Cliente inserido com
com dados 2. Clicar em inserir.
todos os dados.
corretos. 3. Verificar inserção
na tabela cliente.
1. Preencher todos
os campos menos Se campo obrigatório,
1.2 Cadastro um ou mais. não cadastrar. Se
1. com dados
2. Clicar em inserir. campo não obrigatório,
Cadastrar incompletos.
3. Verificar inserção cadastrar.
cliente.
na tabela cliente.
1. Preencher um ou
mais campos com Não permitir cadastro.
dados inválidos.
1.3 Cadastro Não travar programa
com dados 2. Clicar em inserir. ou fechar.
errados. 3. Verificar inserção Dar mensagem de erro
na tabela cliente OU amigável.
4. Verificar erro.
5.2 Testes de software em aplicações de maior porte
Em aplicações maiores (maiores em termos de tamanho da aplica-

ção ou número de horas necessárias para seu desenvolvimento), as em-
presas fazem a contratação de terceiros para o processo de desenvolvi-
mento de testes, além de uma empresa especializada para a realização
deles. Nestes casos, o contratante realiza a especificação do software
e entrega para um terceiro realizar o desenvolvimento. Este fornecedor

pode usar um ambiente próprio para o desenvolvimento ou mesmo usar
o ambiente oferecido pelo contratante. Esse ambiente é sempre aparta-
do do ambiente de produção. Trata-se de um ambiente específico para
desenvolvimento.
Quando chega a hora de realizar os testes, a empresa especializada

em teses é quem executa a atividade. Os testes são realizados em um
terceiro ambiente preparado para isso, muitas vezes no contratante que
possui as ferramentas de teste e também todo o ambiente com dados,
sistema operacional e as aplicações. Interação entre o desenvolvedor e
o testador é realizada até que a aplicação esteja aprovada em todos os
testes nesta etapa do projeto.
Uma vez aprovados todos os testes, dependendo da criticidade da

operação, há um quarto ambiente de validação no qual a nova aplicação
se integra com o ambiente de operação (simulado). Essa validação é
muitas vezes chamada de homologação.
Aprovada a homologação, a nova aplicação (ou alteração de aplica-

ção existente) entra em uma fila para colocação em produção. Existem
momentos programados para isso, geralmente quando há baixo tráfego
de transações. Colocado no ar, seu desempenho é acompanhado pe-
las equipes responsáveis, e se houver qualquer anomalia, é retornada
a versão anterior. Geralmente quem realiza a colocação em marcha é a
empresa contratante com o apoio das demais.
O gerenciamento dessas etapas é complexo e, na maioria das vezes,

os processos são muito rígidos e bem controlados para que não haja
risco quando ocorrer qualquer problema. Modelos como ITIL são co-
mumente utilizados para a realização desse gerenciamento e controle.
6 Ambiente de testes
O ambiente de testes é aquele preparado para a realização das ativi-
dades de testes. É necessário que seja um ambiente apartado do am-
biente de produção onde está a operação da empresa com os dados re-
ais. Nesse ambiente deve ser reproduzido, geralmente em escala menor,
o ambiente de operação. Isto significa que servidor, sistema operacional,
aplicações com as quais o sistema vai interagir, banco de dados e outras
ferramentas devem estar presentes. Ferramentas para apoio aos testes
ou mesmo automação dos testes devem estar presentes também.
6.1 Ferramentas de testes
São diversas as ferramentas que podem ser utilizadas para a realiza-

ção dos testes. As funcionalidades dessas ferramentas podem ser as
seguintes (SPILNER; LINZ; SCHAEFER, 2007):
•• Ferramentas para gerenciamento e controle – basicamente ca-

dastram cada item de configuração de software e acompanham
seu status até que esteja completamente testado e aprovado.
•• Ferramentas para teste de especificação – são geradores au-

tomáticos de dados de testes para analisar os resultados para
cada caso. Podem ser geradores de dados de teste para bancos
de dados, geradores baseados no código, geradores baseados na
interface e baseados na especificação. Spilner, Linz e Schaefer
(2007) chamam a atenção para o fato de que esses geradores
não fazem milagre: é necessário um trabalho de análise para se-
parar os casos importantes daqueles que não fazem sentido.
•• Ferramentas para testes estáticos – fazem a análise do código

a partir de boas práticas de programação. O código é examinado
automaticamente e, a partir de determinadas regras, podem ser

identificadas anomalias no código, como fluxo de dados e fluxo
de controle. Determinadas construções podem ser identificadas
e apontadas para exame mais apurado, inclusive medições de
itens, como complexidade ciclomática de McCabe.
•• Ferramentas para testes dinâmicos – são diversos tipos de tes-

tes que podem ser realizados com essas ferramentas: debuggers
(permitem executar e parar o programa em pontos especificados
e indicam em que momento foi identificado um erro), drivers de
teste (permitem executar o software sob teste com a emissão de
comandos, registrando as ocorrências e analisando resultados;
realizam inicialização, reações a determinadas situações, etc.), si-
muladores (simulam reações do mundo real no ambiente de tes-
te), robôs de teste (ferramentais que capturam e retornam dados
simulando com o click de mouse ou com teclados). Esses testes
precisam ser bem planejados para realizarem a cobertura neces-
sária dos casos importantes sem, no entanto, chegarem a um nú-
mero muito elevado de testes. Vale comentar que há ferramentas
que criam automaticamente os casos de testes, por exemplo o
Proteum desenvolvido pelo ICMC da Universidade de São Paulo
campus São Carlos (DELAMARO; MALDONADO; JINO, 2007).
•• Ferramentas para testes não funcionais – tipicamente teste de

carga e desempenho. Isso é feito simulando um número alto de
usuários, acessos simultâneos em banco de dados, entre outros.
6.2 Integração contínua (IC)
A integração contínua (IC) é uma forma de realizar a integração e os

testes de software para incorporar novas características. Integração de
software é a prática de ligar subsistemas ou componentes de software
para produzir um único sistema unificado. A integração de software é
feita no ciclo de vida tradicional como uma fase independente depois
que o software é implementado. A integração contínua é uma práti-
ca proposta em 1997 como uma das principais práticas do Extreme
Programming (XP), com as seguintes etapas: planejamento do jogo,
pequena versão, metáfora, projeto simples e teste. Isso significa basi-
camente que cada desenvolvedor integra seu próprio trabalho continua-
mente (minimamente uma vez por dia). Esta prática garante que peque-
nas partes são adicionadas imediatamente uma vez implementadas e
ficam prontas para fazer parte do sistema antes de se tornarem compli-
cadas (FOWLER, 2006; HAMDANA; ALRAMOUNI, 2015).
Ferramentas de automação de integração contínua permitem a in-

corporação de novas funcionalidades automaticamente. O desenvolve-
dor codifica a nova funcionalidade e o testador codifica os testes dessa
nova funcionalidade, e esses dois elementos são incorporados fazendo
automaticamente a integração contínua.
Neste capítulo você aprendeu sobre a importância dos testes como
ferramenta para verificação e validação de software. Esta atividade tor-
nou-se uma oportunidade de negócio para empresas se especializarem
na realização de testes. Foram vistos aspectos conceituais sobre os
testes, a maneira como os testes se incorporam ao ciclo de vida de
software e como eles podem ser classificados. Além disso, foi dado um
exemplo de um processo de testes e apresentados os ambientes e as
ferramentas para a realização de testes.
Referências
ANDERSIN, Jari. TPI: a model for test process improvement. Seminar on qual-
ity models for software engineering. Department of Computer Science of
University of Helsinki. Helsinki, 2004.

BASTOS, Anderson; RIOS, Emerson; CRISTALLI, Ricardo; MOREIRA, Trayahú.
Base de conhecimento em testes de software. 2. ed. São Paulo: Martins
Fontes, 2007.
BOEHM, Barry; ROMBACH, Hans Dieter; ZELKOWITZ, Marvin V. Foundations of

empirical software engineering: the legacy of Victor Basili. Heidelberg: Springel-
Verlag, 2005.
DAVIS, A. M.; BERSOFF, E. H.; COMER, E. R. A strategy for comparing alternative

software development life cycle models. IEEE Software, v. 14, n. 10, out. 1988.
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução aos testes de sof-

tware. São Paulo: Elsevier, 2007.
ERICSON, Thomas; SUBOTIC, Anders; URSING, Stig. A test improvement model.

Software testing verification and reliability, n. 7, issue 4, p. 229-246, 1998.
FOWLER, M. Continuous integration, 2006. Disponível em: <http://martinfowler.

com/articles/continuousIntegration.html>. Acesso em: 5 jun. 2016.
HAMDANA, S.; ALRAMOUNI, S. A quality framework for software continuous

integration. In: 6TH INTERNATIONAL CONFERENCE ON APPLIED HUMAN
FACTORS AND ERGONOMICS, 2015.
KOOMEN, Tim; POL, Martin. Test process improvement: a practical step-by-

step guide to structured testing. New York: ACM Press Books, 1999.
KULKARNI, Shrini. Test process maturity models: yesterday, today and tomor-
row. 6TH ANNUAL INTERNATIONAL SOFTWARE TESTING CONFERENCE.
Proceedings New Delhi, mar. 2006.
MOREIRA FILHO, Trayahú R.; RIOS, Emerson. Projeto & Engenharia de Software:
teste de software. Rio de Janeiro: Alta Books, 2003.
MUSA, J. D.; IANINI, A.; OKUMOTO, K. Software reliability: measurement, predic-

tion, applications. New York: McGraw-Hill, 1987.
MYERS, G. J.; Badgett, T.; Thomas, T. M. The art of software testing. Hoboken:
John Wiley & Sons, 2012.
PATTON, R. Software testing. Indianapolis: Sams Publishing, 2001.
PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, méto-
dos e padrões. 2. ed. Rio de Janeiro: LTC, 2003.
SPILNER, A.; LINZ, T.; SCHAEFER, H. Software testing foundations. Santa

Barbara: Rocky Nook, 2007.
SWINKELS, RON. A comparison of TMM and other test process improvement

models. Frits Philips Institute, nov. 2000.
TONINI, A. C. Organização das operações testes independentes de software:

um modelo conceitual. Tese de doutorado – Escola Politécnica da Universidade
de São Paulo, São Paulo, 2012.
TRUYTS, C. F. et al. Steps for requirements writing, v. 10, n. 2, dez. 2012.

Disponível em: <http://doi.editoracubo.com.br/10.4322/pmd.2013.005>.
Acesso em: 5 jun. 2016.

Capítulo 7
Gestão da qualidade
Esta aula tem por objetivo discutir o tema gestão da qualidade de

software para apresentar o modo de executar e controlar atividades da
qualidade a fim de que o software desenvolvido seja de qualidade.
•• Conceitos da qualidade.
•• Planejamento da qualidade.
•• Controle da qualidade.
•• Gestão da qualidade.
•• Garantia da qualidade.
1
1 Definições da qualidade
No capítulo 1 foi apresentada uma definição de qualidade de softwa-
re baseada na ideia de que, se eu tenho um bom processo para realizar
o desenvolvimento, é possível construir um software com qualidade.
Neste capítulo será abordada uma questão um pouco mais abrangen-
te, a gestão da qualidade de software. Para tanto é importante lembrar
que a qualidade está ligada ao usuário, à utilização do software: esta é
a meta final. Dessa forma serão apresentadas algumas definições da
qualidade consagradas pelos especialistas em qualidade (não em sof-
tware) para depois trazer esses conceitos para qualidade de software.
1.1 Qualidade
O termo qualidade pode apresentar vários significados:
Quadro 1 – Definições de qualidade
É a adequação ao uso (JURAN; GODFREY, 1999)
É um produto mais econômico, mais útil e que sempre satisfaz ao consumidor

(ISHIKAWA, 1984)
Existem catorze pontos para gestão da qualidade nos quais a qualidade é um processo
de melhoria contínua (DEMING, 1986)
QUALIDADE
É “defeito zero” e define qualidade como sendo conformidade com os requisitos

(CROSBY, 1979, 1984)
É um conceito complexo, que possui facetas; foram identificadas diversas visões da

qualidade, baseadas em aspectos filosóficos, econômicos, de marketing e de gerência
operacional (GARVIN, 1992)
Fonte: adaptado de Spinola (2008).

Pode-se observar que o conceito da qualidade é muito abrangen-
te, portanto, realizar a gestão da qualidade é uma atividade complexa.
Existem definições que levam em conta outros quesitos:
•• Qualidade transcendental (filosofia): sinônimo de excelência

inata. Reconhecida apenas por intermédio da experiência.
•• Qualidade baseada no produto: a qualidade é uma variável preci-

sa e mensurável.
•• Qualidade baseada no usuário: a qualidade reside nos olhos do

observador. Pressupõe uma certa subjetividade, dependendo da
visão específica:
a. Marketing: combinações precisas de atributos do produto que

fornecem a maior satisfação para um determinado usuário.
b. Economia: as diferenças de qualidade são capturadas por va-

riações na curva de demanda.
c. Gerência de operação: adequação ao uso.
•• Qualidade baseada na manufatura: identifica qualidade com

conformidade e com os requisitos, buscando a excelência (fazer
certo na primeira vez). Os enfoques básicos são o de projeto (con-
fiabilidade) e de produção (controle estatístico da qualidade).
•• Qualidade baseada em valor: define qualidade em termos de

custos e preços. Um produto de qualidade provê desempenho
com um preço aceitável ou conformidade com custo aceitável.
Este enfoque tem prevalecido entre os usuários.
Gestão da qualidade 3
2 A dinâmica da qualidade
As empresas mais estruturadas possuem uma equipe da qualida-
de que desenvolve programas específicos, como o estabelecimento de
metas da qualidade, e definem projetos da qualidade. Esses projetos ge-
ralmente visam o estabelecimento de melhorias no processo existente
e de programas de treinamento para conscientização para a qualidade,
desenvolvem métodos de verificação e validação e realizam o controle
e a gestão da qualidade. Tudo isso com o objetivo de melhorar a quali-
dade dos produtos e serviços oferecidos pela empresa.
Empresas menores não têm como possuir uma equipe que se dedi-
que integralmente à realização de programas da qualidade. No entanto,
exatamente as mesmas funções podem ser realizadas com pessoas
em tempo parcial dedicadas à definição e à melhoria de programas da
qualidade. Deve-se lembrar também que, com menos pessoas, é mais
fácil estruturar e desenvolver programas da qualidade.
A qualidade deve ser controlada para garantir que os produtos de-

senvolvidos, ou os serviços realizados, tenham a qualidade adequada.
É necessário, entretanto, que isso seja feito na medida certa: os custos
das atividades ligadas à qualidade não podem ser muito altos para não
prejudicarem o valor do produto ou o tempo para entregá-lo; o tempo
também não pode ser abaixo do necessário, já que isso pode fazer com
que um produto seja entregue com defeitos que prejudicam o seu de-
sempenho. Esses são os denominados custos da qualidade.
Para o desenvolvimento das atividades referentes à qualidade, a

figura 1 apresenta o diagrama da trilogia de Juran. Esse diagrama
mostra o inter-relacionamento entre os processos de planejamento da
qualidade, o controle da qualidade e a melhoria da qualidade (JURAN;
GODFREY, 1999).

Figura 1 – Diagrama da trilogia de Juran
Planejamento
da qualidade Controle da qualidade (operação)
Melhoria da qualidade
Spike
40 esporádico
Custo da má qualidade
Faixa de controle original
20
Controle da qualidade
Novo nível de
Desperdício crônico controle da
qualidade
0 Tempo
Lições aprendidas
Fonte: Juran e Godfrey (1999, p. 27).
O controle da qualidade (durante a operação) consegue realizar

a medição e o controle dos custos existentes devido à má qualidade.
Como exemplo desses custos podem ser citadas peças fabricadas com
defeito ou retrabalho em um código já desenvolvido com erro.
O planejamento da qualidade estabelece uma nova meta para os

custos da qualidade e define um Projeto de melhoria da qualidade. Uma
vez implantadas as ações de melhoria, a empresa evolui para um novo
patamar da qualidade com custos menores.
2.2 Histórico da qualidade
A evolução histórica da qualidade está representada na figura 2.

Qualidade, como função gerencial, surgiu na década de 1920 com o
aparecimento da produção em massa, representada pela fabricação
do automóvel Ford modelo T. Nessa época, o controle da qualidade
era realizado por meio da inspeção de 100% dos itens fabricados
(SPINOLA, 2008).
Figura 2 – Histórico da qualidade
Gestão da qualidade total

(TQM)
Controle da qualidade total

(TQC) Anos 1950
Controle estatístico de
processos (CEP) Anos 1930/1940
Inspeção
100% Anos 1920
Na década de 1930 e 1940 foi introduzido o controle estatístico de

processos (CEP) que permitiu abandonar a inspeção 100% e realizá-la
por amostragem (uma parcela do lote escolhida por critérios estatísti-
cos) para aprovar ou não o lote fabricado. Começava a era do controle
de processo usando critérios quantitativos com cálculos e gráficos de
controle (SPINOLA, 2008).
Nos anos 1950 surgiu o conceito de garantia da qualidade, e os cus-

tos da qualidade preventiva e corretiva começam a ser medidos. O cus-
to da qualidade preventiva refere-se ao custo para realizar os controles e
as inspeções da qualidade, já o custo da qualidade corretiva refere-se ao
custo incorrido devido ao retrabalho para corrigir os defeitos. A partir de
então desenvolveu-se o controle da qualidade total (total quality control
– TQC), que envolvia os diversos processos e pessoas com a preocupa-
ção de aumentar a confiabilidade (SPINOLA, 2008).
Finalmente veio o conceito de gestão da qualidade total (total qua-

lity management – TQM), em que se estabelece a visão estratégica da

qualidade no contexto atual de mercado complexo e de alta competição
(SPINOLA, 2008).
IMPORTANTE
• TQM é uma forma de gerenciar uma empresa ou outra organização

que concentra seus esforços de forma sistemática e disciplinada
na melhoria contínua da qualidade de tudo que faz (MAIN, 1995).
• TQM é o nome dado para a estratégia multidimensional dirigida

para tornar a empresa capaz de competir em qualidade e através
da qualidade (CONTI, 1993).
O TQM realiza a gestão estratégica da qualidade, estabelecendo

um sistema de melhoria contínua com base na busca de satisfação do
cliente e na análise do posicionamento da empresa no mercado. Ele é
um processo de melhoria a curto, médio e longo prazo (SPINOLA, 2008).
Com essas definições, pode-se observar que o conceito da qualida-

de evoluiu da simples atividade de realizar testes e inspeções para se
tornar uma forma de pensar, uma estratégia de abordagem empresarial.
2.3 Qualidade de software
Com essas definições em mente, como entender a qualidade de sof-

tware e a gestão da qualidade de software? Pressman (2002) assim
definiu a qualidade de software como 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 definido.
Esta definição tem o mérito de considerar, além dos requisitos explí-
citos, a adequação aos requisitos implícitos. Reconhece a necessidade
de o software possuir requisitos que nem sempre são declarados, mas
são necessários. No entanto, ainda não representa um conceito geral de
qualidade de software.
Weinberg (1993) desenvolveu um estudo avaliando a qualidade do

ponto de vista das pessoas, conforme apresentado no quadro 2.
Quadro 2 – As pessoas por trás das definições de qualidade
QUEM É A PESSOA POR TRÁS DESSA DEFINIÇÃO DE QUALIDADE?
• Para os usuários cujo trabalho é afetado pelos defeitos.

Defeito zero
• Para os gerentes que são criticados pelos defeitos.
• Para os usuários cujo trabalho pode tirar proveito dessas funções –

Ter um grande número
se eles as conhecerem.
de funções
• Para os distribuidores que acreditam que as funções vendem produtos.
• Para o pessoal de desenvolvimento que dá um grande valor às opiniões

Codificação elegante de seus colegas.
• Para os professores de ciência da computação que apreciam elegância.
• Para os usuários cujo trabalho sobrecarrega a capacidade de suas máquinas.

Alto desempenho
• Para o pessoal de venda que tem de submeter seus produtos a benchmarks.
Baixo custo de • Para os usuários que desejam comprar milhares de cópias do software.
desenvolvimento • Para os gerentes de projeto que estão com orçamentos apertados.
• Para os usuários cujo trabalho está esperando pelo software.

Desenvolvimento
rápido • Para os distribuidores que desejam colonizar um mercado antes
de seus concorrentes.
• Para os usuários que gastam oito horas por dia na frente de uma tela utilizando
Facilidade para o
o software.
usuário
• Para os usuários que não conseguem se lembrar de detalhes de interface.
Fonte: adaptado de Weinberg (1993, p. 6).
Weinberg (1993) mostra que diferentes pessoas podem ter per-

cepções diferentes em relação à qualidade de um mesmo produto de

software. Ele levantou algumas definições potenciais para alta qualida-
de de software e identificou os tipos de pessoas que podem estar por
trás de cada uma delas.
Kitchenham e Pfleeger (1996) mostram que o contexto e a aplicação

também reforçam a relatividade do conceito de qualidade, e exempli-
ficam: “Erros tolerados em um software processador de texto podem
não ser aceitáveis em um software para controle de uma planta nuclear”
(KITCHENHAM; PFLEEGER, 1996, p. 12).
O debate sobre a qualidade de software ainda apresenta muitos si-

nais de imaturidade, se comparado com outras áreas produtivas. Um
dos indicadores disso é o fato de a terminologia utilizada não estar ain-
da consolidada e devidamente compreendida. Tervonen (1996) discute
este problema:
A maioria dos engenheiros de software concordam que há uma

variedade muito grande de termos da qualidade. Modelos de quali-
dade, tais como Software Quality Metrics e Goal Question Metric, e
padrões, tais como IEEE Quality Metrics Methodology e ISO 9126,
fornecem uma terminologia da qualidade, mas eles tendem a ser
rígidos e abstratos demais, e naturalmente não podem garantir que
sua terminologia será aprendida e usada. Ignorância em relação a
termos da qualidade podem levar a:
- uso insuficiente de estimativas de qualidade quando avaliando

alternativas e
- uso inconsistente dos termos da qualidade por projetistas e ins-

petores. (TERVONEN, 1996, p. 51)
A TQM em empresas de desenvolvimento de software possui o mes-

mo significado que nas empresas de manufatura e de serviços. Tendo
como pontos de apoio – estratégicos – a busca da satisfação do clien-
te, o posicionamento consciente em relação ao mercado e a melhoria
contínua, desdobram-se a política e os objetivos da organização. Esses
objetivos são continuamente reavaliados e aperfeiçoados. A partir des-
ses objetivos, articulam-se as diversas ações necessárias para atingi-
-los e sincronizam-se as atividades nos diversos níveis, desde a alta di-
reção até cada um dos postos de trabalho (SPINOLA, 2008).
Na gerência dos seus processos a empresa que produz software ne-

cessita mover-se na direção da prevenção de defeitos (DUNN; ULLMAN,
1994; SPINOLA; PESSÔA, 1997), em oposição à antiga postura de detec-
ção e remoção de defeitos, que via a qualidade como função da inspe-
ção final (testes) dos programas.
A melhoria de cada um dos processos pode ser obtida aplicando-se

o ciclo Planeje/ Faça/ Verifique/ Aja (Plan/ Do/ Check/ Act – PDCA),
também conhecido como ciclo de Deming (GALGANO, 1993). No nível
operacional, o PDCA constitui um método eficiente e direcionado para a
resolução dinâmica dos problemas (SPINOLA, 2008).
A busca de alta qualidade em software tem sido realizada por meio

de dois tratamentos principais (DROMEY, 1996; HUMPHREY, 1995):
•• Gerência do processo: que considera a necessidade de esta-

belecer um processo de qualidade para produzir produtos de
qualidade.
•• Gerência do produto: que busca identificar as características tan-

gíveis dos produtos a serem desenvolvidos, estabelecendo a par-
tir delas diretrizes para o processo de desenvolvimento.
Essas duas visões são complementares e diversos casos têm de-

monstrado que levam a resultados de melhoria. A empresa AT&T,
por exemplo, focalizou a melhoria de seus produtos, enquanto que a
Motorola utilizou a melhoria de processos (SMITH; BELLEFEUILLE, 1993;
KITCHENHAM; PFLEEGER, 1996; SANDERS, 1997; SPINOLA, 2008). Em
ambas visões é crescente o tratamento objetivo da gerência, com o uso
de métricas de processo e de produto (SPINOLA, 2008).

A discussão processo versus produto de software, fortemente presen-
te na literatura de engenharia de software, contribui para serem identifica-
das as vantagens e desvantagens de cada um dos tratamentos e concluir
que um deles por si só não preenche todas as necessidades de melhoria
no desenvolvimento de software (DROMEY, 1996; SANDERS, 1997).
Dessa forma, podemos concluir que um processo organizado de de-

senvolvimento leva à construção de um produto de qualidade. Um bom
processo leva a um bom produto.
3 Planejamento da qualidade
A qualidade pode e deve ser planejada. Como clientes, todos ficamos
desanimados, para não dizer pior, quando um voo se atrasa, um trata-
mento médico não é feito da melhor maneira, um brinquedo deixa de
funcionar, um eletrodoméstico quebra, um software é lento ou é difícil
de usar. Essas falhas frequentes são, na verdade, lacunas da qualidade
e necessitam de planejamento e ações para serem eliminadas (JURAN;
GODFREY, 1999).
O planejamento da qualidade é o primeiro dos três processos da tri-

logia de Juran (ver figura 1); neste processo devem ser planejadas as
ações para o controle e a melhoria da qualidade na empresa.
No âmbito de um projeto específico, as atividades da qualidade pre-

cisam ser inseridas junto com as atividades do projeto como um todo.
Conforme já visto nos capítulos anteriores, estas são atividades como
verificações, testes e validações.
3.1 Medição do processo
Retornando ao diagrama da trilogia de Juran (figura 1), para se fazer

um bom planejamento da qualidade é necessário ter números para se
saber “a quantas andamos”. Uma forma muito simples de fazer isso é
por intermédio da classificação das atividades desenvolvidas no projeto.
Todas as pessoas envolvidas com o projeto devem realizar apontamento
de horas, registrando quanto tempo foi gasto nas atividades do projeto.
As atividades desenvolvidas no projeto podem ser agrupadas em al-

guns poucos tipos:
•• Atividades do projeto propriamente dito: programação, levanta-

mento de requisitos, concepção da arquitetura do software, do-
cumentação, etc.
•• Atividades de gestão de projeto: elaboração de cronograma, reu-

niões de acompanhamento.
•• Atividades de controle da qualidade: leitura e aprovação de docu-

mentos técnicos, como especificação e testes de software.
•• Retrabalho (custos devido à má qualidade): correção de erros no

programa.
IMPORTANTE
Geralmente a equipe da qualidade obtém indicadores como:
• 10% das horas do projeto são para gestão de projeto.
• 25% das horas do projeto são para atividades de controle da qua-

lidade.
• 15% das horas do projeto são para atividades de retrabalho.
Pensando em termos de custo, as atividades que agregam valor são

aquelas que estão ligadas à construção do produto. As atividades de
gestão de projeto e controle da qualidade são, na verdade, um mal ne-
cessário, mas não agregam valor diretamente. Evidentemente, sem elas

há o risco de se ter mais retrabalho, o que é desastroso! Portanto, as
atividades de controle da qualidade e gestão do projeto devem ser reali-
zadas com o menor custo possível, mas nunca eliminadas.
Assim, o controle da qualidade dentro de um projeto é realizado a

partir de dados históricos de projetos anteriores. Com esses dados é
possível serem estabelecidas as metas para o controle da qualidade
deste projeto, como o número de horas previstas para a gestão de pro-
jeto, o controle da qualidade (horas de verificações e testes) e as horas
de retrabalho.
De maneira geral, a melhoria da qualidade é realizada com o objetivo

de atender a todos os projetos da empresa, e é um esforço para a em-
presa como um todo e não somente dentro de um projeto específico.
4 Controle da qualidade
Controle de qualidade é um processo gerencial universal para a rea-
lização de operações de modo a proporcionar estabilidade, evitar a mu-
dança adversa e manter o status quo. Para manter a estabilidade, o con-
trole da qualidade avalia o desempenho real, compara com as metas e
toma ações sobre a diferença (JURAN; GODFREY, 1999).
O controle da qualidade é um dos três processos gerenciais básicos

por meio do qual a qualidade pode ser gerenciada. Os outros são o pla-
nejamento da qualidade e a melhoria da qualidade.
Na figura 1 (diagrama da trilogia de Juran), pode-se entender que o

controle da qualidade consiste em fazer com que a qualidade do proje-
to fique dentro da faixa cinza marcada como zona original de controle
da qualidade. As linhas em preto dentro dessa faixa são as medidas
realizadas durante a operação. Pode-se dizer que o processo está sob
controle enquanto as medidas ficarem dentro da faixa cinza. No diagra-
ma há uma medida que ficou fora marcada como um spike esporádico,
que pode ter sido causado por uma falha eventual, mas uma só medi-
ção fora da faixa não significa que foi perdido o controle do processo.
Em outras palavras, o controle da qualidade é uma atividade inserida

no dia a dia da empresa para verificar se tudo está sob controle. Com
o acompanhamento das medições do processo, podem ser realizadas
comparações com projetos anteriores para verificar se este projeto está
dentro do nível da qualidade esperado.
Por exemplo, quando são realizados os testes de software, é reali-

zado o registro do número de defeitos encontrados nesta atividade de
verificação. Vale entender aqui que o programador escreve o código e
realiza testes para saber se está bom ou não. Esses testes não são con-
siderados como atividade de verificação, mas sim de desenvolvimento.
No momento em que o programador considerar que está “pronto”, o có-
digo é entregue para a área de testes, ou para outro profissional realizar
os testes seguindo o roteiro de testes planejado (conforme explanado
no capítulo de testes). Os resultados desses testes é que são considera-
dos como atividade de verificação e precisam ser controlados, registra-
dos em uma planilha ou gráfico de controle e estar dentro de uma faixa
predeterminada. Um número muito acima do que é considerado ade-
quado significa que o código desenvolvido está fora dos padrões espe-
rados. A causa precisa ser examinada para se tomar ações corretivas.
5 Melhoria e garantia da qualidade

A melhoria da qualidade tem por objetivo reduzir defeitos que são
crônicos e deve definir ações para alguns itens, tais como aumentar
a taxa de sucesso de um produto fabricado, reduzir o número de er-
ros em atividades administrativas ou as falhas após a entrega (JURAN;
GODFREY, 1999). Conforme ilustrado na trilogia de Juran (figura 1), a
melhoria de processos visa mudar a empresa de patamar. A maneira
com que devem ser desenvolvidas as atividades de melhoria de proces-
sos será focada no próximo capítulo.

A garantia da qualidade é outra atividade importante no contexto da
gestão da qualidade. Ela visa fiscalizar se as atividades da qualidade
estão sendo realizadas adequadamente. Se os resultados estiverem
corretos significa que a empresa vai entregar seus produtos ou servi-
ços dentro do esperado. Por exemplo, uma manufatura que adquire um
insumo com qualidade garantida não precisa realizar inspeção de rece-
bimento, pois o fornecedor garante que não há defeito.
Mas qual a diferença entre o controle da qualidade e a garantia da

qualidade? Eles têm muito em comum, pois ambos avaliam o desem-
penho, comparam o desempenho com as metas e agem na diferença.
No entanto, eles também diferem entre si: o controle da qualidade tem
como objetivo principal manter o controle; o desempenho é avaliado
durante as operações e, depois, comparado com as metas durante as
operações. As informações resultantes são recebidas e usadas interna-
mente (JURAN; GODFREY, 1999). Já a principal finalidade da garantia
da qualidade é verificar se o controle está sendo mantido. O desem-
penho é avaliado após as operações, e a informação resultante é for-
necida internamente a outros que têm necessidade em sabê-la. Esses
outros podem incluir outras áreas da empresa, gerência sênior, equipes
corporativas, órgãos reguladores, clientes e público em geral (JURAN;
GODFREY, 1999).
6 Garantia da qualidade para software

As definições descritas anteriormente são conceitos estabelecidos
pelos especialistas em qualidade. Na área de software, esses conceitos
foram adaptados, particularmente com o surgimento do modelo CMMI.
Os termos utilizados em software são verificação, validação e garantia
da qualidade de software (software quality assurance – SQA).
O CMMI possui um processo de verificação, um processo de valida-

ção e um processo de garantia da qualidade. Os dois primeiros já foram
discutidos no capítulo 5. Nesse modelo, o processo é denominado
PPQA (process and product quality assurance, ou garantia da qualidade
de processo e produto) (CMMI, 2010).
O PPQA tem como objetivo fornecer visibilidade para a equipe e a

gerência sobre os processos e produtos de trabalho associados (CMMI,
2010). Esse processo possui duas metas:
•• SG11: avaliar objetivamente processos e produtos de trabalho.
•• SG2: fornecer visibilidade.
6.1 Avaliar objetivamente processos e produtos de trabalho
A aderência dos processos executados e dos produtos de trabalho

e serviços associados é objetivamente avaliada em relação à descrição
de processos, padrões e procedimentos aplicáveis (CMMI, 2010). Isso
significa que a equipe da qualidade vai verificar se o processo está sen-
do seguido e se todas as etapas previstas foram cumpridas.
Observe que esta é uma atividade de verificação de processo. Não

é verificar se existem erros no projeto do produto, mas sim se todos os
passos para realizá-lo foram seguidos. O que é verificado no produto
são os itens de processo. Por exemplo, se é para entregar para o cliente
a memória de cálculo, é verificado se existe uma memória de cálculo
nos documentos a serem entregues, se foi aprovado, se foi verificado,
se está no formulário correto.
O PPQA emite um relatório apresentando o que foi encontrado. Se

não houver nenhum desvio, o relatório é entregue e os produtos de tra-
balho seguem seu fluxo normal. Se existirem erros, eles são apontados
no relatório.
1 SG é specific goal, ou meta específica.

6.2 Fornecer visibilidade
Questões críticas relativas a não conformidades são monitoradas e

comunicadas objetivamente, e sua solução é assegurada (CMMI, 2010).
As não conformidades, ou desvios encontrados, são informados à

área responsável que deverá providenciar as devidas correções. A área
de PPQA deverá acompanhar essas correções até o fechamento.
O PPQA deve também elaborar registros dessas avaliações para for-

necer visibilidade sobre o andamento das atividades, tais como o status
das ações corretivas e os relatórios de tendências da qualidade.
Nesta aula foi apresentada uma visão geral da qualidade, incluindo
seu histórico. Identificamos que a qualidade nasceu como uma neces-
sidade da indústria na fabricação de produtos em grande quantidade.
Esses conceitos evoluíram e foram trazidos para as demais atividades
humanas, particularmente para a área de software. A qualidade precisa
ser planejada e controlada.
Referências
CONTI, T. Building total quality: a guide for management. London: Chapman &
Hall, 1993.
CROSBY, P. B. Qualidade é investimento. Rio de Janeiro: José Olympio, 1979.
______. The art of hassle-free management. New York: McGraw-Hill, 1984.
DEMING, W.E. Out of the crisis. Cambridge: Cambridge University Press, 1986.
DROMEY, R. G. Cornering the chimera. IEEE Software, v. 13, n. 1, p. 33-43, 1996.
DUNN, R. H.; ULLMAN, R. S. TQM for computer software. 2. ed. New York:
McGraw-Hill, 1994. (McGraw-Hill System Design and Implementation Series).
GALGANO, A. Calidad total: clave estratégica para la competitividad de la em-

presa. Ciudad de México: Diaz de Santos, 1993.
GARVIN, D.A Gerenciando a qualidade: a visão estratégica e competitiva. Rio de

Janeiro: Qualitymark, 1992.
HUMPHREY, W. S. A discipline for software engineering. Salt Lake City:

ISHIKAWA, K. TQC-Total quality control: estratégia e administração da qualida-

de. São Paulo: IMC International, 1984.
JURAN, J. M.; GODFREY A. B. Juran´s quality handbook. New York: McGraw-

Hill, 1999.
KITCHENHAM, B.; PFLEEGER, S. L. Software quality: the elusive target. IEEE

Software, v. 13, n. 1, p. 12-21, 1996.
MAIN, J. Guerras pela qualidade: os sucessos e fracassos da revolução da qua-

lidade. Rio de Janeiro: Campus, 1995.
SANDERS, J. Product, not process: a parable. IEEE Software. Mar 1997, p.6-8.
SMITH, B.; BELLEFEUILLE, J. Making war on defects. IEEE Spectrum, p. 43-50,

1993.
SPINOLA, M. M.; PESSÔA, M. S. P. Produtos que embutem software: aspectos

relevantes para a melhoria do processo de desenvolvimento. In: XI SIMPÓSIO
BRASILEIRO DE ENGENHARIA DE SOFTWARE. Anais WQS’97. Fortaleza: UFC,
1997.
SPINOLA, M. M. Processo de produção de software: da produção à gerência.

Tese de livre docência – Escola Politécnica da Universidade de São Paulo, São
Paulo, 2008.

TERVONEN, I. Support for quality-based design and inspection. IEEE Software,
v. 13, n. 1, p. 44-54, 1996.
WEINBERG, G. M. Software com qualidade: pensando e idealizando sistemas.

São Paulo: Makron, 1993.
Capítulo 8
Melhoria contínua
do processo
Esta aula tem por objetivo discutir o tema melhoria contínua de

processo. Para tanto serão apresentadas algumas ferramentas que po-
dem ser utilizadas para diagnosticar e melhorar o processo de software,
como o CMMI ou a NBR ISO 29110.
Nos ciclos de melhoria de processo, é importante a realização de me-

dições para se saber objetivamente qual foi a profundidade da melhoria.
É importante também envolver as pessoas nos processos de melhoria,
uma vez que a natureza da atividade de desenvolvimento de software
é intensiva em mão de obra e somente pessoas motivadas, treinadas e
qualificadas poderão realizar melhoria de processo.
1
1 A melhoria de processo na trilogia de Juran
Conforme discutido no capítulo anterior, de gestão da qualidade,
Juran e Godfrey (1999) apresentaram a trilogia que relaciona o planeja-
mento, o controle e a melhoria de processo. Neste capítulo será aborda-
do o processo de melhoria contínua.
A melhoria de processo funciona como um sistema de controle no

qual é feita a comparação entre o que é esperado que seja feito e o que
realmente é feito (figura 1). A divergência encontrada leva à necessi-
dade de um ajuste de desempenho. Para isso é necessário que seja
conhecida a capacidade do processo, sejam utilizadas ferramentas
adequadas, que se tenha conhecimento e perfil para realizar as mudan-
ças necessárias e que haja autoridade para executar essas mudanças
(JURAN; GODFREY, 1999).
Figura 1 – Sistema de controle
O que é esperado
que seja feito
O que realmente
Ajuste de desempenho: é feito
- Capacidade de processo
- Ferramentas
- Conhecimento, perfil
- Autoridade
Fonte: adaptado de Juran e Godfrey (1999).

2 Medições do processo e do produto
Medição tem sido a base do progresso da ciência e da engenharia e
precisa ser também utilizada em software (JONES, 1991). As medições
do processo e do produto têm por objetivo dar visibilidade ao projeto.
•• Medições do processo são aquelas que permitem identificar as
atividades relacionadas à construção do software, por exemplo, o
número de horas de trabalho necessárias para realizar um levan-
tamento de requisitos ou a escrita de um código.
•• Medições de produto são aquelas referentes ao produto que está
sendo construído, por exemplo, o número de erros encontrados
na fase de testes ou pós-entrega nos seis primeiros meses de
uso no cliente. Outros exemplos são o número de cliques para
realizar uma determinada função e a complexidade ciclomática
de McCabe que mede a complexidade da estrutura de algoritmos
do código fonte (JONES, 1991).
Na fase de planejamento do projeto é realizado outro tipo de medi-

ção: as estimativas. As estimativas são importantes para se determinar
o porte do projeto e planejar custo e esforço (qual é o tamanho da encren-
ca!). Durante o andamento do projeto, as medições permitem verificar
se o que foi planejado está sendo cumprido e se o produto está saindo
de acordo com as expectativas.
As seções a seguir estão organizadas em GQM, PSM e processo de
medição.
2.1 GQM
Uma sistemática de medições do processo de software é denomina-

da Goal question metrics (GQM), desenvolvida por Basili. A abordagem
do GQM fornece um método para uma organização ou um projeto de-
finirem metas, refinarem essas metas em especificações de dados a
serem coletados e, em seguida, analisarem e interpretarem os dados
resultantes à luz dos objetivos originais (BASILI et al., 2010).
Melhoria contínua do processo 3

O método identifica as metas (goals) e realiza perguntas (questions)
que são respondidas com as medições a serem feitas. Pode-se obser-
var, por exemplo, que o ponto de partidas são os elementos de estraté-
gia em diferentes níveis na organização (nível do negócio, nível do sof-
tware e nível do projeto).
Tomando-se por exemplo a meta 2 “entregar 5% de novas funciona-

lidades a cada 6 meses com 10% do orçamento”, pode-se observar que
ela se desdobra na meta 2 do GQM: “avaliar o crescimento funcional em
cada release”.
Figura 2 – GQM (Goal Question Metrics – Metas Questões Métricas)
Nível do projeto Nível do software Nível do negócio

+ Elementos
Meta 1: aumentar a margem Meta 2: entregar 5% de novas Meta 3: aplicar MoSCoW e

estratégicos
de lucro com o uso de serviço funcionalidades a cada 6 Cocomo de maneira eficaz

de software meses com 10% do orçamento
Estratégia 3: conduzir
Estratégia 1: entregar as Estratégia 2: usar MoSCoW treinamentos, determinar
GQM metas GQM
funcionalidades adicionais e Cocomo ferramentas, realizar estudos piloto
G1: analisar a tendência G2: avaliar o crescimento G3: avaliar a eficácia do

do lucro de cada versão MoSCoW e do Cocomo
Q1: qual é a Q2 – qual é Q3: quantos Q4: qual o Q5: qual a Q6: quão Q7: qual o
Questões
margem de a margem de requisitos período precisão da abrangente foi custo do

lucro atual? lucro para o M estão em entre as estimativa o treinamento? treinamento?
ano 2 e para cada versão? versões? de custo?
o ano 3?
P0: margem Px: margem MR: número RD: release BV: budget NT: número TC: horas de
Métricas
de lucro de lucro anual de requisitos duration – variance – de pessoas treinamento

anual corrente para o ano x implementados duração das variação do treinadas
solicitados pelo versões orçamento
cliente (M)
interpretação
Se P2> 1.1 • P0 e
Modelo de
P3> 1.1 • P2
e… … …
então a meta
é satisfeita
Fonte: Adaptado de Basili et al. (2010, p. 60).

As perguntas ligadas a esta meta são “Q3: quantos requisitos do
tipo M (must – mandatórios) existem em cada release?” e “Q4: quanto
tempo decorre entra cada release?”. Destas perguntas se desdobram as
medições: “MR: número de requisitos do tipo M solicitados pelo cliente e
implementados” e “RD: duração do release”.
Finalmente são determinados modelos de interpretação para que se

possa saber se as metas estão sendo atingidas, as razões dos desvios
identificados e que ações devem ser tomadas para a correção.
O ponto forte do GQM é a amarração feita entre todas as medições

realizadas no âmbito do projeto alinhadas com as metas e as estraté-
gias da organização, formando um sistema muito coerente e útil para o
gerenciamento.
2.2 PSM
Practical software and system measurement (PSM) é um método tes-

tado e de eficácia provada para definir e medir o processo de projeto de
software e sistemas. O objetivo do PSM é oferecer aos gerentes e técni-
cos do projeto as informações quantitativas requeridas para a tomada
de decisões que têm impacto no custo, no cronograma e no desempe-
nho do projeto. O PSM foi originalmente criado para o Departamento de
Defesa americano e possui uma comunidade com seminários e treina-
mentos (PSM, 2016).
O PSM possui dois modelos integrados: um de informação e um de

processo (AGUIAR, 2009). O modelo de informação fornece um cami-
nho para a seleção das medidas a serem utilizadas. Como exemplo de
informação pode-se citar um indicador que mede a produtividade da
equipe de software.

Figura 3 – PSM – modelo de informação
Resultado da
Necessidades Produto de execução do
de informação informação plano de medição
Uma ideia sobre

as entidades
que deveriam Definição formal que
ser medidas Conceito Construção especifica o que será
para satisfazer mensurável mensurável medido e como os dados
as necessidades serão combinados
de informação
Propriedade ou
Entidades Atributos característica
de uma entidade
Fonte: Aguiar (2009, p. 10).
No item construção mensurável é feita a definição formal do que

será medido. No caso, a produtividade é uma medida derivada calcula-
da por meio de duas medidas básicas: esforço do projeto e tamanho do
projeto. O esforço do projeto é medido pelas horas gastas para a cons-
trução do software. Já o tamanho do projeto é medido pela contagem
dos pontos de função do projeto. A produtividade é obtida pelo cálcu-
lo produtividade = (pontos de função)/(esforço). Em outras palavras, a
equipe tem uma produtividade de X pontos de função por horas.
As medidas são realizadas por meio de dados históricos dos proje-

tos, e em novos projetos são estimados os pontos de função. Em fun-
ção da produtividade da equipe, é obtido o esforço necessário (número
de horas) para desenvolver o projeto. Durante o andamento do projeto
essa produtividade pode ser acompanhada.
O modelo de processos do PSM estabelece um ciclo de medições,

análise crítica dessas medições e aperfeiçoamento contínuo dos pro-
cessos e técnicas para dar suporte aos profissionais que utilizam as
medições para gerenciamento dos projetos.

2.3 Processo de medição
A construção de um processo de medição é muito importante para

que a empresa possa ter visibilidade de seus processos. As medições
são realizadas no âmbito do projeto e utilizadas pela organização como
um todo para poder conhecer melhor sua capacidade e efetuar melho-
rias de processo.
A implementação de um processo de medição, no entanto, não é

uma tarefa fácil, pois envolve a necessidade de as pessoas se discipli-
narem para registrar os dados e usar as medições para a tomada de de-
cisão. Se não houver a compreensão da importância dessas atividades,
não haverá sucesso. Começar pequeno, com poucas medidas, é uma
boa iniciativa. Há a necessidade também de realizar treinamento para
que se possa obter comprometimento dos envolvidos. A estrutura cria-
da para medições precisa ser simples e de baixo custo. Os indicadores
devem ser comunicados para que todos possam compreender e tomar
as ações necessárias (PSM, 2016; AGUIAR, 2009).
Alguns exemplos de medidas que podem ser feitas no processo de

desenvolvimento de software (AGUIAR, 2009, p. 17):
•• Prazo de progresso do projeto: grau de alcance dos marcos do

projeto; desempenho no caminho crítico do projeto; progresso de
cada unidade de trabalho.
•• Recurso e custo: esforço da equipe (horas trabalhadas); desem-

penho financeiro; nível de experiência da equipe; turn-over no
projeto.
•• Tamanho funcional e estabilidade do produto: número de re-

quisitos; número de mudanças funcionais; número de pontos de
função.

Com essa massa de dados será possível realizar um tratamento es-
tatístico e alguns estudos interessantes, como analisar a influência da
produtividade da equipe em relação à experiência ou mesmo sobre a
qualidade dos produtos gerados.
3 Modelos de referência
O desenvolvimento de melhoria de processo baseada em modelo
(como CMMI, MPS.BR) é um dos caminhos que a empresa pode ado-
tar. É importante que seja definido, antes de qualquer coisa, qual é o
objetivo da empresa: se necessita a melhoria de processo por causa
de problemas em seu processo ou por causa de pressões de mercado
para obter uma certificação. No primeiro caso há a liberdade de realizar
a melhoria utilizando os modelos de processo como referência, usar
parte do modelo e fazer a mistura de mais de um modelo conforme
a conveniência interna. No segundo caso é necessário implementar o
modelo completo para se alcançar a certificação; a dificuldade está em
implementar um processo que faça sentido para a empresa e que real-
mente agregue valor.
Vale lembrar também que uma empresa possuir certificação com

base em um modelo de processo pode ser um diferencial competitivo
se, no mercado em que ela atua, nenhuma ou poucas empresas tive-
rem essa certificação. Por outro lado, em mercados onde é exigida uma
certificação, esta passa a ser um fator qualificador, ou seja, quem não
a tem está fora.
Existem muitos modelos de processo que podem ser usados como

referência. No entanto, vale aqui destacar os mais conhecidos que se-
rão sucintamente descritos aqui: CMMI, MPS.BR e NBR ISO 29110.
Embora não seja para software, vale citar também a NBR ISO 9001,
que é um modelo de processo para se implementar um sistema de ges-
tão da qualidade. A ISO 9001 pode ser aplicada em qualquer atividade,

incluindo software, e tem como ideia central definir um processo para
o desenvolvimento das atividades, medir e melhorar esse processo. Ela
estabelece os mecanismos de controle para fazer isso, porém não será
detalhada aqui por não se tratar de um modelo para software.
3.1 Modelo CMMI
Trata-se de um dos modelos mais antigos de processo. A primei-

ra versão foi publicada em 1987 e hoje a versão válida é o CMMI-DEV
versão 1.3, publicada em novembro de 2010 (CMMI, 2010). O CMMI se
baseia no conceito de maturidade de processo que nada mais é do que
considerar que a organização evolui no tempo e elabora suas atividades
com mais maturidade e com mais qualidade. Essa evolução a caminho
da maturidade é realizada de uma maneira sistemática e controlada.
O foco aqui é a organização que amadurece como um todo e leva os
participantes a desenvolverem seus trabalhos de maneira mais homo-
gênea em toda a organização. Para isso há um programa de conscienti-
zação e de treinamento, de forma que todos estejam alinhados e sigam
o mesmo processo na realização das atividades. Ao mesmo tempo, na
organização há uma equipe de processo que define o processo, mede-o
e o torna melhor.
O CMMI é um modelo americano gerenciado por uma entidade de-

nominada Software Engineering Institute (SEI) e foi desenvolvido com a
finalidade de oferecer qualidade nos projetos de software militares.
O CMMI é uma constelação de três modelos, o CMMI-DEV, o CMMI-

ACQ e o CMMISVC, que visam o desenvolvimento e a aquisição de sof-
tware, além da realização de serviços. Esses três modelos possuem par-
tes comuns e partes específicas. Aqui será apresentado o CMMI-DEV.
O CMMI-DEV está estruturado em processos. São ao todo 22 proces-

sos para implementar o modelo inteiro. Conforme já explicado, o mode-
lo possui níveis de maturidade que devem ser implementados passo a

passo. São ao todo cinco níveis numerados de 2 a 5, já que o primeiro é
considerado o nível inicial de todas as empresas. Cada nível possui um
foco e um conjunto de processos da coleção (CMMI, 2010).
Figura 4 – Modelo CMMI por estágios
Níveis
5
Melhoria contínua
4 Processo gerenciado quantitativamente
3 Processo definido
2 Gerência de projeto
O nível 2 do CMMI tem como foco a gerência de projeto. Para se

chegar ao nível de maturidade 2 é necessário que sejam implementa-
dos sete processos: gerência de requisitos; planejamento de projeto;
monitoramento e controle de projeto; gerência de acordos com fornece-
dores; medições e análises; garantia da qualidade de processo e produ-
to; e gerência de configuração. Isso significa que a empresa que decidir
implementar o CMMI precisará começar por esse nível, implementando
todos esses processos (CMMI, 2010).
O nível 3 do CMMI tem como foco a definição do processo da orga-

nização. Isso significa que a organização possui um processo padrão
para desenvolver softwares e todo e qualquer projeto de software deve
seguir um processo derivado do padrão. Existem regras de customiza-
ção que orientam como se deve, para um projeto específico, selecio-
nar os procedimentos a serem seguidos. Para se chegar ao nível de

maturidade 3 é necessário que a organização já tenha atingido o nível 2
e implemente mais um grupo de processos. Esse grupo de processos
pode ser classificado como processos de engenharia, gerência de pro-
cesso, gerência de projeto e processos de apoio.
•• Os processos de engenharia referem-se às atividades técnicas

que são desenvolvidas no projeto de software: desenvolvimento
de requisitos; solução técnica; integração de produto; verificação
e validação.
•• Os processos denominados gerência de processo referem-se a

processos que ajudam a estruturar os processos como um todo
da organização: foco no processo organizacional; definição do
processo organizacional e treinamento organizacional.
•• Os processos de gerência de projeto complementam os proces-

sos do nível 2: gerência integrada de projetos e gerência de risco.
•• Os processos de apoio são processos cuja finalidade é apoiar as

atividades dos projetos: análise de decisão e resolução.
Pode-se observar que a implementação do nível 3 exige o esforço

para se implementar onze processos e tem a vantagem de trazer para
a organização um conjunto de processos que padroniza todas as ativi-
dades da organização respeitando as especificidades de projetos de na-
tureza diferente e disseminando boas práticas por toda a organização
(CMMI, 2010).
O nível 4 do CMMI tem como foco o gerenciamento quantitativo do

processo. Significa que a organização e os projetos estabelecem ob-
jetivos quantitativos para o desempenho da qualidade e processo. Os
objetivos quantitativos são fundamentados nas necessidades do clien-
te, dos usuários finais, da organização e dos implementadores de pro-
cesso. São eles: desempenho do processo organizacional e gerência
quantitativa de projeto.

Pode-se observar que a implementação do nível 4 requer que este-
jam implementados os processos dos níveis 2 e 3. Com isso é possível
obter uma quantidade suficiente de medições dos processos e dos pro-
dutos para se tomar decisões sobre melhoria de processo com bases
objetivas numéricas (CMMI, 2010).
O nível 5 do CMMI tem como foco a melhoria contínua. Significa que

a organização melhora continuamente seus processos com base em um
entendimento quantitativo dos seus objetivos de negócios e necessida-
des de desempenho. As organizações no nível 5 se concentram em me-
lhorar continuamente o desempenho do processo por meio do processo
incremental e inovador as melhorias tecnológicas. Os objetivos da quali-
dade e do desempenho dos processos são estabelecidos e continuamen-
te revisados para refletirem as mudanças nos propósitos de negócios e
desempenho organizacional, utilizados como critérios na gestão da me-
lhoria de processos. São os seguintes processos desse nível: gerencia-
mento do processo organizacional e análises causais e resolução.
Pode-se observar que a implementação do nível 5 requer que este-

jam implementados os níveis anteriores e é uma evolução deles, mos-
trando claramente o conceito de maturidade (CMMI, 2010).
Além das áreas de processos anteriormente descritas, o CMMI pos-

sui uma preocupação muito grande com a institucionalização do pro-
cesso. Isso significa que é necessário garantir que todos sigam o pro-
cesso e que isso possa ser demonstrado. Foram criadas, para isso, as
metas e as práticas genéricas dos processos. São diretrizes para a im-
plementação dos processos que precisam ser obedecidas, tais como:
“Executar as práticas específicas da área de processo para desenvolver pro-
dutos de trabalho e prestação de serviços para atingir as metas específicas
da área de processo” (CMMI, 2010).
O modelo CMMI é muito robusto e apropriado para o desenvolvimen-

to de aplicações de software que requerem alta qualidade. No entanto,

aplicações com menor responsabilidade podem implementar o mode-
lo. Há uma crítica sobre o CMMI referente a exigir um processo muito
pesado e de alto custo para a organização. Alguns setores do mercado,
como a área militar e aérea, exigem o CMMI, caso contrário não podem
ser qualificados como fornecedores.
3.2 Modelo MPS.BR
O MPS.BR nasceu como uma alternativa ao CMMI; sua primeira ver-

são é de maio de 2005 e a versão atual é de janeiro de 2016. Esse mo-
delo foi desenvolvido pelo Softex, uma associação criada em 1996 para
impulsionar a indústria brasileira de software e serviços de TI. Hoje, o
MPS.BR, além do modelo para software, desenvolve um para RH e outro
para serviços (SOFTEX, 2012).
O MPS.BR é um modelo de maturidade com sete níveis, nomeados

de G até A, no qual o primeiro é o nível mais básico e o último, o mais
avançado. Esse modelo foi inspirado no CMMI e na Norma NBR ISO/IEC
12.207 que descreve os processos do ciclo de vida do software.
Figura 5 – Níveis do modelo MPS.BR
A – Em otimização
B – Gerenciado quantitativamente
C – Definido
o
çã
D – Largamente definido
olu
Ev
E – Parcialmente definido
F – Gerenciado
G – Parcialmente gerenciado

O primeiro degrau desse modelo de maturidade é o nível G, denomi-
nado parcialmente gerenciado. Ao final da implantação deste nível a
organização deve ser capaz de gerenciar parcialmente seus projetos de
desenvolvimento de software. Esse nível possui dois processos a serem
implementados: GRE (gerência de requisitos) e GPR (gerência de projeto).
O nível F, denominado gerenciado, tem como principal foco agre-

gar processos que irão apoiar a gestão do projeto no que diz respeito
à garantia da qualidade e medição, bem como aqueles que irão organi-
zar os artefatos de trabalho por meio da gerência de configuração. São
os seguintes processos a serem implementados: MED (medição); GQA
(garantia da qualidade); GPP (gerência de portfólio de projetos); GCO
(gerência de configuração); e AQU (aquisição).
O nível E, chamado de parcialmente definido, tem como foco princi-

pal a padronização dos processos da organização por meio da definição
de processos padrão. Estes devem ser definidos a partir dos processos
e das melhores práticas já existentes na organização, o que constitui o
primeiro passo de uma contínua avaliação e melhoria dos processos.
A definição de processos padrão inclui, além dos processos do nível E,
todos os processos que pertencem aos níveis G e F do MR-MPS. São os
seguintes processos a serem implementados: GPR (gerência de proje-
tos – evolução); GRH (gerência de recursos humanos); DFP (definição
do processo organizacional); e AMP (avaliação e melhoria do processo
organizacional).
O nível D, denominado largamente definido, tem como foco a defini-

ção e a implementação de cinco novos processos com o mesmo nível
de capacidade dos processos já implantados: DRE (desenvolvimento de
requisitos); ITP (integração do produto); PCP (projeto e construção do
produto); VAL (validação); e VER (verificação).
O nível C, definido, tem como foco a definição e a implementação

de três novos processos com a mesma capacidade dos processos

já implantados: ADR (análise, decisão e resolução); DRU (desenvolvi-
mento para reutilização); e GRI (gerência de riscos). Ao atingir o nível C
uma organização ou unidade organizacional tem definido e implemen-
tado seu processo padrão e usa práticas de engenharia de software
em seus projetos.
O nível B, chamado de gerenciado quantitativamente, tem como

foco de maturidade a organização ou unidade organizacional passar a
ter uma visão quantitativa do desempenho de seus processos no apoio
ao alcance dos objetivos de qualidade e de desempenho dos processos
e também a capacidade de gerenciar quantitativamente os projetos. O
processo a ser evoluído em maturidade é: GPR (gerência de projetos
– evolução).
O nível A, definido otimização, tem como foco a otimização por

meio da realização de mudanças e adaptações de forma ordenada e
intencional para efetivamente atender a mudanças nos objetivos de ne-
gócio da organização. Não apresenta um processo a ser implementado
ou alterado.
Figura 6 – Equivalência entre o CMMI e o MPS.BR
5
A
4
Em otimização
B
Gerenciado quantitativamente
C
3
Definido
D
Largamente definido
E
Parcialmente definido
F
2
Gerenciado
G
Parcialmente gerenciado
Fonte: adaptado de Softex (2012).

Similarmente ao CMMI, o MPS.BR possui os denominados atributos
de processo que são ferramentas equivalentes às práticas genéricas do
CMMI para a institucionalização do processo. Para cada um dos níveis
de maturidade são definidos atributos de processos que precisam ser
implementados também.
O MPS.BR possui equivalência com o CMMI, conforme ilustrado na

figura 6. Os níveis F e G são equivalentes ao CMMI nível 2; os níveis E, D
e C são equivalentes ao nível 3; o nível B é equivalente ao nível 4; e o nível
A equivalente ao nível 5. Assim, com pequenos ajustes, uma empresa
que possui o MPS.BR pode migrar para o CMMI.
3.3 Norma NBR ISO 29110
A indústria de software reconhece a importância das pequenas em-

presas, no contexto do mercado, que contribuem com produtos e ser-
viços de valor. Reconhece também que o portfólio existente de normas
muitas vezes não atende às necessidades dessas empresas. Para isso
foi desenvolvida a série de Normas NBR ISO/IEC 29110, cujo objetivo é
atender a organizações com até 25 pessoas envolvidas com desenvol-
vimento de software. Nesta série, a parte 4 é certificável, ou seja, emite
um certificado ISO para as empresas que implantarem o processo pres-
crito (ABNT, 2011).
Figura 7 – Processos da NBR ISO/IEC 29110-4-1
Declaração Gerência
de trabalho de projeto
Implementação
de software Software

A figura 7 mostra que a Norma 29110 é formada por dois processos:
gerência de projeto (project management – PM) e implementação de
software (software implementation – SI). A organização recebe a decla-
ração de trabalho, ou seja, um conjunto de requisitos a serem imple-
mentados e entrega o software pronto, funcionando. A Norma possui
como itens obrigatórios o atendimento aos objetivos dos processos, a
execução das atividades de PM e SI e os produtos de trabalho. Não exi-
ge, por exemplo, que existam procedimentos documentados.
O processo gerência de projeto possui como propósito estabelecer

e realizar, de forma sistemática, as tarefas do projeto. Com isso, devem
ser cumpridos os objetivos do projeto na qualidade, tempo e custo es-
perados (ABNT, 2011).
O processo implementação de software possui como propósito a

execução sistemática das atividades de análise, design, construção, in-
tegração e testes para produtos novos ou modificados de software de
acordo com os requisitos especificados (ABNT, 2011).
Quadro 1 – Processo gerência de projeto e processo implementação de software
GERÊNCIA DE PROJETO
PM.O1 – O plano de projeto é desenvolvido de acordo com a declaração de trabalho e

validado com o cliente
PM.O2 – O progresso do projeto é monitorado com base no plano de projeto e registrado no
registro de status do progresso
PM.O3 – As solicitações de mudança são tratadas por meio de sua recepção e análise
Objetivos
PM.O4 – São conduzidas reuniões de avaliação com a equipe de trabalho e o cliente
PM.O5 – Riscos são identificados quando aparecem e durante o desenvolvimento do projeto
PM.O6 – Uma estratégia de controle de versão de software é desenvolvida
PM.O7 – A garantia da qualidade de software é realizada para assegurar que os produtos e
processos de trabalho cumpram o plano do projeto e a especificação dos requisitos
PM.1 – Planejamento do projeto
Atividades PM.2 – Execução do plano de projeto

mandatórias PM.3 – Controle e avaliação de projeto
PM.4 – Encerramento de projeto

IMPLEMENTAÇÃO DE SOFTWARE
SI.O1 – Tarefas das atividades são realizadas segundo o plano do projeto corrente
SI.O2 – Requisitos de software são definidos, analisados quanto à correção e testabilidade,

aprovados pelo cliente, colocados em baseline e divulgados
SI.O3 – O projeto de arquitetura e detalhamento do software é desenvolvido e posto

em baseline
SI.O4 – Os componentes de software definidos pelo projeto são produzidos
Objetivos SI.O5 – O software é produzido fazendo a integração dos componentes de software e

verificado por meio de casos de teste e procedimentos de teste
SI.O6 – Uma configuração de software, que atende à especificação dos requisitos como
acordado com o cliente; inclui a documentação de operação, do usuário e de manutenção; é
integrada, posta em baseline e armazenada no repositório do projeto
SI.O7 – São realizadas tarefas de verificação e validação de todos os produtos de trabalho

requeridos, utilizando critérios definidos para assegurar a consistência entre produtos de
entrada e saída em cada atividade
SI.1 – Iniciação da implementação do software
SI.2 – Análise dos requisitos do software
Atividades SI.3 – Projeto de arquitetura e detalhado do software

mandatórias SI.4 – Construção do software
SI.5 – Integração e testes do software
SI.6 – Entrega do produto
3.3.1 Produtos de trabalho
Os produtos de trabalho são os artefatos produzidos durante a exe-

cução do projeto. Alguns produtos de trabalho são documentos gera-
dos durante o processo, como o registro de reunião e o plano do projeto,
e outros são referentes ao produto construído, como a documentação
de manutenção e o software propriamente dito. Todos eles são manda-
tórios (ABNT, 2011).

Quadro 2 – Produtos de trabalho da NBR ISO/IEC 29110-4
NO PRODUTO PM SI
1 Registro de aceitação X
2 Solicitação de mudança X X
3 Registro de correção X
4 Documentação de manutenção X
5 Registro de reunião X
6 Guia de operação do produto X
7 Registro de status de progresso X
8 Plano do projeto X X
9 Repositório do projeto X
10 Backup do repositório do projeto X
11 Especificação de requisitos X
12 Software X
13 Componente de software X
14 Configuração de software X X
15 Projeto (design) de software X
16 Documentação de usuário do software X
17 Declaração de trabalho
18 Casos de teste e procedimentos de teste X
19 Relatório de teste X
20 Registro de rastreabilidade X
21 Resultados da verificação X
22 Resultados da validação X

Esta aula teve por objetivo mostrar a questão da melhoria de proces-
so de software. A melhoria deve ser feita em ciclos e pode utilizar mo-
delos como o CMMI ou a NBR ISO 29110 como referência. Nos ciclos
de melhoria de processo é importante a realização de medições para se
saber objetivamente qual foi a profundidade da melhoria. Também foi
destacada a importância do envolvimento das pessoas nos processos
de melhoria, uma vez que a natureza da atividade de desenvolvimento
de software é intensiva em mão de obra e somente pessoas motivadas,
treinadas e qualificadas poderão realizar melhorias de processo.
Referências
ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC
29110-4-1 – Engenharia de Software: perfis do ciclo de vida de micro-organi-
zações (MOs) – Parte 4-1: especificações de perfil/grupo perfil genérico. Rio de
Janeiro: ABNT, 2011.
AGUIAR, M. Gerenciamento objetivo de projetos com PSM. Brazilian Function

Point Users Group, 2009. Disponível em: <http://www.bfpug.com.br/Exame%20
CSMS/PSM/Apresentacao_PSM_BFPUG_2009-04-27.pdf>. Acesso em: 9 fev.
2017.
BASILI, V.; LINDVALL, M.; REGARDIE, M.; SEAMAN, C.; HEIDRICH, J.; MUNCH,
J.; ROMBACH, D.; TRENDOWICS, A. Linking software development and busi-
ness strategy through measurement. IEEE Computer Society, 2010. Disponível
em: <https://pdfs.semanticscholar.org/4275/9e525aae4736bab0ececa-
33db6396e28317d.pdf>. Acesso em: 9 fev. 2017.

CROSBY, P. B. Qualidade é investimento. Rio de Janeiro: José Olympio, 1979.

DEMING, W.E. Out of the crisis. Cambridge: Cambridge University Press, 1986.
ISO – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC

20926:2003: software engineering – IFPUG 4.1 Unadjusted functional size
measurement method – Counting practices manual, 2003. Disponível em:
<http://www.iso.org/iso/catalogue_detail.htm?csnumber=35582>. Acesso em:
9 fev. 2017.
JONES, Capers. Applied software measurement: assuring productivity and

quality. New York: McGraw-Hill, 1991. (Software Engineering Series).
JURAN, J. M.; GODFREY A. B. Juran´s quality handbook. New York: McGraw-

Hill, 1999.
PSM – PRACTICAL SOFTWARE & SYSTEMS MEASUREMENT. Objective infor-

mation for decision makers, 2016. Disponível em: <http://www.psmsc.com/
members/default.asp>. Acesso em: 9 fev. 2017.
SOFTEX – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE

BRASILEIRO. MPS.BR: melhoria de processo de software brasileiro. Guia geral
MPS de software. Brasília, DF: Softex, 2012. Disponível em: <http://www.softex.
br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012.pdf>.
Acesso em: 9 fev. 2017.
SPINOLA, M. M. Processo de produção de software: da produção à gerência.

Tese de livre docência – Escola Politécnica da Universidade de São Paulo, São
Paulo, 2008.

ADMINISTRAÇÃO
DO BIG DATA
Dados Internacionais de Catalogação na Publicação (CIP)
(Jeane Passos de Souza - CBR 8a/6189)
Machado, Alexandre Lopes

Administração do Big Data / Alexandre Lopes Machado.
– São Paulo : Editora Senac São Paulo, 2017. (Série Universitária)
Bibliografia.
e-ISBN 978-85-396-1228-4
1. Ciência Da Computação 2. Processamento de dados 3. Ciência de

dados
I. Título.
17-499u CDD-001.64
BISAC COM060040
BISAC COM053000
Índice para catálogo sistemático

1. Processamento de dados 001.64
ADMINISTRAÇÃO
DO BIG DATA
Alexandre Lopes Machado

Administração Regional do Senac no Estado de São Paulo
Presidente do Conselho Regional
Abram Szajman
Diretor do Departamento Regional

Superintendente Universitário e de Desenvolvimento

Luiz Carlos Dourado
Editora Senac São Paulo

Conselho Editorial
Luiz Carlos Dourado
Darcio Sayad Maia
Lucila Mara Sbrana Sciotti
Jeane Passos de Souza
Gerente/Publisher
Jeane Passos de Souza (jpassos@sp.senac.br)
Coordenação Editorial
Márcia Cavalheiro Rodrigues de Almeida (mcavalhe@sp.senac.br)
Comercial
Marcelo Nogueira da Silva (marcelo.msilva@sp.senac.br)
Administrativo
Luís Américo Tousi Botelho (luis.tbotelho@sp.senac.br)
Acompanhamento Pedagógico
Ariadiny Carolina Brasileiro Maciel
Designer Educacional
João Francisco Correia de Souza
Revisão Técnica
Joao Carlos Neto
Colaboração
Ana Paula Pigossi Papalia
Estenio Azevedo
Preparação de Texto
Patricia B. de Almeida
Revisão de Texto
Amanda de Lima Lassak
Luiza Elena Luchini (coord.)
Projeto Gráfico
Alexandre Lemes da Silva
Emília Correa Abreu
Capa
Antonio Carlos De Angelis Proibida a reprodução sem autorização expressa.
Todos os direitos desta edição reservados à
Editoração Eletrônica
Sidney Foot Gomes Editora Senac São Paulo
Manuela Ribeiro
Rua 24 de Maio, 208 – 3o andar
Ilustrações Centro – CEP 01041-000 – São Paulo – SP
Sidney Foot Gomes Caixa Postal 1120 – CEP 01032-970 – São Paulo – SP
Tel. (11) 2187-4450 – Fax (11) 2187-4486
Imagens
E-mail: editora@sp.senac.br
iStock Photos
Home page: http://www.editorasenacsp.com.br
E-pub
Ricardo Diana © Editora Senac São Paulo, 2017
Sumário
Introdução à ciência de dados, 7 Modelagem de dados, 65
1 Breve histórico da ciência de 1 Modelo multidimensional, 66
dados, 8 2 NoSQL, 70
2 Business intelligence , 11 3 UML estendida, 72
3 Data warehousing , 13 Considerações finais, 76
4 Data discovery, 17 Referências, 77
Considerações finais, 20
Referências, 20 Capítulo 6
Analítico (analytics) para
Capítulo 2 Big Data, 79
Big Data, 23 1 Analítico, 80
1 Big Data , 24 2 Analítico descritivo, 81
2 Critério dos “V’s”, 25 3 Analítico preditivo, 91
3 Tratamento dos dados, 29 Considerações finais, 94
4 Qualidade de dados, 33 Referências, 95
Mineração de dados, 97
Capítulo 3 1 Aprendizado de máquina, 98
Arquitetura Big Data, 39 2 Classificação, 99
1 Processamento massivamente 3 Associação, 101
paralelo, 40
4 Regressão, 102
2 Arquitetura GoogleFS, 41
5 Agrupamento, 106
3 Arquitetura HDFS, 42
4 MapReduce, 45
Referências, 109
Análise visual de dados, 111
Capítulo 4
1 Análise OLAP, 112
Ingestão de dados, 51
2 Exploratória de dados, 117
1 Tipos de dados, 52
3 Árvores de decisão, 120
2 Coleta de dados, 54
4 Painéis de controle , 121
3 Integração dos dados, 58
4 Interoperabilidade dos dados, 61
Referências, 122
Referências, 63
Material para uso exclusivo de aluno matriculado em curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o compartilhamento digital, sob as penas da Lei. © Editora Senac São Paulo.
Plataformas de Big Data, 123 Novas fontes de dados para
1 Apache Hadoop, 124 Big Data, 135
2 Weka, 128 1 Dados abertos, 136
3 Tableau, 129 2 Web semântica, 139
4 Exemplos de aplicação, 132 3 Dados ligados, 144
Considerações finais, 133 4 Internet das coisas, 144
Referências, 134 Considerações finais, 146
Referências, 147
Sobre o autor, 149
6 Administração do Big Data

Capítulo 1
Introdução à
ciência de dados
A ciência de dados agrega os impactos, os problemas decorrentes

do veloz e exponencial crescimento dos dados e também as técnicas,
as metodologias e as ferramentas relacionadas à manipulação des-
ses dados. Essa nova ciência de processamento é chamada de quarto
paradigma para a exploração científica (HEY; TANSLEY; TOLLE, 2009)
e se distingue da ciência da computação na medida em que explora,
dentre outros aspectos, as inovações relacionadas a manipular, ana-
lisar e visualizar uma enorme quantidade de dados (NATURE, 2008), e
as interações humano-computador, tão valiosas e significativas para a
visualização e o uso efetivo desses dados (CHU, 2013).
7
A administração de Big Data envolve diversos aspectos, tais como
ciência de dados, arquitetura e plataformas de Big Data, análises es-
tatísticas (analytics), mineração de dados, ingestão e modelagem dos
dados e representação visual para a análise dos dados (visual analyti-
cs). Este capítulo vai apresentar um breve histórico da ciência de dados
e algumas técnicas relacionadas ao processo de tomada de decisão.
Ele está organizado em seções que abordam os conceitos de business
intelligence, data warehousing e data discovery.
1 Breve histórico da ciência de dados
Desde meados do século XX, os sistemas automatizados vêm bus-

cando transformar os dados em informação, visando auxiliar o pro-
cesso de tomada de decisão, um processo de escolha que verifica se
determinada decisão é a mais adequada para uma situação específica
(TURBAN et al., 2009). No final dos anos 1960, os computadores tor-
naram-se realmente indispensáveis a qualquer grande organização.
Nessa época, eles executavam somente um aplicativo de cada vez por
meio de processamento em lote (batch). As aplicações eram caracteri-
zadas por relatórios e programas, que geralmente utilizavam a lingua-
gem COBOL (common business oriented language; ou, em tradução
livre para o português, linguagem comum orientada para os negócios)
(TURBAN et al., 2009). A figura 1 ilustra a linha cronológica de evolu-
ção da tecnologia, além de algumas empresas que se destacaram em
cada época.

Figura 1 – Evolução da ciência de dados
1970 1990 2010

SGBD Relacional Objeto relacional NoSQL
DW Big Data
1980 2000
Padrão SQL Google
BI
Mineração de dados
MapReduce
Processamento paralelo
Cloud computing
Orkut
Legenda Facebook
Empresas Twitter
Tecnologias Netflix
Hadoop
Como podemos observar na imagem, por volta de 1970 uma nova

tecnologia de armazenamento e acesso a dados e um novo software
surgiram: o sistema gerenciador de banco de dados, ou simplesmente
SGBD (sistema de gerenciamento de banco de dados). Esse sistema
permitiu visualizar uma organização “baseada em dados”, em que o
computador poderia atuar como coordenador central para atividades
de toda a organização. Com isso, o banco de dados tornou-se um re-
curso corporativo básico e, pela primeira vez, os computadores foram
vistos como uma verdadeira vantagem competitiva em relação a outras
empresas que não o tivessem (KIMBALL; CASERTA, 2004).
Nas décadas de 1970 e 1980, grandes aperfeiçoamentos tecnológi-

cos resultaram em novos sistemas de informação denominados SGBD
relacionais. Com eles, as pessoas mais influentes passaram a ter aces-
so aos dados com maior facilidade de uso (KIMBALL; CASERTA, 2004).
Introdução à ciência de dados 9

Já na década de 1990, a chegada de novas tecnologias, como
o modelo objeto relacional e as ferramentas CASE (computer-aided
software engineering), ou, em tradução livre para o português, enge-
nharia de software guiada por computador, permitiu que o usuário final
assumisse um papel mais ativo, passando a controlar diretamente os
sistemas e os dados fora do domínio do clássico processamento de da-
dos (KIMBALL; CASERTA, 2004). Ainda nos anos 1990, houve também o
barateamento do disco magnético, o que propiciou o desenvolvimento
de novos estilos de modelagem de dados, cujos objetivos eram a com-
preensibilidade da base de dados pelo usuário final e o desempenho de
consultas gigantes (TURBAN et al., 2009).
No início dos anos 2000 surgiram os computadores com processa-

mento paralelo, que tornaram viável a consulta on-line a bases de dados
contendo bilhões de registros, com volumes que atingem exabytes de
dados (CHU, 2013). Com essa evolução, as organizações começaram
a perceber que poderiam analisar os seus dados de forma otimizada.
Para a implementação desses sistemas, elas passaram a estudar no-
vas formas de armazenar os dados contidos nos sistemas, a fim de que
houvesse integração total de seus dados. Além disso, era necessário
manter o histórico das informações e fazer com que elas fossem dis-
postas de diversas formas. O objetivo era extrair os dados acumulados
pelos computadores ao longo dos anos e transformá-los em informa-
ção. Essa estratégia mudou o enfoque que até então era atribuído ao
conjunto de informações. Nesse contexto, os sistemas passaram a per-
tencer a dois grupos (KIMBALL; CASERTA, 2004):
•• Sistemas online transacionais (online transaction processing –

OLTP): sistemas que tratam o negócio e dão suporte diariamente
a ele, garantindo a operação da organização. Eles executam repe-
tidamente o ciclo de uma transação e trabalham com uma situa-
ção instantânea dos negócios. Não possuem, portanto, registros
dos fatos históricos. Em geral, o OLTP abrange os sistemas que
automatizam o negócio, como o sistema de conta-corrente, de
pagamento, de custos, etc.

•• Sistemas de business intelligence (BI): sistemas que analisam o
negócio e ajudam a interpretar o que ocorreu, visando a elabora-

ção de estratégias futuras para a organização e o suporte ao pro-
cesso de tomada de decisão. Em sentido amplo, eles abrangem
todos os sistemas gerenciais de uma organização.
A seguir, vamos nos aprofundar no conceito de business intelligen-

ce (BI). O entendimento desse termo é fundamental para a proposta
deste volume.
2 Business intelligence
Business intelligence (ou, em tradução livre para o português, inte-
ligência de negócios), ou simplesmente BI, é um termo que surgiu nos
anos 1980 e se refere ao processo de coleta, organização, análise, com-
partilhamento e monitoramento de informações (TURBAN et al., 2009).
A informação transformada e aplicada a um determinado processo de
decisão pode gerar vantagem competitiva para a organização. Assim,
podemos dizer que o BI é o produto da transformação de dados em infor-
mação, após ela ser analisada ou inserida em um determinado contexto.
O BI envolve a utilização de produtos e soluções desenvolvidas com a

tecnologia analítica, que permite transformar os dados armazenados em
bases de dados em informações que auxiliam os diversos níveis de uma
organização. Por exemplo, como interface, ele transforma e torna verda-
deiras todas as informações e as converte em conhecimento estratégico.
Os sistemas BI têm como características (BARBIERI, 2012):
•• Extrair e integrar dados de múltiplas fontes: há ilimitadas pos-

sibilidades de integração com dados provenientes de diversos
sistemas-fonte, obtidos paulatinamente mediante a evolução
por versões.

•• Fazer uso da experiência: a busca e a interpretação de informa-
ções armazenadas na corporação por meio de ferramentas, ga-
rantindo maior precisão nas tomadas de decisão.
•• Analisar dados contextualizados: a aproximação íntegra e co-

laborativa para capturar, criar, organizar e usar todos os ativos
de informação de uma organização. Esses dados são tratados
por um sistema de transformação que cria visões integradas, de
acordo com as necessidades de cada comunidade de usuários,
evitando inconsistências entre os diversos relatórios gerenciais
que chegam à alta gerência.
•• Trabalhar com hipóteses: as hipóteses são características de

processos de auditoria, fiscalização ou validação de ideias. Elas
propiciam a antecipação de mudanças bruscas no mercado, além
de estabelecer imediatamente ações sobre os competidores por
meio da análise dos dados contextualizados.
•• Procurar relações de causa e efeito: o aprendizado por meio

do sucesso e de falhas dos concorrentes proporciona a gera-
ção de novos conhecimentos e uma visão mais clara sobre os
novos negócios.
IMPORTANTE
O BI descreve as habilidades para acessar os dados e explorar as

informações (geralmente contidas em um data warehouse) por meio
de análises, o que permite melhorar o processo de tomada de deci-
são das organizações.

3 Data warehousing
Data warehousing (DW) é o processo pelo qual as organizações

transformam os seus dados computadorizados em informações, utili-
zando uma base de dados com características peculiares denominada
data warehouse (DW ou, em tradução livre para o português, armazém
de dados) (KIMBALL; CASERTA, 2004).
O DW é formado por partes lógicas pequenas denominadas data

marts (ou, em tradução livre para o português, repositórios de dados).
Esse repositório corresponde às necessidades de informação de deter-
minada comunidade de usuários e representa um projeto que pode ser
produzido por uma equipe específica, pois considera-se que para o pro-
jeto monolítico de um DW completo seria necessário o envolvimento de
membros de todas as áreas da organização, o que dificultaria a criação
de uma primeira versão do DW (KIMBALL; CASERTA, 2004).
IMPORTANTE
O DW é uma base de dados orientada por assunto, integrado, não

volátil de histórico, criado para suportar o processo de tomada de
decisão, seja ele tático, estratégico ou operacional.
O DW se propõe a extrair os dados acumulados pelos computadores

ao longo dos anos e transformá-los em informação, ou seja, em algo
que faça sentido ao usuário final. Para tanto, os paradigmas a seguir
são necessários tanto para o armazenamento quanto para a recupera-
ção de informações (KIMBALL; CASERTA, 2004):
•• Não volátil: após serem integrados e transformados, os dados

são carregados em blocos para que sejam disponíveis aos usu-
ários para acesso, possibilitando realizar apenas consultas e

geração de relatórios necessários à tomada de decisão, não per-
mitindo, portanto, atualizações.
•• Histórico: o DW tem a missão de se tornar a “memória corpo-

rativa”. Todos os dados históricos são armazenados no DW,
possibilitando o tratamento de extensas séries históricas. Essa
característica se adapta perfeitamente à atual tendência das or-
ganizações de focar seus negócios no cliente, pois permite tra-
çar o perfil do comprador a partir de seus hábitos e prever seus
movimentos futuros.
•• Acesso: a ênfase do DW é a recuperação da informação, e não

somente o seu armazenamento. O próprio usuário especifica e
executa suas consultas, utilizando uma ferramenta de mercado,
sem necessidade de solicitar o desenvolvimento de programas
pelo pessoal responsável pela área de tecnologia da informação
(TI) da empresa. Com isso, a entrega da informação aos usuários
tende a se tornar cada vez mais proativa.
•• Granularidade: capacidade de tratar consultas que endereçam

centenas de milhares de registros e possibilidade de detalha-
mento sucessivo no decorrer de uma consulta, podendo chegar à
granularidade mais refinada que se desejar. É recomendado que
o dado seja armazenado no DW no mesmo nível de detalhamento
em que ele é gerado nos sistemas-fonte.
•• Evolução harmoniosa e constante: a TI apoia os usuários no

acesso ao DW, assessorando-os nas estratégias de busca, me-
lhorando o desempenho das consultas mais frequentes e cole-
cionando as novas necessidades de informação a serem con-
templadas na próxima versão do DW.
Vamos analisar na figura 2 os componentes de uma solução DW:

Figura 2 – Componentes de uma solução DW
fontes periodicamente
diversas
A
ETL Data Warehouse
Data Mart Data Mart
BI
B
Área de concentração Data Mart Data Mart
C processo de metadados
verificação da carga
Os dados coletados podem ter diversas fontes. Eles são extraídos

periodicamente por meio das ferramentas ETL, sigla para extraction
transformation loading (em português, extração transformação carga).
Essa ferramenta realiza um tratamento dos dados por meio de um pro-
cesso que passa pela fase de extração, transformação e carga dos da-
dos coletados.
Ainda no ETL temos um tipo de armazenamento denominado

staging area (ou, em tradução livre para o português, área de concentra-
ção), onde são encontrados os metadados, ou “dados sobre dados”, que
são como um conjunto de informações de todos os dados coletados,
por exemplo: o nome, a origem, o formato, o fluxo, etc. Esse ciclo de
coleta e tratamento do ETL é contínuo.
Além disso, é por meio do ETL que os dados podem ser enviados ao
data mart, que, como já foi dito, é um subconjunto do DW que “agrupa”
esses dados de acordo com um contexto (seja sua caraterística ou o
tipo de informação que possui), buscando cumprir os requisitos espe-
cíficos de determinados grupos/departamentos que precisem daquela
informação.

Uma vez que os dados chegam a essa etapa, é possível iniciar a
transformação de dados em informação. Ou seja, é nessa etapa que o
BI acontece, organizando as informações e disponibilizando-as para
os usuários.
Assim, por meio do ETL, os dados que antes estavam dispersos

são organizados e se tornam informações, documentos e relatórios, os
quais contribuem com o processo de tomada de decisões. Apesar de
parecer complexo, esse processo acontece em diferentes empresas ao
redor do mundo.
Em resumo, uma solução de DW envolve quatro componentes prin-

cipais. São eles:
1. Processo de tratamento de dados: os processos de extração,

transformação e carga de dados entre dois modelos diferentes, o
OLTP e o DW, denominado ETL.
2. Uma nova organização de dados: o modelo dimensional.
3. Um software específico: a ferramenta OLAP para acesso à

base DW.
4. Um hardware específico: computador com processamento

paralelo.
Todos esses componentes serão analisados nos temas dos próxi-

mos capítulos deste volume.
3.1 Sistema extração/transformação/carga
O sistema extração/transformação/carga (ETL) é um processo sis-

tematizado que está constantemente transferindo dados dos sistemas
OLTP para o ambiente de apoio à decisão (KIMBALL; CASERTA, 2004).
A figura 2 apresentou o processo ETL, que é a parte mais trabalhosa
e invisível para o usuário final. Usando a analogia, ele é a ponta de um
iceberg no oceano do DW.

O componente de extração retira os dados dos sistemas OLTP com
o objetivo de manipulá-los em outros ambientes. Esse processo é feito

por meio de programas extratores que realizam a extração e a inte-
gração de fontes de dados remotos e locais em um único conjunto de
dados, evitando, dessa forma, a criação de arquivos intermediários e,
consequentemente, a falha na integridade e na credibilidade dos dados
e de novos tratamentos dos dados. Em outras palavras, o componente
de extração evita que a informação seja publicada com valores diferen-
tes do sistema-fonte, além de oferecer conectores para diversas fontes
de dados, incluindo bancos de dados, arquivos e aplicações externas.
O componente de transformação, por sua vez, realiza a transfor-

mação dos dados transacionais em formato dimensional. Ele está
constantemente em alteração tanto para atender à inclusão de novos
data marts como para adequar-se às mudanças dos sistemas-fonte.
Ressalta-se que qualquer que seja a estrutura em que os dados dos
sistemas-fonte se encontrem, eles serão trazidos pelo componente de
transformação para a estrutura do DW, se necessário. Para facilitar essa
dinâmica, é importante que ele seja implementado com ferramentas
que apresentem interface gráfica e viabilizem uma documentação téc-
nica mais precisa e integrada.
Por fim, o componente de carga encerra o processo realizando a

carga dos dados transformados no banco de dados do DW. Como ele é
alimentado periodicamente a partir dos sistemas-fontes, é natural que
mudanças nesses sistemas impactem o DW.
4 Data discovery
Em um ambiente ideal de BI, 80% das demandas de análise de dados
deveriam ser conduzidas pelos próprios usuários de negócio, deixan-
do nas mãos dos profissionais de TI as aplicações de BI corporativas.

Entretanto, os relatórios com análise de dados são raramente lidos ou
simplesmente não utilizados, gerando desperdício de trabalho dos pro-
fissionais de TI, que poderiam estar desempenhando atividades com-
plexas e de missão crítica (EVELSON, 2012).
Sendo assim, há a necessidade de se construir soluções que per-

mitem ao cientista de dados elaborar análises a partir dos dados. As
análises mais sofisticadas podem trazer grande valor para o negócio.
Por exemplo, um relatório que mostra um cliente que deseja cancelar
um serviço e que indica quais mudanças podem ser feitas para mantê-
-lo é mais interessante do que um relatório que lista os clientes que a
organização já perdeu.
O data discovery (ou, em tradução livre para o português, descoberta

de dados), ou simplesmente DD, tem o objetivo de responder perguntas
que o usuário ainda não conhece, valorizando o potencial dos dados e
de análise dos profissionais de negócio. Para isso, algumas atividades
são realizadas em ambientes corporativos por diferentes papéis. O ana-
lista de sistemas prepara as fontes de dados para que o analista de
negócio as valide e construa as primeiras visualizações que serão evo-
luídas pelo cliente. A parceria entre os especialistas de TI e de negócio
é essencial.
Assim, o DD dá mais autonomia ao usuário final e, consequente-

mente, a desoneração dos departamentos de TI (EVELSON, 2012). Com
isso, as soluções de DD podem despertar a curiosidade natural das pes-
soas, sugerindo novas perguntas e hipóteses ao negócio e a descoberta
de novos conhecimentos, padrões e desvios (ou anomalias), levando a
decisões bem informadas.
Segundo (EVELSON, 2012), as ferramentas de DD devem ter as se-

guintes características fundamentais:

•• Conhecimento: capacidade analítica para os conhecedores do
negócio por meio de descoberta e análise de contexto. A ferra-

menta deve permitir a criação e o compartilhamento de visualiza-
ções, relatórios e painéis interativos (dashboards), possibilitando
a colaboração dos usuários.
•• Autonomia: maior autonomia para o usuário final na medida em

que é mais fácil criar gráficos e painéis gráficos que reagem a
cada clique ou seleção do usuário e apresentam visualizações até
então não imaginadas por ele. Para tanto, a ferramenta deve con-
ter interface gráfica fácil, intuitiva e voltada ao usuário final, o qual
não será necessariamente um especialista em TI.
•• Descoberta: geração de novas visualizações integradas quando

o usuário interage com um gráfico do painel; consequentemente,
os outros gráficos são atualizados para um novo contexto. Para
tanto, as ferramentas devem suportar a análise visual, a fim de
possibilitar a descoberta de tendências e exceções significativas
no negócio, a livre exploração dos dados em qualquer nível de
detalhe por meio de filtros dinâmicos e a capacidade de efetuar
quaisquer combinações.
•• Resultado: garantia de agilidade nas soluções e oferecimento de

certo grau de independência da TI, sendo uma espécie de self-ser-
vice BI, sem a necessidade da criação de modelos complexos de
dados. Em outras palavras, o objetivo principal é a desoneração
dos departamentos de TI. Para tanto, as ferramentas devem per-
mitir a portabilidade das visualizações, oferecendo aplicações-
-clientes para as plataformas desktop e mobile (tablets e smart-
phones) e tendo um motor otimizado de manipulação dos dados
em memória (in-memory engine).

Este capítulo apresentou o conceito e um breve histórico da ciência
de dados, além de algumas técnicas relacionadas ao processo de aná-
lise de dados e de tomada de decisão.
O volume de dados gerado nos domínios corporativos tem cresci-

do de forma incrivelmente rápida. Esses dados produzidos superam,
em muito, a capacidade de análise das tradicionais ferramentas OLTP.
Nesse contexto, novas técnicas são necessárias para projetar os siste-
mas de apoio à decisão.
Por fim, ressalta-se que não existe uma solução única para Big Data.
As técnicas apresentadas neste capítulo são complementares: o DW é
adequado a negócios com maior previsibilidade, com amplo domínio
sobre as informações ou com muitas regras já estabelecidas, enquanto
o DD é indicado em situações de auditorias, fiscalizações e análises
de tendência, dando maior flexibilidade e autonomia ao usuário nas
análises.
Referências
BARBIERI, Carlos. BI2-Business intelligence: modelagem e qualidade. São
Paulo: Elsevier Campus, 2012.
CHU, Wesley W. Data mining and knowledge discovery for Big Data: methodolo-
gies, challenge and opportunities. New York: Springer-Verlag, 2013.
EVELSON, Boris. The forrester wave: self-service business intelligence platforms,

Q2 2012. Relatório técnico. Forrester. Junho, 2012. Disponível em: <http://www.
sas.com/content/dam/SAS/en_us/doc/analystreport/forrester-wave-self-
service-105855-0612.pdf>. Acesso em: 24 out. 2016.
HEY, Tony; TANSLEY, Stewart; TOLLE, Kristin M. The fourth paradigm: data-
intensive scientific discovery. Redmond: Microsoft Research, 2009.

KIMBALL, Ralph; CASERTA, Joe. The data warehouse ETL toolkit: practical
techniques for extracting, cleaning, conforming, and delivering data. Hoboken:

Wiley, 2004.
NATURE. Big Data: science in the petabyte era. Nature international weekly
journal of science, n. 7209, vol. 455, p. 1-136, 2008. Disponível em: <http://www.
nature.com/nature/journal/v455/n7209/>. Acesso em: 24 out. 2016.
TURBAN, Efraim; SHARDA, Ramesh; ARONSON, Jay E.; KING, David. Business
intelligence: um enfoque gerencial para a inteligência do negócio. Porto Alegre:
Bookman, 2009.

22
Administração do Big Data
Capítulo 2
Big Data
A disponibilidade cada vez maior de dispositivos móveis, de redes

sociais, da web e da captura automática de dados, por meio de senso-
res, tem aumentado consideravelmente a quantidade de dados arma-
zenados e trafegados no mundo. Além disso, a quantidade de dados
gerados pelas organizações tem crescido na mesma proporção – uma
evolução que se tornou um dos principais desafios técnicos para a
ciência da computação (MCAFEE; BRYNJOLFSSON, 2012).
Esses dados estão armazenados de diversas formas e espalha-

dos em ambientes distribuídos, como nas nuvens computacionais.
O desafio é conseguir transformar esse grande volume de dados em
23
informações úteis para a análise e suporte ao processo de decisão, feita
de forma rápida. Esse problema é conhecido como Big Data (MAYER-
-SCHONBERGER; CUKIER, 2013).
Este capítulo vai apresentar o conceito de Big Data e seus critérios.

Além disso, analisará o critério dos “V’s” e algumas técnicas relaciona-
das ao tratamento e à qualidade dos dados.
1 Big Data
As transações da sociedade contemporânea estão cada vez mais
automatizadas e, na última década, uma grande quantidade de dados,
proveniente de centenas de milhares de fontes diferentes, foi armaze-
nada em diversos meios computacionais, o que promove um grande
volume de dados nos sistemas computadorizados.
A consequência disso é que eles estão inundando as bases de ar-

mazenamento de dados. O grande volume ultrapassa a capacidade
de armazenamento dos mecanismos tradicionais, que é considerada
segura e confiável. São exemplos desses sistemas computadorizados:
os portais web, os blogs, as aplicações mobile, os roteadores de rede,
as chamadas voip, as mensagens instantâneas em celulares, as redes
corporativas, os bilhetes de transporte público, as notas fiscais eletrô-
nicas, os registros médicos, etc.
Nesse contexto, as bases de dados estão sendo carregadas em uma

velocidade crescente e exponencial, pressionando as organizações a
manterem uma infraestrutura capaz de trabalhar on-line, todos os dias
da semana e 24 horas por dia (MANYIKA et al., 2011).
McAfee e Brynjolfsson (2012, p. 63) apontam para uma preocupa-

ção: “Nós não temos algoritmos melhores. Temos apenas mais dados”.

Um exemplo disso é a necessidade de analisar um arquivo de log de
dados com 1 bilhão de eventos. O log de dados é uma funcionalidade

utilizada para descrever o processo de registro de eventos relevantes
em um sistema computacional. Esse registro pode ser utilizado para
restabelecer o estado original de um sistema ou para que um admi-
nistrador conheça o seu comportamento no passado, ou para audi-
toria e diagnóstico de problemas em sistemas computacionais. Sem
a utilização de um algoritmo, seria necessário utilizar alguma técnica
de análise estatística tradicional, como a amostragem. Entretanto, a
amostragem tem uma série de limitações, tais como a identificação
de eventos poucos frequentes. Esses “sinais” são considerados ape-
nas ruídos e a identificação de proporção do ruído presente nos dados.
Em outras palavras, eles não ajudam a avaliar a confiabilidade do re-
sultado das análises.
A utilização de novas técnicas para o tratamento de dados pode ser

considerada uma abordagem importante para a análise de grandes vo-
lumes de dados na medida em que utiliza métodos, tecnologias e fer-
ramentas diferentes das tradicionais para a captura, o gerenciamento e
o processamento dos dados (MAYER-SCHONBERGER; CUKIER, 2013).
São exemplos de análise de grandes volumes de dados: a combinação
e a análise de dados de várias fontes diferentes, como termos mais usa-
dos; a criação de listas de palavras-chave extraídas por meio de proces-
samento de textos, organizados segundo algum critério dependente de
contexto, etc.
2 Critério dos “V’s”

Neste livro, utilizaremos a definição de Big Data como qualquer con-
junto de dados (datasets) que atende ao critério dos “V’s”, divididos em
dois grupos:
Big Data 25
1. Os nativos, que são o volume, a variedade e a velocidade.
2. Os adquiridos, que são a variabilidade, a veracidade e o valor.
2.1 Volume
O volume indica que o tamanho das bases de dados tem aumenta-

do consideravelmente, em escala de terabyte ou superior. Ou seja, são
grandes volumes de dados.
PARA SABER MAIS
O aspecto mais importante do critério volume está relacionado

com o tempo de transmissão desses dados, desde o local onde
eles estão armazenados até o local onde eles serão processados,
independentemente do tamanho.
Para grandes volumes, esses tempos serão significativamente
maiores se comparados com aplicações convencionais. Isso leva
à necessidade de arquiteturas de análise específicas para esses
problemas.
2.2 Variedade
A variedade significa que os dados são armazenados nas mais di-

versas formas. Nas grandes organizações, os sistemas de software (ou
hardware dedicado) geralmente utilizam os mais diferentes tipos de
dispositivos de armazenamento, sistemas de arquivo, tipos de codifi-
cação, estrutura de dados, etc. (MANYIKA et al., 2011). Em geral, cada
base de dados possui um modo próprio de armazená-los e codificá-los.
Portanto, a realidade dos dados é a heterogeneidade.

PARA SABER MAIS
As bases relacionais são utilizadas com maior frequência para o

armazenamento de dados tabulares e informações numéricas. Os
dados são armazenados em base de dados estruturada e gerida por
SGBD. Por outro lado, os dados não tabulares e não numéricos (da-
dos não estruturados e semiestruturados) podem utilizar os bancos
de dados NoSQL. Eles serão apresentados em um próximo capítulo.
2.3 Velocidade
A velocidade é a capacidade de analisar grandes volumes de dados de

forma rápida. Ela está relacionada a técnicas para extrair conhecimento
útil a partir de dados. Por útil, entende-se o conhecimento estatistica-
mente válido, evitando um dos grandes problemas das análises estatísti-
cas tradicionais, por exemplo, a amostragem. A análise visual dos dados
(visual analytics) será apresentada mais ao final deste volume.
NA PRÁTICA
Uma aplicação do critério velocidade pode ser analisada no arma-

zenamento das interações com o usuário. Por exemplo, uma página
de venda de equipamentos eletrônicos, e que armazena os “cliques”
de mouse de um usuário que navega pelos seus produtos e ofertas.
Essa interação gera grandes quantidades de dados, utilizados para
a realimentação do site, que irá sugerir outros produtos ao cliente.
Essa ação tem que ser rápida o suficiente para o cliente visualizar
o novo produto enquanto navega na página do item que o motivou
a consultar o site. Outro exemplo desse critério é a sugestão de ví-
deos do YouTube: o site identifica o sucesso de um vídeo e o coloca
no topo das pesquisas para determinadas palavras-chave, de forma
rápida e automática.
Big Data 27
2.4 Variabilidade
A variabilidade, ou volatilidade, se refere aos tipos de dados que so-
frem alterações durante o tempo. Ou seja, dados dinâmicos e que são
atualizados constantemente.
PARA SABER MAIS
O critério variabilidade é contrário ao princípio de DW, que segue o

critério de não volátil. No DW, os dados são carregados em bloco
após serem integrados e transformados. Dessa forma, eles ficam
disponíveis aos cientistas de dados para acesso, mas possibilitando
realizar apenas consultas, não permitindo, portanto, atualizações.
2.5 Veracidade
A veracidade se refere à autenticidade, à reputação de origem e à

confiabilidade dos dados (IBM, [s.d]). Ou seja, esse critério classifica se
a origem dos dados coletados é comprovada, se eles são confiáveis, se
estão dentro da validade (ou vigência) e, quando os dados estão desa-
tualizados, se são identificados e tratados.
2.6 Valor
O valor se refere a dados com significado que contribuam com valor

agregado para os negócios. Em outras palavras, trata-se do esforço de
analisar os dados que de fato sejam fontes de valor agregado para a
tomada de decisão.

PARA SABER MAIS
Em termos de negócio, a entrega de valor pode ser traduzida como:

vantagem competitiva, tempo necessário para o preenchimento de
um pedido/serviço, satisfação do cliente, tempo de espera do clien-
te, produtividade dos funcionários e lucro. Para maiores informa-
ções, consulte o framework para governança de TI COBIT (control
objectives for information and related technology), no site da ISACA:
https://www.isaca.org/.
3 Tratamento dos dados

A criação de novos modelos de gestão de informações é um aspecto
importante em toda organização, pois a torna apta a extrair o máximo
potencial do volume de dados, especialmente para o tratamento mas-
sivo de dados.
O framework de múltiplas tecnologias integradas para o processa-

mento de dados massivos e a criação de uma cadeia de valor por meio
dos dados (do inglês data value chain) são apresentados na figura a
seguir. O framework é responsável por:
1. Gerenciar um fluxo contínuo de dados, desde a sua geração até

a transformação em análises (analytics) de alto nível, visando ali-
mentar os processos corporativos de decisão.
2. Formar uma parceria colaborativa e coordenada entre os interes-

sados em utilizar os resultados das análises para otimização de
serviços e a tomada de decisão.
3. Simplificar as atividades de gerenciamento dos dados de for-

ma a estruturar uma abordagem que favoreça o investimento
em pessoal, processos e tecnologias que maximizem o valor do
conjunto de dados e gerem decisões que aumentem o desem-
penho da organização.
Big Data 29
O tratamento massivo encadeado (workflow) de dados é composto
pelas seguintes fases: a descoberta de dados (data discovery), a inte-
gração de dados (data integration) e a exploração de dados (data explo-
ration), conforme figura 1.
Figura 1 – Workflow de tratamento massivo encadeado
Descoberta de dados Integração Exploração de dados

de dados
Coletar
Preparar Organizar Integrar Analisar Visualizar Fazer decisões
e anotar
Fonte: adaptado de Miller e Mork (2013).
3.1 Descoberta de dados

A fase de descoberta de dados envolve a localização, a preparação
e a organização dos conjuntos de dados relevantes para o processo de
decisão (MILLER; MORK, 2013).
Na fase de coletar e anotar (collect and annotate) é feita a criação de

um catálogo das fontes de dados disponíveis e a aplicação dos critérios
que descrevem a qualidade dessas fontes de dados. Os fatores de qua-
lidade de dados serão apresentados a seguir.
A fase de preparação (prepare) envolve a disponibilização dos dados-

-fonte para um sistema de acesso compartilhado e a definição de re-
gras de controle de acesso para estabelecer níveis adequados de segu-
rança e privacidade no uso dos dados. Nesse contexto, destacam-se as
tecnologias de APIs e Web Services, dentre outras.
Na fase de organização (organize) é feita a definição de metadados

corporativos que envolve a cooperação entre as mais diversas áreas da
organização. Os metadados constituem uma base de dados de apoio
para que o cientista de dados conheça precisamente os itens informa-
cionais que fará constar da sua análise. A colaboração entre as áreas
de geração e de consumo dos dados cria um ambiente de contínua

evolução dos metadados. Eles podem ser definidos na forma de
schemas ou publicados em um servidor de metadados que se baseie

em uma linguagem padronizada.
Por fim, os metadados são acrescentados a uma dimensão extra

dos dados, ampliando a integração dos silos de informação e agregan-
do valor aos dados (MILLER; MORK, 2013).
3.2 Integração de dados

A fase de integração de dados envolve a junção dos bancos de dados
em uma representação comum. Dessa forma, departamentos distintos
podem analisar em particular os dados, evitando gerar informações
conflitantes e, consequentemente, o problema dos silos de informação
(MILLER; MORK, 2013).
Esse problema se refere a grandes fontes de informações heterogê-

neas que não podem ser pesquisadas com precisão, com opções avan-
çadas, comparadas e combinadas, uma vez que cerca de 90% desses
dados são não estruturados (HAGEL; BROWN, 2001). Os dados não es-
truturados serão apresentados em outro capítulo. É possível fazer uma
analogia entre a integração de dados e os silos de alimentos, que são
estruturas físicas, de variados tipos e tamanhos, usadas para armaze-
nar alimentos pelo período que for necessário. Não há possibilidade de
saber qual foi o último grão inserido no silo, ou a quantidade de grãos
existentes em um determinado momento.
3.3 Exploração de dados

A fase de exploração de dados envolve a extração de conhecimen-
to das bases de dados. Atualmente, existem muitas e diversificadas
ferramentas para a exploração dos dados, por exemplo as técnicas
de mineração de dados e também modelos com base em técnicas
recentes, como o MapReduce. Essas técnicas serão apresentadas nos
capítulos 3 e 7.
Big Data 31
3.3.1 Análise
Na fase de análise (analyze), o cientista de dados documenta, con-
comitantemente ao processo de análise, os passos utilizados no pro-
cessamento dos conjuntos de dados (datasets), desde a entrada até
a síntese de saída, possibilitando a reprodução e a evolução futura da
análise (MILLER; MORK, 2013).
PARA SABER MAIS
Os resultados obtidos na fase de análise e visualização por meio

de gráficos e planilhas, linha de tempo, etc. podem apresentar pe-
quenas incorreções e flutuações, de acordo com a qualidade dos
dados utilizados. Os aspectos de qualidade dos dados serão apre-
sentados a seguir.
3.3.2 Visualização
A fase de visualização (visualize) de dados envolve a sintetização

das informações coletadas no processo de exploração das combina-
ções dos dados na forma de gráficos estáticos ou interativos (MILLER;
MORK, 2013). Atualmente, existe uma variada oferta de ferramentas e
padrões abertos para visualização de dados, os quais serão apresenta-
das no capítulo 8.
3.3.3 Tomada de decisão
A fase de tomada de decisão (make decisions) envolve o processo

de decisão que utiliza o conhecimento extraído nas fases anteriores de
análise e de transformação de informações visuais (MILLER; MORK,
2013). Uma das dificuldades enfrentadas nessa fase é a ausência de
tomada de decisão baseada na análise dos dados, para uma maior

acurácia. Em geral, os gestores tendem a tomar decisões fundamenta-
das em intuição e experiência, ao invés de decisões baseadas em fatos

e dados (DAVENPORT, 2014).
IMPORTANTE
Os usuários do processo de análise Big Data são os tomadores de

decisões e, portanto, precisam de informações sumarizadas que
possam ser usadas com agilidade em processos de decisão crítica
e em muitas outras situações, de forma automática, aumentando a
velocidade com a qual as intervenções podem ser aplicadas.
4 Qualidade de dados
A qualidade do resultado do processo de análise depende da qua-
lidade dos dados armazenados nas bases. Os dados de integração de
bases diferentes podem apresentar ruído, informações ambíguas, con-
flitantes ou mesmo errôneas.
Nesse contexto, alguns aspectos são importantes para a qualidade

dos dados (LOSHIN, 2011):
•• A integridade (completeness).
•• A validade (validity).
•• A granularidade (uniqueness).
•• A tempestividade (timeliness).
•• A precisão (accuracy).
•• A consistência (consistency).
•• A flexibilidade (flexibility).
A seguir vamos analisar cada um desses aspectos e entender a sua

relação com a qualidade dos dados.
Big Data 33
4.1. Integridade e validade
A integridade se refere a conjuntos de dados que refletem correta-
mente a realidade representada pela fonte de dados, que são consis-
tentes entre si e que, portanto, são dados válidos (LOSHIN, 2011). Por
exemplo, para tentar garantir a integridade de um banco de dados, no
caso da abordagem relacional, os SGBD oferecem uma restrição de in-
tegridade, que é uma regra de consistência de dados.
4.2 Granularidade
A granularidade se refere à seleção dos dados no seu nível atômico,

além dos dados agregados que forem necessários (LOSHIN, 2011). O
nível atômico se refere à exibição da informação no seu nível mais de-
talhado (por exemplo, o bairro de domicílio de um cliente) ao final de
uma análise, a qual pode ter sido iniciada por uma visão agregada (por
exemplo, clientes por estados ou municípios).
IMPORTANTE
Uma base de informações para apoiar o processo decisório, tanto no

nível tático como no operacional, deve ser altamente granular, permi-
tindo a exibição da informação no seu nível mais detalhado.
4.3 Tempestividade
A tempestividade se refere à agilidade na obtenção de informações. Ela

objetiva a realização de qualquer análise que não tenha sido previamente
definida, a qualquer tempo, pelo cientista de dados. A qualquer tempo sig-
nifica o oferecimento de informações do passado e na formação de séries
históricas de valor inestimável para as previsões (LOSHIN, 2011).

IMPORTANTE
O eixo do tempo consiste na implementação de uma tabela-calen-

dário, com um registro para cada ocorrência do dia, de forma seme-
lhante à implementação do eixo do espaço, no qual se implementa
uma tabela-localidade, com um registro para cada ocorrência do mu-
nicípio, por exemplo.
4.4 Precisão
Esse critério se refere à precisão com que os dados são descritos

por meio dos metadados (LOSHIN, 2011). Os metadados podem conter
o significado do dado no contexto do negócio, a última data de atualiza-
ção de cada informação, a fórmula utilizada para calcular um item de-
rivado, como um indicador, a entidade proprietária do dado ou respon-
sável pelo fornecimento da informação, algum problema de imprecisão
detectado nos dados de origem e, por fim, a forma como o sistema trata
as mudanças ocorridas em determinadas tabelas.
4.5 Consistência
A consistência se refere à importância de a informação disponibili-

zada não conter erros. As inconsistências podem ter origem no sistema
de transformação, que gerou algum erro nas etapas de extração, ou no
próprio sistema-fonte, que captou dados errados. Neste último caso,
uma vez identificado o erro, pode-se optar por apresentá-lo com a de-
vida sinalização, de forma a demonstrar o que se passa no sistema de
origem. A garantia desse tipo de consistência se atinge pela atividade
de controle de qualidade.
Big Data 35
4.6 Flexibilidade
A flexibilidade se refere à facilidade de elaboração de análises iné-
ditas (LOSHIN, 2011). Em outras palavras, o cientista de dados pode
manusear e formatar de acordo com suas necessidades e preferências.
Em um ambiente global de competição, a pressão por inovação con-
tínua e por abordagens como “fazer melhor com menos” é uma ne-
cessidade constante. Este capítulo apresentou o conceito de Big Data,
os seus critérios e algumas técnicas relacionadas ao tratamento e à
qualidade dos dados.
Aproveitar o potencial dos dados e aplicar novas tecnologias para

o tratamento massivo de dados visando oferecer serviços mais ade-
quados e melhorar a tomada de decisões é um grande desafio, mas
também uma grande oportunidade para as organizações. O uso de tec-
nologias adequadas pode reduzir a complexidade de soluções para a
contextualização, busca e análise de informações (CHU, 2013).
Os critérios nativos e adquiridos dos “V’s” ajudam a definir com maior

precisão quais tipos de dados são considerados grandes volumes de
dados. Ressalta-se que uma determinada aplicação pode ter ênfases
diferentes em cada um dos “V’s”. Por exemplo, há casos em que a varie-
dade é mais evidente que o volume ou velocidade, ou vice-versa.
A integração é um dos maiores desafios atuais da ciência da com-

putação e requer um esforço de compreensão profunda dos sistemas-
-fonte, uma modelagem única dos dados, a adoção de padrões e um
sistema de transformação que trate os dados provenientes de diversas
origens para que possam conviver harmoniosamente em uma mesma
análise. Ela deve ser considerada tanto do ponto de vista da arquitetura
da solução quanto da sua engenharia, com o objetivo de se obter uma

definição precisa dos pontos de integração desejados entre as informa-
ções provenientes de origens diversificadas.
Por outro lado, quanto mais bases forem integradas e mais diver-
sificado for o conjunto de dados, mais rico será o processo de análi-
se e mais importante será o impacto de seus resultados nas decisões
administrativas.
Com relação à qualidade de dados, é possível aceitar imperfeições

nos dados desde que o nível de ruído seja pequeno em relação ao vo-
lume. Isso faz com que boa parte desses dados, mesmo quando devi-
damente armazenados, não sejam desprezados pelas organizações, o
que ocorria no passado, quando as organizações não sabiam extrair
utilidade deles.
Referências
DAVENPORT, Thomas H. How strategists use Big Data to support internal

business decisions, discovery and production. Strategy & Leadership, 42(4),
2014.
HAGEL, John; BROWN, John S. Your next IT strategy. Harvard Business Review,
2001. Disponível em: <https://hbr.org/2001/10/your-next-it-strategy>. Acesso
em: 21 out. 2016.
IBM. The four V’s of Big Data. Big Data & Analytics Hub, [s.d]. Disponível em:
<http://www.ibmbigdatahub.com/infographic/four-vs-big-data>. Acesso em:
21 out. 2016.
LOSHIN, David. The practitioner’s guide to data quality improvement.

Burlington: Elsevier, 2011.
MANYIKA, James; CHUI, Michael; BROWN, Brad; BUGHIN, Jacques; DOBBS,

Richard; ROXBURGH, Charles; BYERS, Angela H. Big data: the next frontier
Big Data 37
for innovation, competition, and productivity. Citeulike. 2011. Disponível em:
<http://www.citeulike.org/group/18242/article/9341321>. Acesso em: 21 out.
2016.
MAYER-SCHONBERGER, Viktor; CUKIER, Kenneth. Big Data: como extrair vo-

lume, variedade, velocidade e valor da avalanche de informação cotidiana.
Tradução Paulo Polzonoff Junior. Rio de Janeiro: Campus, 2013.
MCAFEE, Andrew; BRYNJOLFSSON, Erik. Big Data: the management revolu-

tion. Harvard Business Review, 2012. Disponível em: <http://www.rosebt.com/
uploads/8/1/8/1/8181762/big_data_the_management_revolution.pdf>. Acesso
em: 21 out. 2016.
MILLER, H. Gilbert; MORK, Peter. From data to decisions: a value chain for Big
Data. IT Professional, v. 15, p. 57-59, jan./fev. 2013.

Capítulo 3
Arquitetura
Big Data
A arquitetura tradicional de processamento de dados é baseada em

unidades de armazenamento e clusters de processamento tradicionais.
Entretanto, eles são caros e dificultam a escalabilidade do sistema para
grandes volumes de dados (MAYER-SCHONBERGER; CUKIER, 2013).
Uma abordagem diferente para resolver esse problema é a imple-

mentação de processamento distribuído e paralelo com base em má-
quinas mais simples, derivado de computadores pessoais, para dimi-
nuir os custos.
Este capítulo vai apresentar a arquitetura de processamento massi-

vamente paralelo para Big Data. Além disso, analisará as arquiteturas
GoogleFS e HDFS, e os fundamentos do algoritmo MapReduce.
39
1 Processamento massivamente paralelo
A arquitetura para o processamento de grandes volumes de dados
tem as seguintes características: distribuída, paralela e redundante. Ela
é distribuída e paralela para contornar o problema da pouca confiabili-
dade do hardware, e redundante, pois a falha de qualquer nó (um pro-
cessador e uma unidade de armazenamento) não deve causar nenhum
efeito sobre o desempenho do sistema (GHEMAWAT; GOBIOFF; LEUNG,
2003). Assim, com base nessas características, podemos resumir al-
guns pontos sobre a arquitetura de processamento:
•• O tamanho típico dos arquivos utilizados por ela é sempre gran-

de. São comuns arquivos com vários gigabytes.
•• O seu sistema deve ser intrinsecamente tolerante a falhas. Dado

o tamanho dos clusters e o tipo de hardware utilizado, deve-se
considerar que a probabilidade de ocorrer uma falha em algum
dos nós é, para todos os efeitos, de 1 para 1.000, ou seja, o pe-
ríodo médio entre falhas (em inglês, mean time between failures
– MTBF) é menor que um dia.
•• A maior parte das alterações nos arquivos são acréscimos

(appends). Ou seja, as escritas em posições aleatórias são prati-
camente inexistentes. Em outras palavras, a grande maioria dos
acessos é para leitura e, geralmente, essa leitura é sequencial.
•• O tipo mais comum de processamento é em lote, ou batch, ao in-

vés de pequenos ciclos de leitura e escrita. Assim, o sistema deve
ser otimizado para garantir uma resposta contínua em termos de
consumo de banda, ao invés de ter uma latência pequena.
A Google foi a primeira empresa a criar uma plataforma para o

processamento massivamente paralelo. A plataforma é denominada

GoogleFS (GHEMAWAT; GOBIOFF; LEUNG, 2003). Posteriormente, sur-
giram outras arquiteturas, como a HDFS (APACHE HADOOP, 2016).

Vamos analisar essas duas plataformas mais detalhadamente a seguir.
2 Arquitetura GoogleFS
O Google File System (GoogleFS) utiliza uma arquitetura na qual os

arquivos são divididos em pedaços (chunks). Esses pedaços são distri-
buídos entre vários nós do cluster de armazenamento nos servidores
secundários (chunk servers) e são armazenados com redundância, de
modo que a falha de um nó não leva à perda de nenhuma informação.
Uma visão de alto nível da arquitetura GoogleFS é mostrada na figura

da página seguinte. O servidor mestre (master) possui uma ou várias
redundâncias, que podem assumir o controle rapidamente em caso de
falha. Ele distribui as atividades em diversos servidores secundários
que processam os arquivos previamente fracionados. O mapeamento
entre a aplicação e os servidores fica armazenado no servidor mestre,
e assim permite que a aplicação tenha o acesso direto aos servidores
intermediários. Todos os metadados do sistema de arquivos ficam ar-
mazenados no servidor principal ou em suas réplicas. Por exemplo, o
mapeamento entre arquivos e chunks está no servidor principal.
Neste ponto, é importante destacar o papel do servidor espelho,

que assume as funções do servidor principal em caso de falha. O
mapeamento entre a aplicação e os servidores fica armazenado no
servidor mestre, o que permite que a aplicação tenha acesso direto
aos servidores intermediários. Haverá a redundância dos arquivos nos
diversos servidores intermediários, o que, como aprendemos, é uma
forma de proteção.
Arquitetura Big Data 41

Figura 1 – Arquitetura GoogleFS
Arquivo 1
Partição 1
Servidor Arquivo 1
secundário Partição 2
ui vos
arq Arquivo 2
os
e sd
ar tiçõ Partição 1
sp
to à
o dire
ess Arquivo 1
Ac
Partição 2
Mapeamento Servidor Servidor Arquivo 1 Redundância

Aplicação Partição 1
principal secundário
Arquivo 2
Ac
ess
od Servidor
Partição 2
ire
to espelho
às
par Arquivo 1
tiç
ões
do Partição 2
sa
rqu
ivo Arquivo 2
s Servidor
secundário Partição 1
Arquivo 2
Partição 2
Fonte: adaptado de Ghemawat, Gobioff e Leung (2003).
Como podemos analisar na figura, a arquitetura GoogleFS é diferente

dos projetos de sistemas de arquivo tradicionais, pois nela há a redun-
dância dos arquivos nos diversos servidores intermediários, que atuam
como uma forma de proteção, e o acesso aos dados é feito diretamente
do cliente para o servidor secundário, evitando, assim, que o servidor
principal se torne um gargalo para a transmissão de dados (CHU, 2013).
3 Arquitetura HDFS
Hadoop distributed file system (HDFS) é um sistema de arquivos se-
melhante ao sistema GoogleFS. Ele utiliza blocos de 128 Mb, que são
maiores do que os blocos utilizados por sistemas de arquivo comuns

(APACHE HADOOP, 2016). Nesse sistema, cada bloco é equivalente a
um chunk. A próxima figura ilustra a arquitetura HDFS, que é baseada

em dois tipos de nós master/worker: o NameNode e o DataNode. Dentro
de cada nó de dados, as informações são separadas em blocos e são
replicadas em diferentes racks. Assim, uma informação que está no nó
de dados do rack 1, por exemplo, pode ser replicada para outro nó de da-
dos do rack 2. Dessa forma, o cliente faz o acesso aos nós de dados por
meio do NameMode, que tem os metadados (detalhes) de cada infor-
mação armazenada. Em outras palavras, o NameMode funciona como
um guia que armazena a localização de cada bloco de informação.
Figura 2 – Arquitetura HDFS
Operações de metadados NameNode Metadados (Nome, réplicas, ...):

/home/foo/data, 3,...
Cliente
Operações de dados
Leitura Nó de dados Nó de dados
Replicação
Rack 1 Escrita Rack 2
Cliente
Fonte: adaptado de Apache Hadoop (2016).
Como podemos analisar na figura, o cliente realiza o acesso aos

diversos nós de dados (DataNodes) por meio dos metadados dos
NameNodes. Os nós de dados são diversos e servem de base para um
grande conjunto de análises. Neles, os dados podem ser carregados e
transportados para outra forma de armazenamento, ou utilizados como
o próprio sistema de armazenamento de dados de uma aplicação.
Já o NameNode é um nó único em um cluster e mantém todos os

metadados do sistema de arquivos, como o mapeamento de arqui-
vos para blocos, permissões de arquivos, estruturas de diretórios, etc.

Opcionalmente, pode ser configurado um NameNode secundário e um
backup em uma pasta de rede compartilhada. Esse tipo de backup per-
mite recuperar o NameNode em caso de falha. Entretanto, essa recupe-
ração não é especialmente rápida.
IMPORTANTE
O HDFS será tão confiável quanto for o seu NameNode. Para ler ou
armazenar um arquivo, aplicações-cliente comunicam-se com o
NameNode para determinar apenas os DataNodes e os blocos que
devem ser acessados ou escritos. Após essa determinação, todo
fluxo de dados ocorre entre o cliente e o DataNode, de modo que o
NameNode nunca seja um gargalo para o funcionamento do sistema.
Para que a compreensão acerca do tema se torne mais fácil, va-

mos analisar as características de um modelo de arquitetura HDFS no
quadro 1.
Quadro 1 – Características da arquitetura HDFS
ITEM FUNCIONALIDADE
Ela pode funcionar sobre um sistema de arquivos comum, como o

Sistema de arquivos
Ext4 ou NTFS.
Implementa uma interface Filesystem in user space (Fuse). Portanto,

ele pode ser montado como um sistema de arquivos normal em
qualquer sistema Linux. No entanto, o HDFS não implementa uma
Interface
interface Portable operating system interface (Posix) completa. Em
particular, acréscimos e escrita em posição arbitrária em um arquivo
não são suportados.
O número de réplicas pode ser definido por arquivo. Assim, um

arquivo que precisa ser utilizado em muitas análises pode ter um
Redundância
fator de replicação mais alto que os outros, desse modo ele estará
localmente disponível em um número maior de nós.
(cont.)

ITEM FUNCIONALIDADE
Permite uma organização tradicional dos dados em diretórios e

Armazenamento
arquivos, e apresenta uma interface de linha de comando simples.
A abstração de blocos é separada dos detalhes de hardware. Isso

Sistema de arquivos permite trabalhar com arquivos que são maiores do que qualquer um
dos discos presentes no cluster.
NA PRÁTICA
O Twitter reporta que ele utiliza o próprio HDFS para armazenar e pro-
cessar arquivos de log e de tweets. O Facebook costuma carregar o
seu cluster HDFS com dados provenientes de seu banco de dados de
usuários, executar análises (como criar lista de amigos sugeridos) e
depois recolocar esses dados em seus bancos de dados para servir
aos usuários.
Uma vez apresentada as arquiteturas adequadas para o processa-

mento distribuído de dados, na próxima seção veremos como gerar
algoritmos de análise de grandes volumes de dados facilmente esca-
lonáveis e resilientes a falhas. Uma técnica é encontrar abstrações que
abrangem várias tarefas de análise e que são facilmente paralelizáveis.
Uma dessas abstrações é denominada MapReduce.
4 MapReduce
O MapReduce tem por fundamento duas operações comuns em
programas funcionais: o map e o reduce, originários de alguns dialetos
do LISt Processing (Lisp). Nessa linguagem, a lista é a estrutura de da-
dos fundamental: os dados e os programas são representados como
listas, o que permite que a linguagem manipule o código-fonte como
qualquer outro tipo de dados (DEAN; GHEMAWAT, 2004).

A função map recebe um par, composto de chave e valor, e retorna
uma lista de pares ordenados (chave2, valor2). As chaves não precisam
ser únicas. Um exemplo de chave seria o nome do arquivo-fonte para
leitura, e o valor, a linha do arquivo a ser aplicado a função map.
Por outro lado, a operação reduce recebe um par (chave2, lista de va-
lores2) e retorna um valor3. Os valores retornados por map que tinham
a mesma chave foram agrupados em uma lista. Intuitivamente, perce-
be-se que o estágio de map pode ser facilmente executado em paralelo.
Como exemplo apresentado por Dean e Ghemawat (2004), suponha-

mos uma aplicação na qual o objetivo é gerar uma lista com o número
de ocorrências de cada palavra em um grande conjunto de arquivos.
Nesse caso, pode-se configurar o MapReduce de modo que a entrada
seja uma lista de pares (nome do arquivo, conteúdo do arquivo). A fun-
ção map para esse exemplo é simplesmente:
def map(String nomeDoArquivo, String conteúdoDoArquivo)

for each palavra in conteúdoDoArquivo
Essa função emite um par intermediário para cada palavra existente

no arquivo (como o conteúdo do arquivo foi dividido em palavras, não
é relevante para o exemplo). Nota-se que, como o framework já agrupa
os pares intermediários pela chave, não é necessário consolidar o nú-
mero de vezes que uma palavra aparece no mesmo arquivo. O reduce
para essa aplicação é:
def reduce(String palavra, Iterator valores)

int total = 0
for each valor in valores

Nesse sentido, podem existir diferentes detalhes de implementação,
otimizados para diferentes casos. A implementação utilizada pela fer-

ramenta Hadoop será apresentada em um capítulo adiante.
NA PRÁTICA
Um exemplo de aplicação do algoritmo é o cálculo de frequência de

palavras em um conjunto de documentos. Considere que os docu-
mentos sejam significativamente grandes (gigabytes). Nesse caso,
mover a função map até o local onde o dado está armazenado e
executá-la nesse local é muito mais eficiente. Nota-se, portanto, que
ele não recebe a lista de valores explicitamente, mas um índice para
a lista. Isso permite a execução de listas cujo tamanho excede a me-
mória da máquina que está executando o reduce.
A figura a seguir apresenta a arquitetura do MapReducer. Podemos

analisar que o nó principal mantém um job tracker, que é o responsá-
vel por distribuir os processos e acompanhá-los. Em cada nó executor,
existe um task tracker, que será o responsável por executar a função
associada àquele nó (pode ser um map ou um reduce). Em geral, o task
e o job tracker mantêm uma comunicação frequente entre si, chamada
de heartbeat. Caso o job tracker passe um determinado período sem re-
ceber o heartbeat (sinal que continua ativo) do task tracker, ele assume
que aquela máquina ou processo falhou e dispara um novo processo
para cumprir a mesma tarefa. Em algumas implementações, quando
alguns nós terminam um processamento, o job tracker pode mandar
esse nó realizar um processamento que já foi passado para outro nó. O
primeiro resultado que estiver disponível será usado e os outros proces-
sos serão interrompidos.

Figura 3 – Arquitetura do MapReducer
Master Slave
Task tracker Task tracker
Job tracker
MapReduce layer
HDFS layer
NameNode
DataNode DataNode
Multi-node cluster
Fonte: adaptado de Apache Hadoop (2016).
Neste modelo, o nó master é composto pelo job tracker e tasks

tracker, sendo que ambos têm funções diferentes: o job distribui os pro-
cessos, enquanto o task os executa. Fazendo um paralelo, essa ação
é parecida com a comunicação entre o NameNode e o DataNode no
HDFS, na qual o NameNode executa a função de distribuir os processos
armazenados nos DataNodes. Em ambos os modelos existem nós sla-
ves com redundância de informação, sendo que no modelo MapReduce,
a redundância é um task tracker, e no HDFS é um DataNode.
NA PRÁTICA
Uma das características relacionada ao grande volume de dados é o

tempo de processamento dos dados. Dependendo do volume de da-
dos e da largura de banda da rede, o tempo gasto para mover esses
dados até um cluster de processamento passa a dominar o próprio
tempo de processamento. Para resolver esse problema, pode-se ex-
plorar o fato de que a função map precisa de uma visão apenas parcial
dos dados (definida pela chave do par de entrada). Esse fato pode ser
utilizado para, ao invés de mover os dados até o processamento, mo-
ver a função map até o nó onde os dados estão armazenados.

Este capítulo apresentou a arquitetura de Big Data e os fundamen-

tos do algoritmo MapReduce. A utilização da arquitetura HDFS pode
melhorar a análise dos dados, permitindo a integração de processos
e o compartilhamento de dados, informações e conhecimento. Ela se
mostrou uma arquitetura interessante para a extração, o refinamento e
a análise dos dados na medida em que melhora a velocidade e a capa-
cidade de sistematização das informações.
As implementações do MapReduce estão rapidamente ganhando

popularidade, uma vez que elas proveem modelos de programação
simplificados para armazenar e processar de forma escalável gran-
des conjuntos de dados, além de atender ao requisito não funcional de
hardware barato com baixa confiabilidade. Para isso, elas devem ser
tolerantes a falhas, da mesma forma que as arquiteturas GoogleFS e
HDFS apresentadas neste capítulo.
Por fim, caso o sistema de MapReduce tenha conhecimento de qual

servidor secundário contém cada arquivo, ele poderá executar a função
map no mesmo servidor. Assim, um sistema de MapReduce que co-
nheça o modo como os dados estão armazenados trará grandes van-
tagens em termos de velocidade.
Referências
APACHE HADOOP. HDFS users guide. The Apache Software Foundation. 2016.
Disponível em: <http://hadoop.apache.org/docs/current/hadoop-project-dist/
hadoop-hdfs/HdfsUserGuide.html>. Acesso em: 29 nov. 2016.
DEAN, Jeffrey; GHEMAWAT, Sanjay. MapReduce: simplified data processing

on large clusters. Sixth symposium on operating system design and

implementation (OSDI). San Francisco, 2004. Disponível em: <https://static.
googleusercontent.com/media/research.google.com/pt-BR//archive/mapre-
duce-osdi04.pdf>. Acesso em: 29 nov. 2016.
GHEMAWAT, Sanjay; GOBIOFF, Howard; LEUNG, Shun-Tak. The Google File

System. Symposium on operating systems principles (SOSP). New York,
2003. Disponível em: <https://static.googleusercontent.com/media/research.
google.com/pt-BR//archive/gfs-sosp2003.pdf>. Acesso em: 29 nov. 2016.


Capítulo 4
Ingestão
de dados
A ingestão de dados é um dos elementos mais críticos de um pro-

cesso de Big Data e a parte mais trabalhosa e invisível para o usuário fi-
nal. Podemos fazer uma analogia à ponta de um iceberg, o que significa
que esta atividade é apenas o começo (ou uma pequena parte) de um
processo muito maior e complexo.
Geralmente, as fontes de dados são construídas ao longo de anos

e os dados são descritos e armazenados nelas em muitas e diferentes
formas. Porém, esse grande volume de dados e de sistemas desenvol-
vidos isoladamente causa alguns efeitos colaterais indesejados, como
o problema da interoperabilidade dos dados.
51
Este capítulo vai apresentar as técnicas utilizadas para a ingestão de
dados. Além disso, analisará os diversos tipos de dados nos quais po-
dem ser feitas coletas de dados, os aspectos relacionados à integração
dos dados e os fundamentos da interoperabilidade dos dados.
1 Tipos de dados
Os tipos de dados se referem ao critério “variedade”, que já foi des-
crito em um capítulo anterior. A figura a seguir ilustra os diferentes tipos
de dados; eles podem ser classificados em dados estruturados, não es-
truturados e dados semiestruturados (que pode ser descrito como uma
mistura de ambos).
Cerca de 20% dos dados são do tipo estruturados, que são os dados
que podem ser organizados em colunas e linhas. Já os outros 80% são
os dados não estruturados, como os anexos de e-mail, um áudio ou ví-
deo, documentos, faturas, formulários, raio-X, Rich media, entre outros.
Vamos aprender sobre eles nas próximas seções.
Figura 1 – Tipos de dados
20%
ESTRUTURADO
Linhas e colunas 80%
NÃO ESTRUTURADO
Anexos de e-mail
Áudio/vídeo
Contratos
Documentos
Faturas
Formulários
Imagens
Manuais
Mensagens instantâneas
Páginas Web
PDFs
Raios-X
Rich media
Verificações

1.1 Dados estruturados
Os dados estruturados são aqueles organizados segundo um pa-

drão rígido e predefinido, respeitando diversos critérios, como:
•• Campos: os atributos de dados.
•• Extensão do campo: o tipo de dado.
•• Domínio: os valores possíveis do dado.
NA PRÁTICA
Em geral, é possível descrever os dados estruturados por meio de

linhas e colunas e organizá-los em tabelas. Esse é o caso, por exem-
plo, dos dados envolvidos em tabelas de SGBD relacionais usados
pelos sistemas de informação na maioria das organizações. Confor-
me apresentado na figura, eles representam apenas 20% dos dados
disponíveis atualmente.
1.2 Dados não estruturados
Os dados não estruturados são aqueles para os quais nenhum es-

quema é especificado, contendo apenas o conteúdo da informação e
uma forma de apresentá-lo. São exemplos:
•• Arquivos textos: NF-e, escriturações contábeis, páginas HTML,

documentos escritos em linguagem natural, etc.
•• Áudios: gravações de áudio em geral, como registros de escutas

telefônicas, áudio de vídeos, etc.
•• Imagens e vídeos: gravações de vídeo em geral, como os prove-

nientes de câmeras de segurança, vídeos do YouTube, etc.
•• Dados analógicos de sensores: sonar, georradar (ground-penetra-

ting radar – GPR), etc.
Ingestão de dados 53
IMPORTANTE
Conforme analisamos na figura, os dados não estruturados são os
dados mais comuns e representam 80% das fontes de dados dispo-
níveis atualmente.
1.3 Dados semiestruturados
Os dados semiestruturados são aqueles que possuem característi-

cas dos tipos estruturados e não estruturados. Ou seja, são dados hete-
rogêneos sem uma estrutura regular ou, ainda, que têm uma estrutura
capaz de evoluir de forma imprevisível. Assim, essa estrutura de dados
pode ser implícita, pois os tipos de dados são apenas indicativos e, além
disso, podem ser incompletos. Assim, alguns de seus atributos gerais e
imprescindíveis podem ser conhecidos a priori, enquanto outros podem
ser acrescentados posteriormente conforme as circunstâncias.
NA PRÁTICA
As referências bibliográficas são um exemplo de conjunto de dados

semiestruturados, contendo itens parecidos.
2 Coleta de dados
A coleta de dados de Big Data é semelhante ao processo de ETL,
aprendido no capítulo 1. A coleta é um processo sistematizado que está
constantemente transferindo dados para um ambiente de carga. Ela
não é executada uma única vez para responder a uma demanda especí-
fica, mas periodicamente para atender a diversas demandas de análise

(MAYER-SCHONBERGER; CUKIER, 2013). A arquitetura de coleta de da-
dos é formada por três camadas (TURBAN, 2009), as quais dão origem
aos processos de extração, de manipulação de dados e de carga, que
serão apresentados posteriormente. As camadas são:
1. Camada de dados operacionais: ela é composta pelas fontes de

dados nos mais diversos tipos (variedade).
2. Camada de concentração: a área de concentração (data lake, em

inglês) é fundamental para a conciliação dos dados provenientes
dos mais diversos sistemas de origem. Ela fica no back room (ou
sala dos fundos, em português). A camada de concentração é o
“canteiro de obras” onde a coleta de dados é construída.
3. Camada de carga: após a manipulação dos dados, é necessário

carregá-los para a respectiva base que tem, em geral, um mode-
lo de dados diferente da fonte de dados de origem. Alguns mo-
delos relacionados ao Big Data serão apresentados no próximo
capítulo.
Figura 2 – Camadas e processos da coleta de dados
Camada de Camada de Camada

dados operacionais concentração de carga
Manipulação de dados
Extração Carga
PARA PENSAR
Construir uma base de análise sem montar o processo de coleta de
dados correspondente a querer que uma torneira funcione, fornecendo
constantemente água de boa qualidade, sem que haja por trás dela todo
um complexo sistema de fornecimento de água.
2.1 Processo de extração

O processo de extração atua sobre as fontes de dados no critério va-
riedade (TURBAN, 2009). Em geral, tais fontes contêm uma quantidade
muito grande de dados, que foram coletados pelos sistemas legados ao
longo dos anos. Em outras palavras, a extração de dados é o primeiro
passo no sentido de “cavar” o iceberg e dar nova vida aos dados que ali
são enterrados a cada dia. Como sabemos, existem diferentes tipos e
formatos de dados: alguns são mais comuns e utilizados por boa parte
das pessoas, como “.doc”, “.txt”, “.mp3” e “.jpg”, etc., enquanto outros
são mais específicos e utilizados por profissionais da área de tecnologia
da informação (TI), como os formatos “.xml”, “.csv”, “.css” e “.html”, por
exemplo.
Figura 3 – Variedade de dados

PARA PENSAR
Um processo de extração exige uma avaliação criteriosa para definir

a qualidade e o significado da informação. O aspecto de qualidade de
dados foi tratado em outro capítulo. O primeiro impacto do significa-
do da informação ocorre sobre o sistema de transformação de dados,
também conhecido como manipulação de dados, que será detalhado
na próxima seção e, posteriormente, sobre os aspectos de integração
e interoperabilidade dos dados, que serão apresentados mais à frente
neste capítulo.
2.2 Processo de manipulação dos dados
O processo de manipulação dos dados é a fase de ajuste do dado

que pode envolver o desmembramento ou a composição de dados
(TURBAN, 2009). Ele consiste em várias operações feitas sobre os da-
dos extraídos para torná-los mais adequados para as análises. As tare-
fas de manipulação de dados são:
•• Eliminação de dados redundantes: eliminação de duplicações ou

de fragmentos de dados inúteis para a análise.
•• Eliminação de dados inconsistentes: limpeza dos dados e a re-

solução de conflitos, tais como a correção de erros ortográficos, e
de situações inconsistentes, como a associação de um município
a um código postal incompatível.
•• Recuperação de dados ausentes: obtenção de dados faltantes. A

combinação de dados provenientes de fontes diferentes pode ser
feita por meio de verificação da coincidência exata.
•• Transformações de dados: elaboração de dados derivados por

meio de sua adequação para formatos de entrada para algorit-
mos. São exemplos de transformação:
◦◦ idade em faixa etária;
◦◦ renda em classe econômica;
◦◦ data de nascimento em idade.
2.3 Processo de carga
O processo de carga acrescenta novas informações à base de dados

existente, sem perder nenhuma das informações que já estão armaze-
nadas (TURBAN, 2009). Os dados são carregados em lote (batch) e em
paralelo. Depois de carregados, os dados são indexados. Esta é a etapa
final do processo de coleta de dados.
PARA SABER MAIS
Durante o processo de carga, podem acontecer alguns erros. Em ge-

ral, o limite aceitável de erros é de 1% do total da coleta de dados.
Até este limite, a carga continua. Acima de 1% de erros, a etapa é
rejeitada (TURBAN, 2009).
3 Integração dos dados

A integração dos dados de Big Data é de fundamental importância e
deve ser considerada tanto do ponto de vista da arquitetura da solução
quanto da sua engenharia. Ela não acontece por acaso: requer compre-
ensão profunda dos sistemas-fonte, modelagem dos dados, adoção de
padrões e um sistema de transformação que manipule os dados prove-
nientes de diversas origens a fim de que possam conviver harmoniosa-
mente em uma mesma análise.
A integração é feita por meio da manutenção das fontes de origem

para que elas trabalhem de forma integrada, mesmo porque muitas

vezes os sistemas de origem são externos à organização e não há ges-
tão sobre a manipulação dessas fontes. Há duas formas de aborda-

gem para a integração do Big Data. A próxima figura ilustra as duas
abordagens.
•• A bottom-up: ela é feita de forma desconectada, ou seja, por cada

departamento isoladamente, criando sérios problemas de incon-
sistência entre as diversas fontes.
•• A top-down: uma única equipe tem que identificar todas as ne-

cessidades de informações das diversas comunidades, analisan-
do o acervo de dados presente em todos os sistemas-fontes.
Figura 4 – Abordagens de integração do Big Data
Top-down
Bottom-up
Em resumo, a abordagem bottom-up é mais utilizada para a cria-

ção de pequenas bases isoladas de análise; já a abordagem top-down é
mais comum quando pretendemos fazer análises em nível global. Cada
tipo de abordagem tem suas vantagens e desvantagens, conforme o
quadro 1.
Quadro 1 – Abordagens de integração dos dados
ABORDAGEM VANTAGENS DESVANTAGENS
• Dificuldade em conhecer
o patrimônio de dados da
• Totalmente integrado organização e todos os sistemas
• Visão como um todo legados.
• Repositório de metadados • Dificuldade em entender as

Top-down
centralizados necessidades informacionais
de todos os interessados nos
• Processos centralizados de
resultados de uma análise.
manutenção e monitoração
• Implementação muito longa.
• Alta taxa de risco.
• Cria repositórios independentes.

• Perpetua visões de contexto
• Foco em um determinado contexto incompatíveis.
Bottom-up • Implementação rápida • Consagra análises que não
• Retorno rápido podem ser comparadas entre si.
• Torna-se uma nova fonte de
dados sem integração.
O tipo top-down possui um sistema totalmente integrado, o que ga-

rante uma visão do processo como um todo. Os seus repositórios de
metadados são centralizados, permitindo processos centralizados de
manutenção e monitoração. Porém, esse modelo exige um longo tempo
de implementação e tem uma alta taxa de risco. Além disso, apresenta
dificuldade em executar algumas tarefas, como conhecer o patrimônio
de dados e entender as necessidades de geração de análise de dados
de todos os envolvidos.
Já o tipo bottom-up tem o foco em um contexto específico. Sua im-

plementação é mais veloz, o que garante um retorno rápido de resulta-
dos. Esse modelo, porém, exige a criação de repositórios independentes
que não podem ser comparados entre si, impossibilitando a integração
de novas fontes de dados.

4 Interoperabilidade dos dados
Nos anos recentes, os dados têm assumido um papel imprescindível

na cooperação entre organizações e entre indivíduos. Eles são frequen-
temente compostos a partir da integração de serviços eletrônicos hete-
rogêneos, cruzando fronteiras organizacionais e interligando diversos
processos de negócio (AALST; HEE, 2004).
Nesse contexto, a interoperabilidade é elemento-chave para a viabi-

lização da cooperação entre organizações e o sucesso do intercâmbio
de informações. Ela pode ser vista como a capacidade de os sistemas
operarem em conjunto, trocando informações e compartilhando fun-
ções (HAGEL; BROWN, 2001). Obstáculos à interoperabilidade surgem,
principalmente, do fato de os sistemas que apoiam as funções em mui-
tas organizações serem geralmente criados de forma independente e
não compartilharem os mesmos termos e vocabulários para as regras
de negócio da organização.
No sentido amplo, interoperabilidade é a habilidade de pessoas, or-

ganizações e sistemas interagirem e se interconectarem para a troca e
o uso da informação, eficiente e efetivamente. Já a interoperabilidade
de sistemas é entendida como a capacidade de dois ou mais sistemas
ou componentes trocarem e usarem informações sem esforço especial
por parte de cada sistema (HAGEL; BROWN, 2001).
A interoperabilidade pode ser dividida em três categorias (ARMS et

al., 2002):
•• Acordo técnico: trata de formatos de dados, protocolos e ques-

tões relacionadas à segurança.
•• Acordo de conteúdo: trata dos dados e metadados, incluindo

acordos da semântica ou interpretação da informação.
•• Acordo organizacional: trata das regras básicas de acesso, pre-

servação de coleções e serviços, pagamento e autenticação.
Este capítulo apresentou as técnicas utilizadas para a ingestão de
dados. A ingestão de grandes volumes de dados requer técnicas e tec-
nologias avançadas de Big Data. A coleta de dados é a parte mais tra-
balhosa e invisível para o usuário final: ela é a ponta de um iceberg no
oceano do Big Data.
A unificação da extração de dados relativos a cada sistema-fonte

é o que garante a integração dos dados. Assim, o processo de trans-
formação deve ser implementado de forma a atender às demandas de
extração de dados de um mesmo sistema-fonte, gerando uma única
demanda de extração periódica.
A manipulação de dados deve estar constantemente em alteração,

tanto para atender à inclusão de novas fontes de dados como para ade-
quar-se às mudanças dos sistemas-fonte. Para facilitar essa constante
“transformação” do processo, é importante que ele seja implementado
com ferramentas que tenham interface gráfica e viabilizem uma docu-
mentação técnica mais precisa e integrada.
A administração das etapas de coleta de dados pode ser feita por

meio de programas utilitários, que permitem verificar o status de cada
etapa. Ao final do processo de carga, é possível ao cientista de dados
corrigir os erros manualmente e rodar novamente a carga. Ao rodar uma
segunda vez a carga, uma nova tentativa de carga é feita e o processo
se encerra.
Por fim, a integração de dados requer o envolvimento efetivo dos

usuários finais, a fim de obter uma definição precisa dos pontos de
integração desejados entre as informações provenientes de origens
diversificadas.

Referências
AALST, Wil van der; HEE, Kees van. Workflow management: models, methods,
and systems (information systems). Cambridge: MIT Press, 2004.
ABRIAL, Jean Raymond. Data semantics. In: KLIMBIE, J. W.; KOFFEMAN, K. L.

Database management. Amsterdã: North-Holland, 1974.
ARMS, William Y. et al. A spectrum of interoperability: the site for science

prototype for the NSDL. D-Lib Magazine, v. 8, n. 1, jan. 2002. Disponível em:
<http://www.dlib.org/dlib/january02/arms/01arms.html>. Acesso em: 22 nov.
2016.
HAGEL, John; BROWN, John S. Your next IT strategy. Harvard Business Review,
2001. Disponível em: <https://hbr.org/2001/10/your-next-it-strategy>. Acesso
em: 21 out. 2016.
MAYER-SCHONBERGER, Viktor; CUKIER, Kenneth. Big Data: como extrair

volume, variedade, velocidade e valor da avalanche de informação cotidiana.
Bookman, 2009.
64
Capítulo 5
Modelagem de
dados
O objetivo da modelagem de dados é reduzir a complexidade da

porção do universo que está sendo estudado, capturando somente as
características que se deseja estudar em uma situação específica. Em
outras palavras, nós modelamos para entender e representar o mundo.
Este capítulo vai apresentar algumas técnicas utilizadas para a mo-

delagem de dados de Big Data. Para isso, vamos analisar o modelo
multidimensional, o NoSQL e a UML estendida. O modelo multidimen-
sional de dados é o primeiro passo para gerar informações de apoio
aos cientistas de dados e ao processo decisório. Posteriormente, novas
soluções surgiram, como o modelo NoSQL e a UML estendida.
65
1 Modelo multidimensional
A modelagem dimensional surgiu na década de 1990, mas é utili-
zada há bastante tempo, antes mesmo de receber esse nome. O con-
ceito tem origem na matemática dos eixos coordenados de Descartes,
nos vetores n-dimensionais ou matrizes da álgebra linear (KIMBALL;
CASERTA, 2004).
O foco da modelagem dimensional é o cruzamento de variáveis. Em

uma linguagem matemática, é o produto cartesiano de n variáveis. Ao
resultado, ou vetor de dimensão n, estão associadas as medidas de in-
teresse para o usuário.
NA PRÁTICA
Imagine uma empresa que vende mercadorias em diversas localida-

des. Deseja-se acompanhar o seu desempenho ao longo do tempo.
A partir dessa declaração é imediata a imagem de um cubo, cujas
arestas são mercadorias, localidades e tempo. A visualização do
cubo será apresentada no capítulo 8. Nas interseções de cada três
valores provenientes dessas arestas estão armazenadas medidas,
como preço e custo, que podem ser operadas para se obter indica-
dores de desempenho.
A simplicidade é a característica mais importante, e deve ser busca-

da na modelagem dimensional. O modelo dimensional é o catálogo de
produtos a ser utilizado pelo usuário no seu passeio pelo supermerca-
do de informações. Portanto, deve ser simples o bastante para orientar
sem confundir (KIMBALL; CASERTA, 2004).
Para melhor atender às necessidades de representação das infor-

mações, distinguem-se duas modalidades de modelo dimensional
(TURBAN et al., 2009):

•• O conceitual: retrata a forma como o ambiente informacional se
manifesta para os usuários via ferramenta OLAP (online analytical

processing).
•• O físico: retrata a realização ou fiscalização do modelo dimensio-

nal no contexto do banco de dados hospedeiro.
Se analisarmos o modelo dimensional representado na figura a se-

guir, podemos notar que ele é completamente previsível (TURBAN et al.,
2009). Assim, podemos resumir sua representação como um diagrama
de tabelas conectadas entre si. Há uma dessas tabelas que se sobres-
sai no centro do diagrama, conectada com as demais tabelas ao seu
redor, em uma disposição radial. A tabela central é denominada tabela
de fato e as demais tabelas, de dimensão. Em geral, deseja-se estudar
os valores que as variáveis dependentes (fatos) assumem para cada
combinação possível das variáveis independentes (dimensões), dentro
do universo delimitado. As tabelas fato e dimensão serão apresentadas
nas próximas seções.
Figura 1 – Modelo multidimensional de dados
Dimensão A
Dimensão E Dimensão B
Fato
Dimensão D Dimensão C
Modelagem de dados 67
Aqui só é possível um tipo de relacionamento, um para n. Ou seja,
um único registro do atributo de contato da dimensão para zero ou
mais registros da tabela de fatos. Em termos de implementação física,
conjuntos de fatos dão origem a uma tabela de fatos, também conheci-
da como tabela fato. Vamos ver um exemplo na prática.
NA PRÁTICA
Por exemplo, no cruzamento das dimensões LOJA, DIA e PRODUTO

podemos encontrar: “Editora SENAC, 1/1/2017, Arquitetura de Big
Data” e, associado à dimensão fato as medidas: vendas R$ 33,00,
custo R$ 22,00, quantidade vendida 11.
1.1 Dimensão
As dimensões fornecem os valores que atuarão como cabeçalhos

de linha e são as variáveis independentes. Elas costumam conter valo-
res descritivos (texto) ou, quando codificadas, variáveis numéricas dis-
cretas, sendo que a cada valor se associa um texto.
Em cada dimensão existe um único atributo, de maior detalhamen-

to, que se relaciona com uma dada tabela de fatos. Ele é conhecido
como “atributo de contato da dimensão”. É por meio desse atributo
de contato que a dimensão é “espetada” na tabela de fatos, formando
uma figura radial.
Em outras palavras, uma dimensão contém uma ou mais variáveis

com alguma afinidade e que são denominadas de atributos dimensio-
nais, ou simplesmente atributos. Em termos de implementação física,
cada dimensão dá origem a uma tabela.

1.2 Fato
Os fatos fornecem os valores que serão apresentados no centro

da tabela e são as variáveis numéricas dependentes que assumem
valores contínuos, denominados fatos. Eles são o foco da curiosidade
do cliente ou então as medições numéricas do negócio também de-
nominados métricas.
As métricas são fórmulas matemáticas que atuam sobre os fatos,

de forma a permitir a agregação de muitos registros em um único re-
gistro. Elas podem ser de dois tipos:
•• Métricas básicas: definem a operação de adição sobre um único

fato.
•• Métricas derivadas: utilizam outras operações derivadas sobre

diversos fatos e sobre outras métricas, como o percentual que
um determinado valor representa em um total.
PARA SABER MAIS
Como reconhecer se uma variável numérica é uma coisa ou outra?

Na verdade, não se trata de reconhecer. A questão a ser colocada é
outra: de que forma uma variável numérica vai ser apresentada para
os usuários? Para ser apresentada como cabeçalho de linhas, a va-
riável será modelada como atributo dimensional; para ser apresen-
tada como o núcleo de tabelas, a variável será modelada como fato.
No entanto, caso se deseje as duas formas de apresentação, a mes-
ma variável poderá ser modelada simultaneamente como atributo
dimensional e como fato. Tal duplicidade de papéis seria inaceitável
no modelo entidade-relacionamento.
Acabamos de descobrir uma característica muito interessante da

modelagem dimensional. Estamos modelando não somente o que os
dados são, mas também a forma como os dados devem ser visualiza-
dos pelo usuário.
2 NoSQL
Os bancos de dados NoSQL (not only structured query language) via-
bilizam o armazenamento distribuído de dados sem exigir uma estru-
tura ou formatação específica, e a criação de modelos de dados que
favoreçam o seu uso para leitura (SADALAGE; FOWLER, 2013). Eles
não possuem consistência e junções (joins) entre seus dados, embo-
ra alguns tipos de consistências fracas e suporte a transações são
suportados.
Portanto, os bancos NoSQL não possuem as restrições do modelo

que segue o padrão ACID (atomicidade, consistência, isolamento e du-
rabilidade) (MAYER-SCHONBERGER; CUKIER, 2013).
Existem diversos tipos de banco de dados NoSQL, cada qual com

uma modelagem de dados própria (SADALAGE; FOWLER, 2013). Eles
são divididos em bancos orientados a documentos ou colunas, tipo
chave-valor e grafos. Eles serão apresentados nas próximas seções.
PARA SABER MAIS
Recentemente têm surgido novas tecnologias híbridas que procu-

ram compatibilizar a organização do mundo relacional SQL com a
flexibilidade e escalabilidade do modelo NoSQL. Elas têm o obje-
tivo de tornar-se uma alternativa viável para trabalhar com dados
massivos de forma distribuída, suportando tabelas flexíveis e ainda
mantendo uma grande compatibilidade com o padrão SQL (MAYER-
-SCHONBERGER; CUKIER, 2013).
2.1 Orientado a documentos
O banco de dados orientado a documentos tem esse nome porque

modela os dados na forma de documentos. Esses documentos são co-
leções de atributos e valores (SADALAGE; FOWLER, 2013).

Em geral, os bancos de dados orientados a documento não possuem
esquema. Ou seja, os documentos armazenados não precisam ter uma

estrutura em comum. Essa característica faz deles boas opções para
o armazenamento de dados semiestruturados. É comum esse tipo de
banco de dados usar algum formato de armazenamento, como o JSON,
que permite embutir uma estrutura em outra (ou seja, um documento
embutido em outro).
2.2 Orientado a colunas
O banco de dados orientado a colunas modela os dados como um

mapa multidimensional. Assim, os valores, que são as células da tabela,
são indexados pelas chaves: nome da tabela, chave da linha, chave da
coluna e tempo da operação (SADALAGE; FOWLER, 2013).
A principal vantagem desse tipo de banco é a facilidade de arma-

zenamento e recuperação dos dados. Por outro lado, há uma grande
dificuldade de recuperar dados específicos, principalmente de resultado
de registros com características semelhantes.
2.3 Orientado a chave-valor
O banco de dados orientado a chave-valor modela os dados sem um

esquema predefinido e representado com uma coleção de pares chave-
-valor. O banco armazena um valor (de qualquer tipo) acessível por uma
chave única, podendo estar codificado em padrões como JSon, XML,
PDF, etc. (SADALAGE; FOWLER, 2013).
2.4 Grafos
Ao desenvolvermos uma aplicação, geralmente nos deparamos com

a situação de trabalharmos com o banco de dados relacional, realizando
diversas consultas complexas. Tais consultas (queries) podem ter essa
complexidade devido ao fato de estarmos modelando dados que não
são naturais ao paradigma relacional, em um banco relacional.
O banco de dados orientado a grafos armazena dados com ligações

entre si, formando um grafo. Um grafo é formado por vértices, arestas e
propriedades. O gerenciamento de dados é realizado por meio de estru-
turas diferenciadas e consultas complexas.
3 UML estendida
A UML na versão 2.2 é composta por quinze diagramas, divididos
nas categorias estruturais, ou estáticos, e dinâmicos (OMG, [s/d]). Os
estruturais têm o objetivo de mostrar as características que não mu-
dam com o tempo; já os dinâmicos mostram como o modelo evolui
durante o tempo. A UML é composta por diversos elementos básicos
que representam as diferentes partes de um sistema, como: classe, in-
terface, nota, pacote, caso de uso, atividades, dentre outros.
Entretanto, a linguagem UML possui algumas limitações relaciona-

das à modelagem de Big Data. Uma limitação é que, no diagrama de
classes, as decisões de modelagem são deixadas por conta do enge-
nheiro do conhecimento, e permanecem implícitas em sua mente, pre-
judicando a precisão da comunicação e o compartilhamento da infor-
mação (GUIZZARDI, 2005).
Por outro lado, essa linguagem permite a criação de mecanismos

de extensão que possibilitam modificar os elementos da própria lingua-
gem. Isso acontece por meio de elementos próprios denominados es-
tereótipos, de valores de etiqueta e de restrições (UML, s/d).
Uma proposta nesta direção é feita por Guizzardi (2005), em que o

metamodelo do diagrama de classes da UML é estendido para incorporar
algumas propriedades ontológicas. Tal processo deu origem à linguagem
chamada de OntoUML, a qual será apresentada a seguir.

3.1 OntoUML
Para a comunidade de ciência da computação, o termo se refere a

um artefato de engenharia, constituído de um vocabulário de termos or-
ganizados em uma taxonomia, suas definições e um conjunto de axio-
mas formais usados para criar novas relações e para restringir as suas
interpretações segundo um sentido pretendido (MACHADO, 2013).
Já há bastante tempo, filósofos têm usado ontologia para descrever

domínios naturais, ou seja, as coisas naturais do mundo, como os tipos
de existência e as relações temporais. Ontologias, no sentido filosófico,
têm sido desenvolvidas em filosofia desde Aristóteles.
Neste livro, ontologias são tratadas como um artefato computacio-

nal composto de um vocabulário de conceitos, suas definições e suas
possíveis propriedades; e um modelo gráfico mostrando todas as pos-
síveis relações entre os conceitos, representando de maneira clara e
não ambígua o conhecimento do domínio. O artefato é denominado
OntoUML (ontological unified modeling language) (GUIZZARDI, 2005).
Guizzardi (2005) redesenhou essa linguagem a partir da versão 2.0

da linguagem UML. A principal diferença é que ele acrescentou nessa
linguagem redesenhada um conjunto de características ontológicas.
Assim, podemos definir a OntoUML como um perfil UML composto por
um conjunto de estereótipos que representam as categorias ontoló-
gicas, bem como por restrições formais de tal modo que se restringe
o conjunto de modelos àqueles que representam situações admissí-
veis segundo uma ontologia bem-fundamentada denominada Unified
Foundation Ontology (UFO) (GUIZZARDI, 2005). Esta linguagem tem
sido aplicada com sucesso em diversos projetos em diferentes domí-
nios, desde petróleo e gás até bioinformática.
Para entendermos como funciona esse modelo, vamos analisar a

figura 2.
Figura 2 – Exemplo de diagrama OntoUML
<<phase>>
Criança
<<subkind>> <<role>>
<<phase>> Homem Esposo
Adolecente
<<kind>> <<material>> <<relator>>
<<phase>> Pessoa casadoCom Casamento
Adulto <<subkind>> <<role>>
Mulher Esposa
<<phase>>
Idoso
Fonte: adaptado de GUIZZARDI (2005).
O primeiro tipo é denominado rígido e compreende todos os demais

tipos; é representado por “<<kind>>”. Por ser o primeiro, consideramos
este tipo como um tipo raiz. O tipo “kind” é o único tipo rígido instancia-
do em todas as situações e, consequentemente, ele define a estrutura
estável do modelo.
Em nosso exemplo, vamos considerar que “kind” seja uma pessoa.

Dentro desse tipo ainda é possível ter atributos, como nome, idade, CPF,
etc., algo semelhante ao diagrama de classes da UML.
Dentro do tipo “kind” temos um subtipo, uma especialização, repre-

sentado por “<<subkind>>”. Continuando o nosso exemplo, o “subkind”
de pessoa é homem e mulher, pois ambas as instâncias não podem
mudar, mas compartilham um princípio de identidade comum, que é
ser uma pessoa.
Dentro do diagrama ainda temos o tipo denominado antirrígido, que

se divide em duas subcategorias:
•• Papéis: “<<role>>”.
•• Fases: “<<phase>>”.
Esses elementos são considerados antirrígidos, pois a sua classifi-

cação é dinâmica, ou seja, as suas instâncias podem se mover entre

estes tipos sem nenhum efeito na identidade da instância. A diferença
entre papéis e fases é que no primeiro tipo as mudanças ocorrem nas

suas propriedades relacionais, enquanto no segundo, por mudanças in-
trínsecas nas propriedades das instâncias. Para ficar mais fácil, vamos
analisar no exemplo como seriam esses tipos.
O “<<role>>”, neste exemplo, seria o “esposo” (ou esposa), que é um

papel relacionado a uma pessoa dentro de um contexto relacional, ou
seja, uma pessoa só é um “esposo” ou “esposa” no contexto de um ca-
samento. Ele pode deixar de ser esposo, voltar a ser esposo, e assim por
diante. Entretanto, em todas as situações, ele mantém a sua identidade
de pessoa.
Já em nosso exemplo, podemos definir como “phase do kind pessoa”

os estágios da vida: uma criança, um adolescente, um adulto ou um ido-
so. Veja que, neste caso, a mudança é de uma propriedade intrínseca da
pessoa. Assim, uma pessoa adulta não pode voltar a ser uma pessoa
criança, porém ela continua existindo como pessoa.
Os elementos são conectados com as outras entidades por meio

de relações. Em OntoUML há tipicamente duas categorias de relações:
•• As relações formais: <<formal>>.
•• As relações materiais: <<material>>.
As relações formais conectam duas ou mais entidades diretamente,

sem a intervenção de nenhum outro indivíduo, e tratam de aspectos in-
trínsecos de um objeto ou de aspectos internos da linguagem. Ou seja,
essas relações podem ser “parte-de”, “subconjunto-de”, instanciação,
dentre outras. As relações materiais, diferentemente, possuem uma
estrutura material e tratam de aspectos externos ao objeto. Elas dão
origem aos aspectos relacionais denominados <<relator>>. Portanto, os
aspectos relacionais são derivados das relações materiais e, em geral,
estão escondidos atrás das relações materiais.
Voltemos ao nosso exemplo: a relação material seria a relação
que o objeto tem com o outro. Ou seja, o esposo tem uma relação
“casadoCom” a esposa. Mas essa relação esconde um aspecto que é o
casamento, e possui características próprias, como a data do casamen-
to, local, testemunhas, etc. Portanto, o <<relator>> seria o casamento,
já que é este contexto relacional que determina o papel (role) dos dois
objetos. Ou seja, se o papel de um “subkind” é ser esposo, logo a relação
que ele tem é um casamento.
Ressalta-se que sem a explicitação do conceito casamento, todos

os seus detalhes ficariam escondidos atrás da relação “casadoCom”, e
invisíveis e desprezados.
Este capítulo apresentou as técnicas utilizadas para a modelagem
de dados para Big Data. Um modelo representa uma parte da realidade
que vai ser representada por ele. Sendo assim, não existe técnica de
modelagem melhor ou pior. O que existe é o modelo mais adequado a
esse ou àquele propósito.
Neste contexto, os modelos apresentados não se excluem mutua-

mente, pois cada um deles tem a sua aplicação.
No modelo dimensional, o usuário da informação tem uma visão de

quais dados estão disponíveis e quais cruzamentos podem ser realiza-
dos na construção das consultas. É um mapa das informações da ma-
neira como serão acessadas pelo usuário final, não necessariamente
como estão organizadas. As dimensões e fatos servirão para se cons-
truir restrições do que entra ou não no relatório. No entanto, dimensões
serão utilizadas com mais frequência na construção dessas restrições.
Já nos modelos NoSQL, as tabelas não possuem uma estrutura fixa

de colunas, ou seja, estas podem ser adicionadas e removidas de forma

dinâmica. A flexibilização desse modelo favorece a simplicidade da mo-
delagem, a escalabilidade horizontal e um maior desempenho. Para a

consulta dos dados, esses bancos de dados fornecem outros mecanis-
mos de consulta alternativos à tradicional linguagem SQL.
Por fim, a linguagem OntoUML permite expressar mais sobre o do-

mínio e, além disso, ela obriga a explicitação de uma grande quantidade
de conhecimento que fica escondido atrás de relações materiais. Os
elementos “kind”, “subkind”, “role” e “phase” representam a maior parte
dos elementos encontrados nos domínios da realidade.
Referências
GUIZZARDI, Giancarlo. Ontological foundations for structural conceptual
models. CTIT PhD Thesis Series – Telematica Instituut, Enschede, 2005.
KIMBALL, Ralph; CASERTA, Joe. The data warehouse ETL toolkit: practical
techniques for extracting, cleaning, conforming, and delivering data. Hoboken:
Wiley, 2004.
MACHADO, Alexandre Lopes. Modelo conceitual formal de relacionamentos

do ordenamento jurídico positivo. Tese de doutorado – Instituto Tecnológico
de Aeronáutica (ITA), São José dos Campos, 2013.

OMG – OBJECT MANAGEMENT GROUP. Unified modeling language. Object

Management Group, [s/d]. Disponível em: <http://www.omg.org/spec/UML/>.
Acesso em: 6 jan. 2016.
SADALAGE, Pramod J.; FOWLER, Martin. NoSQL essencial. São Paulo: Novatec,
2013.
Bookman, 2009.
78
<http://www.uml.org/what-is-uml.htm>. Acesso em: 6 jan. 2016.

UML. What is UML. Introduction, [s/d]. [Tradução do autor]. Disponível em:
Capítulo 6
Analítico
(analytics) para
Big Data
O analítico em Big Data é o trabalho de análise inteligente de um

grande volume de dados, sejam eles estruturados ou não. Como já es-
tudamos, esses dados são coletados, armazenados e passam por uma
série de consolidações de softwares. Por meio do cruzamento desses
dados é possível gerar diversos tipos de relatórios, que, por sua vez, po-
dem ajudar no processo de tomada de decisão de uma empresa.
O mais importante é que tudo isso é realizado em um tempo bastan-

te reduzido. Vamos apresentar neste capítulo como são realizadas as
análises estatísticas (analytics) para Big Data. Para isso, vamos focar os
estudos nas análises estatísticas mais relevantes.
79
Vamos inicialmente analisar o tipo analítico descritivo, utilizado
para descrever os padrões e tendências revelados pelos dados. Na se-
quência, vamos estudar tipo o analítico preditivo que visa prever o que
acontecerá no futuro.
1 Analítico
O analítico utiliza duas grandes áreas: a estatística e o data mining
(DM), ou mineração de dados em português (MAYER-SCHONBERGER;
CUKIER, 2013).
A estatística constitui uma parte da matemática aplicada e tem

como finalidade obter conclusões sobre os verdadeiros parâmetros dos
dados. Ela é aplicada em análise do tipo analítico descritivo e preditivo
(BUSSAB; MORETTIN, 2013). Já o data mining utiliza os resultados da
análise preditiva para estipular ações proativas (CHU, 2013) e gerar a
análise do tipo analítico prescritivo.
A tabela 1 apresenta um resumo dos três tipos de analítico existen-

tes. O analítico descritivo busca responder o que aconteceu com os
dados. Esse tipo de análise está diretamente relacionado com o data
warehouse (DW). Como já sabemos, o DW é uma base de dados orien-
tada por assunto – integrado, não volátil de histórico –, criado para su-
portar o processo de tomada de decisão, seja ele tático, estratégico ou
operacional. Dentro dessa tecnologia, a análise se faz por meio da ex-
tração dos dados acumulados ao longo dos anos e pela transformação
deles em informação, ou seja, em algo que faça sentido ao usuário final.
Já o analítico preditivo tenta prever o que acontecerá com os dados.

Esse tipo de análise está diretamente relacionado com o data discovery
(DD). Como já sabemos, o DD tem o objetivo de responder perguntas
que o usuário ainda não conhece, valorizando o potencial dos dados
e de análise dos profissionais de negócio. Dentro dessa tecnologia, a

análise se faz por meio da descoberta de novos conhecimentos, pa-
drões e desvios (ou anomalias), levando a decisões bem informadas.
Por fim, o analítico prescritivo determina quais ações podem ser to-
madas para que algo de fato aconteça, ou como podemos fazer algo
acontecer. Esse tipo de análise está diretamente relacionado ao data
mining.
Tabela 1 – Analíticos e tecnologias aplicadas
ANALÍTICO DESCRITIVO ANALÍTICO PREDITIVO ANALÍTICO PRESCRITIVO
Como podemos fazer

O que aconteceu? O que acontecerá?
acontecer?
Data warehouse (DW)
Data discovery (DD)
Data mining (DM)
2 Analítico descritivo
Assim como em todas as análises, o analítico descritivo oferece uma
possível interpretação para os resultados obtidos, utilizando para isso a
coleta, a organização, a descrição, a análise e a interpretação dos da-
dos (BUSSAB; MORETTIN, 2013). Porém, no modelo de análise analítico
descritiva, o foco é buscar uma análise de uma situação imediata. Ao
invés de fazer uma análise para uma decisão de longo prazo, este mo-
delo de análise descritiva examina dados para que decisões imediatas
ou urgentes sejam tomadas com segurança.
Geralmente este modelo é adotado por empresas de cartões de cré-

dito ou instituições financeiras, para a concessão ou liberação de cré-
dito para um indivíduo, ou ainda para saber se a compra é compatível
com o perfil daquele cliente. Por meio desse modelo, é possível reduzir
os riscos de realizar pagamentos por cartões roubados.
Analítico (analytics) para Big Data 81

Veja diferentes técnicas para aplicar a análise descritiva.
2.1 Interpolação linear
A interpolação é um método que permite construir um novo conjun-

to de dados a partir de um conjunto já conhecido (BUSSAB; MORETTIN,
2013). Por meio da interpolação, é possível construir uma função
que apresente uma continuação para o conjunto de dados que já
conhecemos.
Para ficar mais fácil, vamos utilizar um exemplo: vamos supor que
precisamos calcular a raiz quadrada de 24,69.
A raiz não é exata e, portanto, torna o cálculo difícil. Por outro lado,
podemos identificar quais são as raízes exatas mais próximas desse
número. Antes temos a raiz do número 16, que é igual a 4, e depois
temos a raiz do número 25, que é igual a 5. Com essas duas informa-
ções, podemos transformar o cálculo de uma função difícil, com uma
raiz desconhecida e fracionária, em um cálculo de função fácil, realizada
por meio de uma regra de três.
Dessa forma, o analista é capaz de prever os valores e, com isso,

encontrar a continuidade desejada.
PARA SABER MAIS
A regra de três é um processo simples para determinar um valor a

partir de três valores já conhecidos. Para isso, devemos agrupar os
valores do mesmo tipo em colunas, mantendo na mesma linha os
valores de tipo diferente que são correspondentes. Os dados dispo-
níveis na coluna podem estar em ordem crescente ou decrescente.
Caso todas as colunas apresentem dados na mesma ordem, elas
são diretamente proporcionais, e basta multiplicarmos os valores
em cruz: o primeiro valor da primeira coluna vezes o segundo valor
da segunda coluna, e vice-versa. Porém, se as colunas apresentam

ordens diferentes, uma crescente e outra decrescente, elas são in-
versamente proporcionais. Neste caso, devemos inverter os valores

para ficarem diretamente proporcional antes de realizar o cálculo.
Vamos aplicar a regra de três no exemplo da raiz de 24,69. O primei-

ro passo, que já realizamos, é identificar os valores conhecidos mais
próximos. Eles são, respectivamente, as raízes de 16 e 25:
2
16 = 4 2
24,69 = x 2
25 = 5
Com essas informações podemos construir a tabela, semelhante à

regra de três. Assim, o número 16 vai estar na mesma linha que o núme-
ro 4, da mesma forma que o número 24,69 vai estar na linha da variável
que queremos encontrar, e o número 25 vai estar na linha do número 5:
16 4
24,69 x
25 5
Agora devemos identificar se as grandezas são direta ou inversa-

mente proporcionais. Em uma coluna temos os números 16, 24,69 e 25,
em uma ordem crescente. Na outra coluna temos os valores: 4, x que
é a variável que devemos encontrar, e 5. Neste caso, com base nos va-
lores conhecidos, podemos afirmar que as grandezas são diretamente
proporcionais.
Assim, a última etapa é montar a proporção e resolver a equação.

Para isso vamos organizar os valores da seguinte forma:
25 – 16 5–4
24,69 – 16 x–4

O número 25 menos 16 é proporcional ao número 5 menos 4. Da
mesma forma, o número 24,69 menos 16 é proporcional à variável x
menos o número 4. Continuando o cálculo, encontraremos os valores
da multiplicação:
9 1
8,69 x–4
Neste caso, 9 multiplicado pelo resultado de x menos 4 é igual à mul-

tiplicação de 8,69 por 1. Logo, podemos dizer que:
Obviamente, quando utilizamos a função mais simples não obte-

mos o resultado exato, que no exemplo seria 4,968903299521938. No
entanto, dependendo do domínio do problema, o ganho de simplicida-
de pode compensar o erro.
Uma aplicação da interpolação em análise de Big Data é a aproxima-

ção de funções complexas por funções mais simples. Podemos, então,
escolher alguns dados pontuais da função complexa e tentar reduzi-la
com uma função mais simples. No nosso exemplo, reduzimos o proble-
ma de cinco valores e uma variável desconhecida para um problema de
regra de três, que já era de nosso conhecimento.
2.2 Distribuição de frequência
A distribuição de frequência é uma disposição de dados numéricos

de acordo com o tamanho ou a magnitude dos fatos e sem variação de

local, tempo e fato (BUSSAB; MORETTIN, 2013). Ela pode ser apresenta-
da por valor (único) ou por grupo de escalares (classes), discriminando

a frequência deles.
Acompanhe o exemplo: a tabela a seguir apresenta a distribuição da

produção de automóveis em função dos anos por valor (único). Em ou-
tras palavras, é uma série histórica da produção total de veículos entre o
período de 2001 a 2015. Perceba que a frequência se refere ao total de
veículos produzidos naquele ano.
Tabela 1 – Série histórica de produção total de automóveis
ANO FREQUÊNCIA ANO FREQUÊNCIA
2001 1.817.116 2009 3.183.482
2002 1.791.530 2010 3.646.548
2003 1.827.791 2011 3.446.329
2004 2.317.227 2012 3.432.249
2005 2.530.249 2013 3.738.448
2006 2.612.329 2014 3.172.750
2007 2.980.163 2015 2.453.622
2008 3.216.381
Fonte: adaptado de Anfavea (s/d).
Já a próxima tabela apresenta a mesma distribuição de produção

de automóveis por grupo de escalares (classes). Em outras palavras, é
a mesma série histórica da tabela anterior em função de períodos (três
anos, ou triênios).

Tabela 2 – Série histórica de produção total de automóveis (em triênios)
CLASSES FREQUÊNCIA
2001|---2003 5.436.437
2004|---2006 7.459.805
2007|---2009 9.380.026
2010|---2012 10.525.126
2013|---2015 9.364.820
Uma aplicação da distribuição de frequência em Big Data é a ex-

ploratória de dados, que será apresentada no capítulo 8. Ela permite a
identificação de tendências, como no nosso exemplo, no qual é possível
perceber que as vendas foram crescentes de 2001 a 2012; começaram
a reduzir em 2013; que houve um recorde de vendas entre 2010 e 2012;
e por fim, que o triênio 2013 a 2015 foi um retrocesso de vendas, pois
teve um resultado pior que 2007 a 2009; e assim sucessivamente.
Além da tendência, podemos ainda utilizar outras medidas de fre-

quência que são denominadas de posição e de dispersão.
•• As medidas de posição mostram como estão concentrados os

dados e resumem informações importantes sobre a distribuição
(BUSSAB; MORETTIN, 2013). São exemplos a moda e a mediana,
que serão apresentadas ainda neste capítulo.
•• Já as medidas de dispersão mostram o grau de homogeneidade

ou de heterogeneidade que existe entre os dados da distribuição
(BUSSAB; MORETTIN, 2013). Em outras palavras, elas capturam
distorções nos dados.
Para ilustrar melhor o resultado de uma análise distorcida de Big

Data, vamos utilizar um exemplo: imagine que dois indivíduos saem

para jantar e, enquanto um deles come um leitão inteiro, o outro não
come nada. Nesse caso, temos como média ½ leitão para cada um. No
entanto, esse valor não caracteriza a situação. Em uma situação real, os
dois indivíduos morreriam: um de fome (por não comer nada ) e o outro
de indigestão (por comer um leitão inteiro sozinho). Em outras palavras,
a medida de posição pode trazer resultados errados. A variância é um
exemplo para resolver este problema e será apresentada mais adiante.
2.3 Moda
A moda (Mo) é o valor ou atributo que ocorre com maior frequência

em uma distribuição (BUSSAB; MORETTIN, 2013). Por exemplo, a nota
modal dos alunos de uma turma é a nota mais comum que a maioria
dos alunos obteve.
Quando temos série de valores não agrupados, a Mo é facilmente

encontrada, pois basta encontrar o valor que mais se repete. Neste
caso, temos:
•• Amodal: a distribuição não possui moda. Esse é o caso da série

apresentada na tabela 2: não existe Mo. Em outras palavras, não
houve produção constante de veículos entre o período de 2001 a
2015. As vendas subiram ou desceram durante o período.
•• Unimodal: a distribuição possui uma única moda. Dado os valo-

res 4, 2, 6, 4, 3, 5, 7, 9, 4, 10, 8, 4, 3, 2, 4, a Mo é igual 4.
•• Bimodal: a distribuição possui duas modas, ou dois valores que

mais se repetem, e na mesma quantidade. Dado os valores 3, 2,
3, 4, 5, 3, 4, 2, 3, 2, 5, 2, a Mo é igual a 2 e 3.
•• Multimodal: semelhante à moda bimodal, mas a distribuição

possui n modas. Dado os valores 1, 2, 3, 0, 7, 3, 2, 5, 1, 9, 15, a
moda é: Mo = 1; Mo = 2; Mo = 3.

PARA PENSAR
Dizemos que um determinado produto está na “moda” quando, dentre
diversos outros produtos, ele está sendo usado por um número maior
de pessoas.
2.4 Mediana
A mediana (Md) é outra medida de posição que representa o valor

que divide a distribuição em dois conjuntos com o mesmo número de
elementos (BUSSAB; MORETTIN, 2013). Voltemos à série histórica da
tabela 1. Para calcular a mediana devemos seguir os seguintes passos:
1. Primeiramente, precisamos identificar o Rol. O Rol é qualquer ar-

ranjo de dados brutos em ordem crescente (ou decrescente):
Rol = 1.791.530, 1.817.116, ... , 3.738.448.
2. Selecionar o valor central que divide a distribuição de forma que

tenha o mesmo número de elementos à esquerda e à direita des-
se valor. Assim, se temos quinze elementos, ele será o oitavo
elemento.
3. Temos sete valores abaixo do oitavo elemento e sete valores aci-

ma dele. Logo, a mediana é Md = 3.216.381, que corresponde ao
resultado do ano de 2008 da série histórica.
Portanto, o ano de 2008 foi o que melhor representou a quantidade

de veículos vendidos, considerando o período de 2001 a 2015. Em ou-
tras palavras, a mediana dá uma ideia melhor de um valor típico que
não é distorcido por valores extremamente altos ou baixos. No nosso
exemplo, a média seria distorcida por um pequeno número de valores
extremamente altos ou baixos (anos de 2002 e de 2013) em que há que-
da na produção de veículos, embora, no geral, ela tenha sido constante
durante o período. Assim, são esses dois anos que o cientista de dados
precisa investigar melhor.

Observe que, no exemplo anterior, trabalhamos em uma série de
quinze valores, e quinze é um número ímpar. Se temos um número ím-

par de dados, a mediana será justamente o termo central. Se, porém,
tivéssemos um número par de dados, não haveria valor central.
Agora considere a série de valores 6, 4, 10, 5, 12, 3, 20, 7 nas seguin-
tes etapas:
1. Rol: 3, 4, 5, 6, 7, 10, 12, 20.
2. Ao selecionar os termos centrais, como o número de dados é par,
existem dois termos centrais no Rol.
Rol: 3, 4, 5, 6, 7, 10, 12, 20.
3. Por convenção, adotamos a mediana como sendo a média arit-
mética entre os dois termos centrais. Assim, a Md será igual à
soma de 6 e 7 dividido por 2, ou seja, 6,5.
2.5 Variância
A variância é a média aritmética dos quadrados dos desvios em tor-

no da média aritmética (BUSSAB; MORETTIN, 2013).
PARA SABER MAIS
A média aritmética é a razão entre a soma dos dados assumidos pela

variável e o número de dados considerados (BUSSAB; MORETTIN,
2013).

No nosso exemplo da tabela 1, temos a produção média de veículos
como:
1.817.1662 + 1.791.5302 + ... + 2.453.6222

X= = 2.453.081 veículos
15
Em outras palavras, a variância é uma medida de dispersão que con-

sidera todos os dados em torno da média aritmética. Assim, temos:
Onde:
σ2X = variância ao quadrado de um número

X2 = média do quadrado
(X)2 = quadrado da média
Voltemos ao exemplo da tabela 1. O valor da variância seria:
Em Big Data, a variância indica a distância dos valores analisados

em relação ao valor esperado. O valor esperado, em geral, é a média
aritmética. Quanto menor a variância, mais próximos os valores estão
da média. Da mesma forma, quanto maior ela é, mais os valores estão
distantes da média.
No nosso exemplo, a variância (419.606.381.083) está distante

da média (2.811.081), mostrando que cada valor da série está muito

distante da média. Em outras palavras, a utilização da média mostraria
um resultado distorcido da produção de veículos. Como nesse exemplo

calculamos a variância de todos os anos, dizemos que fizemos o cálcu-
lo da variância populacional.
3 Analítico preditivo
A análise preditiva ou inferencial busca analisar dados armazenados
ao longo de um tempo para mapear ou prever algum resultado e/ou
comportamento. Essa análise é realizada por meio de uma amostra.
A amostra nada mais é do que uma pequena parte de um todo, que é
escolhida para ser analisada pela técnica de amostragem.
Dessa forma, o cientista de dados pode prever o que acontecerá

com os dados e responder a perguntas que o usuário ainda não conhe-
ce, valorizando o potencial dos dados.
3.1 Amostragem
A amostragem estatística envolve a escolha de qualquer subconjunto

não vazio de uma população. A população é qualquer conjunto de ele-
mentos ou indivíduos, com pelo menos uma característica comum ao ob-
jeto em estudo, e devem ser representativas das características básicas
da população alvo, tais como o tamanho (BUSSAB; MORETTIN, 2013).
A população pode ser finita ou infinita conforme o número de elemen-

tos que possui. Na prática consideramos como infinitas aquelas popula-
ções com número de elementos muito grande. Por exemplo, a população
do quanto pesa, em quilos, os alunos de uma academia é finita. Porém,
se cada aluno é sorteado e recolocado no conjunto para novo sorteio,
teríamos a população de pesos infinita (BUSSAB; MORETTIN, 2013).
Para a seleção da amostra, é importante que ela seja representativa

da população, considerando a aleatoriedade da seleção e o tamanho da

amostra. A aleatoriedade da seleção pode ser:
•• Amostragem probabilística: cada elemento da população tem
uma probabilidade (não nula) de ser escolhido. Em geral, todos
os elementos têm a mesma probabilidade de ser escolhido. Um
exemplo seria o sorteio aleatório de dez pessoas para ganhar um
prêmio. Cada pessoa tem 10% de chance de ser escolhida.
•• Amostragem não probabilística: a amostragem é restrita aos ele-
mentos a que se tem acesso. Não há a possibilidade de sorteio.
Um exemplo é o estudo sobre a ocorrência de focos de dengue
em casas de um determinado bairro da cidade. Para realizá-lo, a
amostragem coletada da população será de algumas casas que
podem (ou não) ter contraído a doença. Este tipo de amostragem
não é aplicado em Big Data e não será detalhada neste livro.
Já o tamanho da amostra é calculado com base no parâmetro que
se deseja estimar e leva em consideração as incertezas inerentes à
estimação, tais como a variação original dos dados (variância popu-
lacional), da precisão requerida no trabalho, do tempo disponível, do
custo da amostragem e alguns erros inerentes à técnica de amostra-
gem (BUSSAB; MORETTIN, 2013). Em regra geral, podemos afirmar que
quanto maior a amostragem, maior será a precisão do resultado.
IMPORTANTE
Em alguns casos, a amostragem apropriada pode produzir um tama-

nho de amostra que seja relativamente próximo ao da população de
base. Em tais casos, vale a pena considerar a possibilidade do cen-
so. O censo é a pesquisa de toda a população. Ele pode ser usado
quando a população de base for relativamente pequena (como pode
ocorrer em países pequenos), ou quando houver uma exigência legal
de que todas as pesquisas de empresas tenham de ser censos. As
limitações de recursos e o ônus de responder decidirão o uso da
amostragem ou o censo.

3.2 Técnicas de amostragem probabilísticas
É fundamental que as amostras sejam obtidas por processos ade-

quados de modo a evitar que erros comprometam a análise. Existe um
conjunto substancial de técnicas de amostragem estatística (BUSSAB;
MORETTIN, 2013). Algumas técnicas probabilísticas são:
•• Técnica de amostragem aleatória simples: é um procedimento

aleatório bem simples por meio da escolha de n elementos de
uma população de tamanho N. Essa técnica pressupõe uma po-
pulação homogênea e não garante representatividade, pois al-
guns grupos (mais raros) podem nunca ser sorteados. Em análi-
se de Big Data, essa técnica pode ser utilizada para filtrar grandes
volumes de dados. Digamos que temos milhões de registros (po-
pulação) e gostaríamos de escolher uma amostra aleatória sim-
ples de cinquenta elementos para análise. Primeiro, cada registro
é numerado de um até a quantidade. Então, geramos uma lista de
cinquenta números aleatórios, por meio de um algoritmo, e os nú-
meros dessa lista serão os únicos que serão analisados, ou seja,
serão a amostra.
•• Técnica de amostragem sistemática: é um procedimento para

amostrar uniformemente todo o espaço, garantindo uma amostra
por célula. Se os elementos da população já se encontram orde-
nados segundo algum critério, pode-se selecionar um elemento
qualquer e escolher um “passo” que definirá o próximo elemento
escolhido. Em análise de Big Data, essa técnica é utilizada de for-
ma semelhante à técnica aleatória simples, com adicionais. Os
registros são colocados em uma lista e cada vigésimo registro,
por exemplo, seria selecionado para inclusão na amostra. A fim
de evitar o viés humano neste método, o cientista de dados deve
selecionar o primeiro elemento aleatoriamente.

•• Técnica de amostragem de estratificação: é um procedimento
que seleciona aleatoriamente estratos com elementos. Os estra-
tos devem ser homogêneos em termos do fenômeno que está
sendo considerado. Isso garante uma menor variabilidade e re-
presentatividade. Entretanto, requer o conhecimento prévio sobre
os estratos. Em análise de Big Data, essa técnica pode ser utiliza-
da para filtrar grandes volumes de dados, dividindo-os em grupos.
Por exemplo, ela pode ser aplicada para realizar a classificação
de documentos legais. Para obter uma amostra estratificada de
documentos, o cientista de dados organizaria primeiro a popu-
lação por ano e, então, selecionaria determinado número de ofí-
cios, certidões, decretos, contratos, por exemplo, garantindo que
o cientista de dados tenha a quantidade adequada de indivíduos
de cada classe na amostra final.
Este capítulo apresentou algumas técnicas analíticas para Big Data.
O analítico descritivo é muito utilizado para comprovar a influência de
certas variáveis no resultado obtido.
Por outro lado, o analítico preditivo é a parte mais importante da es-

tatística, pois é a inferência estatística que visa descobrir o valor futuro
de determinado atributo com o objetivo de prever o comportamento de
um determinado objeto.
Por fim, a combinação dos analíticos preditivo e prescritivo tem um

objetivo maior que é analisar o conjunto de registros fornecidos, a fim
de aprender como classificar um novo registro. Este aprendizado é feito
por meio de algoritmos e é denominado mineração de dados, conforme
veremos no próximo capítulo).

Referências
ANFAVEA. Série histórica de produção total de automóveis, [s/d]. Disponível

em: <http://www.anfavea.com.br/estat%C3%ADsticas.html>. Acesso em: 28
jan. 2017.
BUSSAB, Wilton O.; MORETTIN, Pedro A. Estatística básica. 8. ed. São Paulo:
Saraiva, 2013.


96
Capítulo 7
Mineração de dados
A mineração de dados (data mining) é composta por um conjunto

de técnicas e algoritmos variados. A utilização de soluções paralelas e
distribuídas consolida-se como crucial para a viabilidade da execução
desses algoritmos em grandes bases de dados.
Um problema enfrentado em mineração de dados é encontrar pa-

drões presentes nessas bases de dados por meio de algumas técnicas.
Este capítulo vai apresentar essas técnicas de aprendizado de má-

quina, que são divididas em supervisionado (classificação, associação
e regressão) e não supervisionado (agrupamento).
97
A classificação identifica a qual classe um determinado objeto per-
tence, a associação identifica quais atributos de um objeto estão rela-
cionados e a regressão determina um objeto por um valor numérico
e não uma classe. Já o agrupamento visa identificar e aproximar os
objetos similares.
1 Aprendizado de máquina
O aprendizado de máquina (ou machine learning, em inglês) é o pro-
cesso de explorar os dados à procura de padrões consistentes para
detectar relacionamentos sistemáticos entre eles e agrupá-los em
classes.
Uma classe é uma coleção de objetos similares entre si e não simila-

res aos objetos localizados em classes diferentes. A identificação é feita
por meio de padrões válidos, novos, potencialmente úteis e finalmente
compreensíveis a partir dos dados (ZAKI; MEIRA, 2014).
Em outras palavras, é feita a identificação dos padrões por meio dos

dados existentes e a descoberta de novos padrões úteis após o apren-
dizado da máquina. Os tipos de aprendizado de máquina são:
•• Aprendizado supervisionado: a definição do foco de análise

é clara e determinada. Os dados de treinamento são os dados
utilizados para “ensinar” a máquina e contêm a classe de cada
amostra. Os novos dados são classificados por meio de treina-
mento do algoritmo. As técnicas mais comuns são a classifica-
ção, a associação e a regressão.
•• Aprendizado não supervisionado: as classes em que os dados

serão classificados não são conhecidas ou bem determinadas.
Uma vez separado um grupo de amostras, o objetivo é estabe-
lecer um conjunto de agrupamentos ou classes. A técnica mais
comum é o agrupamento.

O quadro 1 compara as principais características dos aprendizados
supervisionado e não supervisionado. As próximas seções apresentam

as técnicas utilizadas para cada um deles.
Quadro 1 – Características dos tipos de aprendizado
SUPERVISIONADO NÃO SUPERVISIONADO
Usado principalmente para

É usado principalmente para
exploração, descrição e sumarização
Aplicação classificar, estimar ou predizer o
de dados, identificando os grupos de
valor de uma variável.
dados similares.
É preciso que os dados sejam Não necessita de dados

Pré-requisito
previamente categorizados. categorizados.
A qualidade de uma regra é

avaliada por fatores definidos A qualidade é mais difícil de ser
Qualidade pelo usuário, logo há medidas avaliada, logo não é muito claro quais
objetivas para medir a qualidade regras deveriam ser descobertas.
da classificação.
Classificação, associação e
Técnicas Agrupamento.
regressão.
IMPORTANTE
A mineração de dados envolve algumas técnicas adequadas para

cada tipo de problema (incluindo o pré-processamento de dados), o
conhecimento do modelo de negócios do cliente e uma infraestrutu-
ra de computação (MAYER-SCHONBERGER; CUKIER, 2013).
2 Classificação
A classificação ou supervisão é o processo de organizar objetos em
classes de forma que membros de uma mesma classe sejam similares.
O objetivo é construir um modelo que possa ser aplicado a dados não
classificados visando categorizá-los em classes.
Mineração de dados 99
O agrupamento é geralmente realizado a partir de estruturas e pa-
drões nos dados. A classificação é realizada em três etapas (ZAKI;
MEIRA, 2014):
1. Criação do modelo de classificação: utilização de um modelo

matemático denominado classificador. São utilizadas algumas
técnicas, como as árvores de decisão, que serão apresentadas
no próximo capítulo.
2. Validação do modelo: é aplicado um classificador sobre os da-

dos existentes com classes definidas, visando o treinamento do
classificador.
3. Operação do modelo sobre novos dados: o classificador realiza

a previsão sobre os novos dados utilizando o aprendizado obtido
durante a etapa anterior.
Vamos supor que o objeto definido seja, por exemplo, a transação

de um cartão de crédito. Essa ação possui uma série de etapas, desde
o momento da leitura do cartão até a efetivação do débito na fatura do
cliente, correto? Se houver o registro de uma transação incorreta no
cartão de um cliente, podemos considerar que houve uma fraude.
Nesse caso, o objetivo das técnicas é determinar a qual classe essa

transação pertence. Em outras palavras, o objetivo é detectar compor-
tamentos atípicos (fraudes) ou típicos (não fraude). A figura a seguir
apresenta o objeto e a classe correspondente.
Figura 1 – Exemplo de classificação
Objeto Classe
Transação de
ü
Fraude ou
cartão de crédito não fraude

3 Associação
A associação é o processo de encontrar padrões frequentes e corre-

lações entre conjuntos de objetos, na qual dado um conjunto de atribu-
tos, é possível ainda prever a ocorrência de outro conjunto de itens com
certo grau de confiança (ZAKI; MEIRA, 2014). Essa técnica consiste
em identificar a relação dos itens mais frequentes em um determinado
conjunto de dados e permite obter resultados do tipo: “SE, TAMBÉM”.
Tal construção recebe o nome de regra de associação (ou association
rules, em inglês).
NA PRÁTICA
Um exemplo de associação que ficou bastante conhecido foi a des-

coberta feita por uma das maiores redes de varejo dos Estados Uni-
dos, o Walmart. Foi descoberto em seu gigantesco banco de dados
que a venda de fraldas descartáveis estava associada à de cerve-
ja. Em geral, os compradores eram homens, que saíam à noite para
comprar fraldas e aproveitavam para levar algumas latinhas de cer-
veja para casa. Os produtos foram postos lado a lado. Resultado: a
venda de fraldas e cervejas disparou. A regra seria: SE compra fral-
das TAMBÉM compra cerveja.
Vamos supor que a informação que devemos analisar seja sobre os

clientes que compram computadores e tendem a comprar softwares de
edição de texto. Nesse caso, temos: SE compra computador TAMBÉM
compra software de edição de texto. A regra para este caso seria:
compra (x, “computador”)  compra (y, “software de edição de tex-

to”) [2%, 60%]
Conforme a regra, podemos notar que as medidas são inseridas

entre colchetes. A primeira medida, denominada suporte, indica que

2% de todas as transações analisadas contabilizavam computador
e software em uma mesma compra. A segunda medida, denomina-
da confiança, indica que 60% dos clientes que compram computador
também compram o software.
Por fim, as regras que satisfazem aos dois valores mínimos são con-
sideradas fortes.
4 Regressão
A regressão (ou estimação) é um processo para estimar o valor de
uma determinada variável analisando-se os valores das demais (CHU,
2013). Ao invés de classes a serem previstas para um determinado ob-
jeto, como nos processos de classificação e associação, são previstos
valores contínuos.
IMPORTANTE
A regressão é semelhante à classificação, porém é usada quando o

registro é identificado por um valor numérico e não uma classe.
Um modelo de regressão pode prever, por exemplo, qual será o valor

gasto por um novo consumidor utilizando como base o registro de va-
lores mensais gastos por diversos tipos de consumidores e de acordo
com os hábitos de cada um. A próxima figura apresenta o objeto e a
resposta correspondente.

Figura 2 – Exemplo de classificação
Objeto Classe
Registro de valores mensais Valor gasto por um

gastos por diversos tipos de novo consumidor
consumidores e de acordo
com os hábitos de cada um
NA PRÁTICA
A regressão pode ser usada para estimar a quantia a ser gasta por
uma família de quatro pessoas durante a volta às aulas, ou estimar a
pressão arterial ideal de um paciente baseando-se na idade, no sexo
e na massa corporal.
As técnicas de regressão modelam o relacionamento de variáveis

independentes (chamadas preditoras) com uma variável dependente
(chamada resposta) (CHU, 2013). As variáveis preditoras são os atribu-
tos dos registros, e a resposta é o que se quer predizer.
Em outras palavras, esses valores são obtidos por meio de uma ex-
pressão matemática que relaciona pares de valores (variáveis predito-
ras) numéricos. Essa expressão permite estimar y em função de x. Por
meio desses pares, é possível construir um gráfico que melhor se ajuste
aos pontos. Exemplos de gráfico serão apresentados mais adiante.
Se a expressão matemática obtida para relacionar as duas variáveis

(x e y) for uma reta, teremos uma regressão linear. Caso contrário, tere-
mos uma regressão não linear.

4.1 Regressão linear
As regressões são chamadas de lineares quando a relação entre as
variáveis preditoras e a resposta segue um comportamento linear (CHU,
2013). Em outras palavras, é a obtenção da equação de uma reta para
relacionar as duas variáveis, x e y. Nesse caso, é possível criar um mo-
delo no qual o valor de y é uma função linear de x, ou seja, y é igual ao
resultado da multiplicação da variável a por x, mais a variável b:
y = ax + b
Imagine que um analista coletou diversos pontos (x e y) e quer proje-

tar esses dados em um gráfico. O objetivo é identificar a melhor reta, ou
seja, aquela que passa pelo maior número possível de pontos. A figura
a seguir ilustra um gráfico de dispersão (reta) que apresenta o bônus
recebido pelos funcionários de uma dada empresa, expresso em reais
(variável y), e o respectivo tempo de serviço, em meses (variável x). O
gráfico de dispersão evidencia a reta da regressão linear. Assim, encon-
tramos a reta que melhor se ajusta ao conjunto de pontos (x, y) do fenô-
meno estudado.
Figura 3 – Gráfico de dispersão (regressão linear)
Tempo 180
de serviço Bônus
(meses) mensal 160
62 153 140
48 131 120
78 166
Bônus mensal
100
42 124
69 155 80
53 134 60
61 156
40
55 151
44 121 20
48 146 0
0 10 20 30 40 50 60 70 80 90
74 158
66 161 Tempo de serviço (em meses)

Com base no gráfico obtido, podemos concluir que quanto maior o
tempo de serviço (expresso em meses) de determinado funcionário em

uma empresa, maior será o seu bônus mensal (expresso em reais).
4.2 Regressão não linear
As regressões são chamadas de não lineares quando a relação en-

tre as variáveis preditoras e a resposta não segue um comportamento
linear, como uma curva (CHU, 2013). Em outras palavras, é a obtenção
da equação de uma curva para relacionar as duas variáveis, x e y. Nesse
caso, os pontos se aproximam de uma curva cujo gráfico é uma função
quadrática, exponencial, logarítmica, etc.
Vamos analisar o caso em que a curva de ajuste é uma função qua-

drática. A regra então fica assim: y é igual a variável a vezes x, vezes
dois; somado à variável b vezes x; somado à variável c:
y = ax2 + bx + c
Imagine que um analista coletou diversos pontos (x e y) e quer proje-

tar esses dados em um gráfico. O objetivo é identificar a melhor curva,
ou seja, aquela que passa pelo maior número possível de pontos. A pró-
xima figura apresenta um gráfico de dispersão (parábola) com os valo-
res da quantidade demandada de um bem (variável y) e os preços de
venda correspondentes em determinado período (variável x). O gráfico
de dispersão evidencia a curva da regressão não linear denominada pa-
rábola. Em outras palavras, encontramos a curva que melhor se ajusta
ao conjunto de pontos (x, y) do fenômeno estudado.

Figura 4 – Gráfico de dispersão (regressão não linear)
250
200
Quantidade (em unidades)

Quantidade Preço de
vendida venda (R$)
150
1 136
24 171
45 196 100
66 159
86 131 50
0
0 20 40 60 80 100
Preço de venda (R$)
Com base no gráfico obtido, podemos concluir que quanto maior

a quantidade demandada de um bem, maiores serão os preços de
venda.
5 Agrupamento
O agrupamento (ou clustering, em inglês) é o processo de agrupar
um conjunto de dados com características similares, de acordo com
algum critério de similaridade prefixado (ZAKI; MEIRA, 2014). Em outras
palavras, a tarefa de agrupamento visa identificar e aproximar os regis-
tros similares.
IMPORTANTE
O agrupamento pode ser utilizado como apoio à estratégia de marke-

ting, ajudando os analistas a identificar grupos de clientes-alvo por
meio da segmentação de mercado para um nicho de produtos. Na
área financeira, ele pode auxiliar os analistas nos processos de aná-

lise de crédito e seguro. Por fim, no segmento de gestão pública,
pode auxiliar governantes no planejamento de cidades, identificando

grupos de casas de acordo com tipos, valores e localizações.
Um agrupamento é uma coleção de registros similares entre si,

porém diferentes dos outros registros nos demais agrupamentos. Ele
pode ser de três tipos:
•• Particional: não há hierarquia entre os grupos. Cada ponto pode

estar somente em um grupo, associado a diferentes grupos ou
sobreposto.
•• Hierárquico: existe a noção de hierarquia entre grupos. A cria-

ção de grupos pode ser aglomerativo (bottom-up) ou divisivo
(top-down).
•• Probabilístico: assume-se que o dado é composto por diversas

distribuições diferentes, pertencendo probabilisticamente a mais
de um grupo.
Vamos supor que decidimos utilizar essa técnica em um conjun-

to de objetos definido, por exemplo, o registro de um supermercado
contendo os dados pessoais de um cliente incluindo o seu histórico
de compras.
Nesse caso, o objetivo é determinar diferentes grupos de clientes e

criar um agrupamento particional. Em outras palavras, criar listas de
sugestão de novas compras com base no histórico de compras daquele
cliente. A figura 5 apresenta o objeto e a resposta correspondente:

Figura 5 – Exemplo de agrupamento
Objeto Classe
Cliente (dados Grupos de clientes

pessoais/histórico
de compra)
PARA SABER MAIS
O algoritmo K-Means é o mais conhecido para a implementação da

técnica de agrupamento. Trata-se de um processo extremamente
custoso do ponto de vista computacional e um desafio para a extra-
ção de paralelismo uma vez que a sua complexidade é exponencial.
Em geral, a solução adotada obedece a requisitos rígidos de escala-
bilidade algorítmica.
Este capítulo apresentou as técnicas utilizadas para a mineração de
dados. Em cenários de grandes volumes de dados, as soluções adota-
das devem obedecer a requisitos rígidos de escalabilidade, pois nem
tudo se resolve com a introdução de mais recursos de hardware.
Em geral, os algoritmos que implementam as técnicas apresentadas

neste capítulo são um processo extremamente custoso do ponto de
vista computacional, uma vez que a quantidade de dados envolvidos
na mineração é muito grande, e os algoritmos frequentemente são irre-
gulares e intensivos em termos de entrada/saída (E/S). Um algoritmo é

irregular quando o seu comportamento e, portanto, o seu custo depen-
dem da natureza da entrada. O fato de que os programas são intensivos

em termos de E/S faz com que o desempenho seja bastante afetado
pelos componentes do sistema e pela quantidade de sobreposição en-
tre o processamento e a comunicação atingida durante a execução do
programa.
Referências

ZAKI, Mohammed; MEIRA, Wagner. Fundamentals of data mining algorithms.

New York: Cambridge University Press, 2014.

110
Capítulo 8
Análise visual de
dados
O objetivo final da análise de dados é transformá-los em informa-

ções capazes de dar suporte às decisões gerenciais de forma amigável
e flexível ao usuário e em tempo hábil (TURBAN et al., 2009).
O cientista de dados é capaz de ampliar sua compreensão sobre os

dados por meio de uma análise visual deles. Isso pode acontecer por
uma ou mais formas de visualização, ou, ainda, a análise pode ser filtra-
da a partir de um ou mais dados consolidados.
Neste capítulo vamos estudar algumas técnicas utilizadas para a

análise visual de Big Data. Iniciamos nosso estudo com a apresenta-
ção da análise OLAP, aprendendo sobre o seu funcionamento e dando
111
destaque aos seus operadores, que são os drills, os filtros, o ranking, os
sorts, o tilling, etc.
Em seguida, vamos analisar a exploratória de dados – um tipo de

recurso estatístico muito utilizado para a representação gráfica dos da-
dos. Também conheceremos as árvores de decisão – um tipo de fluxo-
grama para representar, de maneira gráfica, o processo de classificação
de mineração de dados, que já estudamos no capítulo anterior.
Por fim, vamos aprender mais sobre os painéis de controles (dash-

boards), que são a junção de diversos recursos gráficos em uma única
tela.
1 Análise OLAP
A online analytical processing (OLAP) é um conjunto de processos
para a manipulação, visualização e análise de dados multidimensionais.
Nessa análise, as informações são armazenadas em modelos mul-

tidimensionais que gravam valores quantitativos e de medidas, decom-
postas ou filtradas por uma ou mais dimensões e/ou filtradas a partir de
um ou mais dados em cubos.
O cubo é uma estrutura que armazena os dados em formato multidi-

mensional. Ele permite a criação de diversos subcubos, fazendo assim
uma limitação da área a ser analisada, permitindo a visualização por
meio de diversos ângulos e possibilitando análises multidimensionais
dos dados. É usual a expressão ferramenta OLAP para se referir aos
sistemas que juntamente com o modelo de dados multidimensional
permitem as seguintes funcionalidades (TURBAN et al., 2009):
•• Utilização da ferramenta de consulta eventual (ad-hoc query tool),

que é uma ferramenta de consultas residentes na estação de
trabalho do usuário final que aceita a solicitação de dados por

intermédio de comandos do tipo “apontar e clicar” e constrói uma
consulta eventual para buscar um resultado. A consulta eventual

é qualquer consulta que não possa ser determinada antes da
consulta ser emitida.
•• Apresentação de dados em termos de múltiplas dimensões em

telas por meio de uma configuração tridimensional de linhas, co-
lunas e páginas.
•• Navegação pelas hierarquias, dimensões e seus elementos, que

permite selecionar as perspectivas sob as quais se deseja visua-
lizar as variáveis ou medidas.
NA PRÁTICA
Aplicações típicas de OLAP são relatórios de negócios, marketing,

gerenciais, business performance management (BPM), budgeting e
previsão, financeiros e áreas similares.
Imagine que um analista precise realizar uma análise dos produtos

mais vendidos de uma loja durante os meses de janeiro a julho. Trata-
se de uma loja de varejo que tem diversos produtos e filiais distribuídas
por três regiões do Brasil. Para isso, ele precisa separar os dados de
vendas em três dimensões: a região, o produto e o mês.
Após a definição das dimensões de interesse, a ferramenta OLAP

separa os dados em um cubo de dados de vendas com a representação
das dimensões, como apresentado na figura a seguir. Em um segundo
plano, ele apresenta um subcubo derivado do cubo com um elemento
específico: o produto leite vendido em uma loja da região Sul durante o
mês de abril.
Análise visual de dados 113

Figura 1 – Cubo de análise multidimensional
(b) Subcubo: produto leite em loja

(a) Cubo com as dimensões de vendas
da região Sul para o mês de abril
o
O
giã
Re
S
N
Suco
Cola
Produto
Leite
Creme
Cadeira
Sabonete
1 2 3 4 5 6 7
Mês
As funcionalidades possibilitam criar visões dos dados por meio de

sua reorganização, de forma que eles possam ser examinados sob di-
ferentes perspectivas. Para isso, alguns operadores são utilizados con-
forme veremos a seguir.
1.1 Operadores
Os operadores OLAP servem para modificar a posição de uma infor-

mação, alterando linhas por colunas de maneira a facilitar a compreen-
são dos usuários e girar o cubo sempre que necessário, ou seja, fatiar
(slice) o cubo (dice) (TURBAN et al., 2009). Em outras palavras, o slice é
quem cria os subcubos.
NA PRÁTICA
Lembra-se da análise de vendas? Imagine agora que um analista de-

seja verificar as vendas de todos os produtos para uma cidade espe-
cífica da região Sudeste (São Paulo) no dia do Natal (24/12). Esse é
um bom exemplo de slice e dice.

Assim, é possível fatiar o cubo de dados traçando novas perspec-
tivas para avaliar os dados. Os operadores OLAP são (TURBAN et al.,

2009):
•• Filtros: os dados já recuperados pelo usuário podem ser nova-

mente filtrados para facilitar as análises diretamente no docu-
mento. Eles podem ser:
◦◦ rotação: possibilita inverter colunas e linhas na navegação ao

longo das dimensões na direção de maior detalhe.
◦◦ pivoting: ocorre quando o usuário faz a inversão/rotação dos

eixos no relatório.
◦◦ paging: permite ao usuário exibir as informações do relatório

em blocos ou em mais de uma página. Os blocos (breaks) ser-
vem para separar o relatório em grupos de informações.
PARA PENSAR
Lembra-se da análise de vendas? Imagine que um analista precisa vi-

sualizar a informação de um relatório consolidada por cidades. Para
isso, ele deve solicitar o operador break. Após esta ação ser executada,
automaticamente o relatório será agrupado por cidades, somando os
valores mensuráveis em cada uma delas.
•• Ranking: a opção de ranking permite ordenar resultados maio-

res/menores, com base em objetos numéricos.
NA PRÁTICA
Lembra-se da análise de vendas? Um exemplo de ranking é selecio-

nar as três maiores cidades (top 3) por média de vendas de suco.

•• Sorts: servem para ordenar uma informação. Essa ordenação
pode ser customizada, crescente ou decrescente.
•• Tiling: com esse recurso, o usuário tem à sua disposição a visu-

alização múltipla em uma única tela, isto é, pode ver simultanea-
mente mais de uma consulta ou a mesma consulta como relató-
rio e gráfico.
•• Drill: navegação ao longo das dimensões em diversas direções e

níveis de detalhamento:
◦◦ down: ocorre quando o usuário aumenta o nível de detalhe da

informação, diminuindo o grau de granularidade;
NA PRÁTICA
Com o drill down é possível apresentar um item de resumo consoli-

dado por ano em seus componentes detalhados, como ano, semes-
tre, trimestre, mensal e diário.
◦◦ up ou roll up: ocorre quando o usuário aumenta o grau de

granularidade, diminuindo o nível de detalhamento da infor-
mação. Em outras palavras, é o contrário do drill down, pois a
navegação ao longo das dimensões é feita na direção de me-
nor detalhe.
◦◦ across: ocorre quando o usuário navega entre fatos diferentes

com dimensões comuns.
◦◦ out: nessa ação o detalhamento ocorre para informações ex-

ternas, como fotos, som, documentos e tabelas.
◦◦ throught: ocorre quando o usuário navega para fora da tabela

em busca de mais detalhes para enriquecer o seu relatório.

2 Exploratória de dados
A exploratória de dados pode ser feita por meio de recursos estatís-

ticos, como as séries estatísticas e a distribuição de frequência que já
aprendemos em um capítulo anterior.
Para a representação gráfica dos dados de séries estatísticas são uti-

lizados os gráficos. Já para a representação gráfica de distribuição de
frequência são utilizados os histogramas e os polígonos de frequência
(BUSSAB; MORETTIN, 2013).
2.1 Gráficos
O gráfico de barras (ou colunas) são representações que utilizam

barras horizontais ou verticais para representar a magnitude dos dados
estatísticos em um gráfico (BUSSAB; MORETTIN, 2013).
Imagine que um analista precisa visualizar a distribuição de dados

estatísticos de produção de automóveis em função dos anos. Para isso,
ele separa em uma tabela a série histórica da produção total de veículos
entre o período de 2010 a 2015. A figura abaixo apresenta esse gráfico
de barras.
Figura 2 – Gráfico de barras para a série histórica de produção total de veículos
3.738.448
3.646.548 3.443.329
Ano Total 3.432.249 3.172.750
2010 3.646.548 2.453.622
2011 3.443.329
2012 3.432.249
2013 3.738.448
2014 3.172.750
2015 2.453.622
2010 2011 2012 2013 2014 2015

Já o gráfico de setores são representações que evidenciam uma par-
te do todo (BUSSAB; MORETTIN, 2013). Um dos tipos mais utilizados é
o gráfico em formato de pizza, conforme mostra a figura 3. Neste caso,
é utilizado um gráfico em pizza, que ilustra a mesma série histórica da
produção total de veículos. Por meio desse gráfico o analista pode notar
percentualmente a quantidade de veículos produzidos no período dos
últimos cinco anos, que se manteve constante.
Figura 3 – Gráfico de setores para a série histórica de produção total de veículos (em%)
13% 18%
2010
2011
16% 17% 2012

2013
2014
2015
19% 17%
2.2 Histograma
O histograma é a representação gráfica em colunas de uma distri-

buição de frequência. As bases de cada retângulo representam uma
classe e a altura deles representam a quantidade ou frequência daquela
classe (BUSSAB; MORETTIN, 2013).
Imagine que um analista precise visualizar a distribuição de dados es-

tatísticos de produção de automóveis em função de períodos (três anos,
ou triênios). A figura a seguir apresenta a distribuição de frequência em
classes da produção total de veículos entre o período de 2001 a 2015.

Figura 4 – Histograma para as classes de produção de automóveis
Classes Total 12.000.000
2001 --- 2003 5.436.437 10.000.000

2004 --- 2006 7.459.805
8.000.000
2007 --- 2009 9.380.026
2010 --- 2012 10.525.126 6.000.000
2013 --- 2015 9.364.820
4.000.000
2.000.000
0
2001 --- 2003 2004 --- 2006 2007 --- 2009 2010 --- 2012 2013 --- 2015
Para finalmente fechar os pontos do histograma, devemos unir os

pontos do polígono aos pontos médios das classes anterior e posterior
supostas até atingir os limites e superfícies correspondentes, criando
um polígono de frequência. Vamos entender mais sobre ele a seguir.
2.3 Polígonos de frequência
Agora vamos supor que o analista queira verificar a repetição menor

ou maior de uma ocorrência (neste caso, a quantidade de vezes que
um processo periódico se repete por unidade de tempo). Para isso, o
processo periódico deve unir os pontos médios da quantidade de cada
coluna do histograma. Dessa forma, ele será capaz de perceber que
o ponto que tiver mais altura representa a maior frequência, ao passo
que a área abaixo da curva inclui a totalidade dos dados existentes. A
figura 5 apresenta o polígono de frequência para as classes da figura 4.

Figura 5 – Polígono de frequência para as classes
12.000.000
10.000.000
8.000.000
6.000.000
4.000.000
2.000.000
0
2001 --- 2003 2004 --- 2006 2007 --- 2009 2010 --- 2012 2013 --- 2015
O polígono de frequência é o gráfico obtido quando se une os pontos

médios das bases superiores dos retângulos de um histograma, por
meio de segmentos de retas consecutivos (BUSSAB; MORETTIN, 2013).
3 Árvores de decisão
As árvores de decisão (decision trees) são um fluxograma em for-
ma de árvore no qual cada nó (não folha) indica um teste feito sobre
um valor (ZAKI; MEIRA, 2014). As ligações entre os nós representam os
valores possíveis do teste do nó superior, e as folhas indicam a classe
(categoria) a qual o registro pertence. Pela estrutura que formam, as
árvores de decisões podem ser convertidas em regras de classificação
de mineração de dados (apresentada no capítulo 7).
Em outras palavras, as árvores são uma maneira gráfica de visuali-

zar as consequências de decisões atuais e futuras bem como os even-
tos aleatórios relacionados.
Com a árvore de decisão montada, para classificar um novo registro,

basta seguir o fluxo na árvore (mediante os testes nos nós não folhas),
começando no nó raiz até chegar a uma folha (ZAKI; MEIRA, 2014).

IMPORTANTE
O sucesso das árvores de decisão deve-se ao fato de ser uma téc-

nica extremamente simples, pois não necessita de parâmetros de
configuração, e de geralmente apresentar um bom grau de asserti-
vidade.
4 Painéis de controle
O painel de controle (ou dashboard, em inglês) é a visualização dos
diversos elementos gráficos apresentados neste capítulo em uma
única tela para fácil acompanhamento das informações (MAYER-
SCHONBERGER; CUKIER, 2013).
O objetivo é a análise visual das informações mais importantes e

necessárias para alcançar um ou mais objetivos, consolidadas e ajus-
tadas de acordo com a interação do usuário com qualquer um dos ele-
mentos presentes na tela do painel criado.
Este capítulo apresentou as técnicas de representação visual para a
análise de dados. As análises OLAP oferecem respostas consistentes
às consultas iterativas executadas pelos usuários da ferramenta, inde-
pendentemente da complexidade do banco de dados. Em relação às
árvores de decisão, é necessária uma análise detalhada dos dados que
serão usados para garantir bons resultados, sendo uma técnica extre-
mamente poderosa.
Por fim, o ideal é que o painel de controle não tenha barra de rola-
gem para que a informação seja encontrada rapidamente. Outro fator

relevante é organizar e segmentar as informações em diferentes abas
com nomes referentes ao contexto de análise.
Referências
ANFAVEA. Série histórica de produção total de automóveis, [s/d]. Disponível
em: <http://www.anfavea.com.br/estat%C3%ADsticas.html>. Acesso em: 28
jan. 2017.
BUSSAB, Wilton O.; MORETTIN, Pedro A. Estatística básica. 8. ed. São Paulo:
Saraiva, 2013.

Bookman, 2009.
ZAKI, Mohammed; MEIRA, Wagner. Fundamentals of data mining algorithms.

New York: Cambridge University Press, 2014.

Capítulo 9
Plataformas de
Big Data
Este capítulo vai apresentar algumas plataformas para Big Data.

Diante da grande variedade de ferramentas disponíveis, serão apre-
sentadas aquelas que são consideradas essenciais para o cientista de
dados: as plataformas Apache Hadoop, Weka e Tableau. Além disso,
veremos alguns exemplos de aplicação em empresas e governos ao
redor do mundo.
O Apache Hadoop representa uma família de componentes que, as-

sociada ao paradigma de nuvem, permite principalmente que as mani-
pulações sejam trazidas para onde estão os dados, utilizando-se a ar-
quitetura HDFS e o algoritmo MapReduce, já estudados anteriormente.
123
Já o Weka é uma plataforma com um catálogo de algoritmos com
técnicas de aprendizado de máquinas tais como aprendizado supervi-
sionado e não supervisionado.
Por fim, o Tableau foi projetado para permitir que profissionais de

negócio sem conhecimento técnico pudessem analisar seus dados de
forma eficiente, estejam esses dados em sistemas de bancos de da-
dos ou em simples planilhas eletrônicas. Em um ambiente corporativo,
um usuário confortável com planilhas eletrônicas pode, por si só, criar
análises ricas e interativas e painéis poderosos com a ferramenta, e
compartilhá-los com segurança por toda a empresa.
1 Apache Hadoop
Trata-se de uma plataforma de software livre mantida pela Apache
que permite integrar clusters e máquinas virtuais em um único ambien-
te de processamento de Big Data (WHITE, 2015). Ele é composto por
duas camadas: um framework para MapReduce e um sistema de arqui-
vos distribuído.
A camada de framework para MapReduce possui uma implementa-

ção de map e reduce, semelhante ao que já estudamos em um capítulo
anterior, além de duas implementações adicionais para tornar a imple-
mentação mais eficiente e automatizar algumas tarefas. São elas:
•• Combine: é realizada de forma semelhante a um mecanismo

de reduce local. Quando o map começa a emitir resultados, en-
quanto ainda está na memória uma operação de reduce, torna-
-se altamente eficiente. Assim, é possível definir uma operação
para ser executada quando nessa condição. Nos casos simples,
essa operação será a mesma que o reduce, mas o usuário tem
a opção de definir qualquer operação que ele queira, até mesmo
nenhuma.

•• Shuffle/sort: é realizada progressivamente conforme os maps
terminam. Ela consiste em agregar os valores intermediários pro-

duzidos pelos maps (shuffle) e, para cada chave intermediária, co-
locar a lista de valores em ordem para passar para o job reduce.
Desse modo, a função reduce pode sempre assumir que os dados
que ela recebe estão em ordem. E, como ocorre com quase todas
as partes do framework, o usuário tem flexibilidade para definir
sua própria função de comparação, que será utilizada para gerar
o ordenamento.
Já o sistema de arquivos distribuído usa a arquitetura HDFS e se be-

neficia de suas informações para aproveitar ao máximo a localidade de
dados. Desse modo, apesar de cada camada poder ser utilizada de ma-
neira independente, as camadas funcionam melhor quando trabalham
juntas. Além disso, como os resultados dos jobs MapReduce também
ficam disponíveis no HDFS, esse sistema de arquivos funciona como
um elemento fundamental de comunicação do Hadoop.
Após a finalização de todos os maps, o framework instanciará tantos

jobs reduce quanto houverem chaves intermediárias. As saídas são, ge-
ralmente, consolidadas em um arquivo único de saída para o job. Além
das opções tratadas até agora, há uma infinidade de outros pontos de
configuração. Em geral, qualquer aspecto do framework pode ser con-
figurado para aplicações específicas.
IMPORTANTE
Assim como a arquitetura HDFS, a arquitetura do MapReduce no

Hadoop é do tipo master/worker, no qual existe um nó principal, cha-
mado JobTracker, com quem os clientes submetendo jobs se comu-
nicam. Desse modo, o sistema se torna bastante resistente a falhas.
Plataformas de Big Data 125

Na prática, o Apache Hadoop só tem valor quando usado em conjun-
to com outras soluções disponíveis (WHITE, 2015). Por esse motivo, a
plataforma tem sido considerada um ecossistema que reúne inúmeros
projetos. A figura 1 apresenta os projetos relacionados, e a tabela se-
guinte, uma descrição de cada componente.
Figura 1 – Ecossistema Apache Hadoop
Ambari
R. Connectors
Mahout
Sqoop
Oozie
Hive
Pig
Hbase
YARN Map Reduce v2
Zookeeper
Flume
HDFS
Fonte: adaptado de Sammer (2012).
O componente HDFS é o responsável pela materialidade (armaze-

namento distribuído) e desempenho (processamento distribuído). Cada
um desses componentes segue um versionamento independente.
Quadro 1 – Componentes do ecossistema Apache Hadoop
COMPONENTE DESCRIÇÃO
Flume Ingestão de streams de dados volumosos a partir de múltiplas fontes.
Sqoop Integração de dados entre Hadoop (HDFS) e bancos estruturados.
Zookeeper Serviço de alto desempenho para coordenação de aplicações distribuídas.
(cont.)

COMPONENTE DESCRIÇÃO
YARN Gerenciamento de recursos do cluster Hadoop.
HBase Banco de dados NoSQL que trabalha em conjunto com o HDFS.
Oozie Agendamento de jobs (Hadoop ou não).
Criado pelo Yahoo, é uma tentativa de fornecer uma linguagem de alto nível,
Pig acrescida de um framework de execução para computação paralela que permite
análises de arquivos muito grandes. É uma linguagem de alto nível.
Mahout Implementação para aprendizado de máquina e mineração de grafos.
Conectores com o ambiente R. R é um ambiente gratuito e de código aberto que

Conectores R
propicia análises estatísticas e com recursos gráficos.
Criado pelo Facebook, é uma camada de data warehouse que roda em cima do
Hive Hadoop. Utiliza uma linguagem chamada Hive SQL, similar à SQL, o que facilita
sua utilização.
Ambari Provisão, gerenciamento e monitoração de clusters Hadoop.
Tal como ocorre com outros sistemas baseados em software livre

(notavelmente com o sistema operacional Linux), o administrador da
ferramenta Hadoop deve garantir compatibilidade entre todos esses
componentes. Essa tarefa é importante e oferecida por uma distribui-
ção Hadoop (LUBLINSKY; SMITH; YAKUBOVICH, 2013).
Para tanto, algumas empresas especializadas surgem com o objetivo

de dar um formato industrializado a esses componentes e acabam por
fomentar essas iniciativas. Em outras palavras, a empresa inicia com
uma versão estável do software distribuído com um código-fonte livre, e
então o coloca sob controle de versionamento próprio, comprometendo-
-se, assim, a corrigir eventuais falhas de segurança e erros críticos, for-
necer pacotes de instalação para diferentes sistemas operacionais, exe-
cutar rigorosos processos de testes, além de oferecer treinamento e um
nível de suporte do produto a seus clientes. No caso do Apache Hadoop,
existem as chamadas distribuições Hadoop, criadas e mantidas por em-
presas especializadas (LUBLINSKY; SMITH; YAKUBOVICH, 2013).

Atualmente, as maiores distribuições de Hadoop são fornecidas pe-
las empresas Cloudera, Hortonworks e MapR. É importante observar que
existem ainda distribuições criadas por grandes empresas de tecnologia,
tais como IBM e EMC, mas que não possuem o mesmo nível de acei-
tação no mercado. Além disso, outras grandes companhias, como Intel,
Microsoft e Teradata, tentaram criar suas próprias distribuições Hadoop,
mas acabaram optando por firmar parceria com uma das três empresas
citadas anteriormente (LUBLINSKY; SMITH; YAKUBOVICH, 2013).
2 Weka
A plataforma Weka, construída pela Waikato University, na Nova
Zelândia, consiste em um banco de programas em Java com os princi-
pais algoritmos de mineração de dados (SOURCEFORGE, 2016).
Para a utilização da plataforma são necessárias as massas de trei-

namento e as de testes. As massas de treinamento são os dados usa-
dos para treinar o algoritmo. Já as massas de testes são usadas para
testar o algoritmo com os próprios dados de treinamento.
A próxima figura ilustra a interface explorer do software Weka. O seu

manuseio é composto de cinco passos:
•• Abertura dos arquivos de treinamento.
•• Escolha do classificador: entre as dezenas de classificadores ofe-

recidos pelo Weka, temos os:
◦◦ baseados em árvores de decisão (J48);

◦◦ baseados em máquinas de vetores de suporte (SMO);
◦◦ baseados em análise de clusters (K-means);
◦◦ baseados em métodos bayesianos (Bayes Net).
•• Escolha dos métodos de testes: em geral, a experiência é repetida
dez vezes.

•• Execução do treinamento e verificação dos resultados de testes:
os dados de treinamento são misturados e reamostrados para

classificação.
•• Geração do programa classificador: o programa é uma classe em

Java obtida pelos dados de treinamento.
O formato de arquivo de treinamento e de teste adequado a esta

plataforma é o attribute-relation file format (ARFF), que é o formato es-
perado pelos componentes do software Weka (SOURCEFORGE, 2016).
Um arquivo no formato “.ARFF” é um arquivo de texto puro, composto
de três partes:
•• Relação: a primeira linha do arquivo, que deve ser igual a @rela-

tion seguida de uma palavra-chave que identifique a relação ou
tarefa estudada.
•• Atributos: um conjunto de linhas no qual cada uma inicia com

@attribute seguida do nome do atributo e do seu tipo, que pode ser
nominal ou numérico. Se for nominal, elas devem aparecer como
uma lista, separadas por vírgulas e cercadas por chaves. Caso
seja numérico, o nome deve ser seguido da palavra-chave real.
Geralmente em uma tarefa de classificação supervisionada, na

qual conhecemos as classes das instâncias usadas para treina-
mento, o último atributo é a classe para as instâncias.
•• Dados: cada linha deve corresponder a uma instância e deve ter

valores separados por vírgula correspondentes (e na mesma or-
dem) dos atributos da seção atributos. Esses valores são inseri-
dos depois de uma linha contendo @data.
3 Tableau
O Tableau é um software de análise que combina exploração e visu-
alização de dados em um único aplicativo. Ele é capaz de importar da-
dos de arquivos, ou banco de dados, e visualizá-los de diversas formas

possíveis. Alguns exemplos de visualização disponíveis nele são: gráfi-
co em barras, pizza e linha, mapas geográficos, bolhas de ar, mapas de
calor, dentre outros. Também é possível efetuar relacionamento entre
arquivos ou base de dados, criar filtros e campos calculados (RUETER;
FIELDS, 2012).
As equipes de TI podem gerenciar os dados e metadados de forma

centralizada, controlar as permissões e garantir o atendimento de um
número maior de clientes (RUETER; FIELDS, 2012).
NA PRÁTICA
Assim como o Google, a Tableau Software nasceu na Universidade
Stanford, em 2002, a partir de projetos de pesquisa de doutorandos
na área de visualização de dados provenientes de bancos de dados
relacionais multidimensionais de grande volume. É uma das cin-
quenta empresas que mais crescem nos Estados Unidos, tendo suas
aplicações usadas por mais de 30 mil pessoas ao redor do mundo
e por clientes como Google, GM, Microsoft, Citrix, Citigroup, Wells
Fargo, Coca-Cola, ExxonMobil e Walmart.

O Tableau baseia-se em três conceitos:
•• Conectar: a uma fonte de dados qualquer (arquivos simples

e bancos de dados transacionais ou analíticos, relacionais ou
multidimensionais).
•• Analisar: visualizar, filtrar, classificar, efetuar cálculos, reorgani-

zar e sumarizar os dados.
•• Compartilhar: publicando resultados aos demais usuários em

servidor próprio, embutidos em páginas da organização ou na
forma de arquivos em formato Microsoft Office ou PDF.
É possível analisar na figura 2 a solução Tableau: os workbooks

(como são chamadas suas visualizações e painéis) são criados com a
ferramenta Tableau Desktop e publicados em uma instância do Tableau
Server. As fontes de dados podem ser diversas, como: bancos de dados,

cubos, planilhas eletrônicas e arquivos do Hadoop armazenados no
HDFS. Em seguida, esses workbooks podem ser acessados pelos usu-

ários finais:
•• a partir de uma estação de trabalho convencional, por meio do

Tableau Reader ou de um navegador web;
•• a partir de dispositivos móveis (tablets e smartphones), via apli-

cações nativas (iOS ou Android) ou navegador Web.
Figura 2 – Elementos do software Tableau
Desktop Navegador Tablets Celulares
Tableau
Bancos de dados
Conexão ao vivo
em memória principal
Banco de dados Cubos Planilhas eletrônicas Hadoop e mais
Fonte: adaptado de Rueter e Fields (2012).

4 Exemplos de aplicação
Algumas empresas têm aplicado a análise de grandes volumes de
dados para otimizar as suas operações ou melhorar os serviços aos
seus clientes (FEINLEIB, [s/d]). Dentre os vários casos de sucesso, po-
demos citar:
•• Google, Amazon e Netflix têm adotado técnicas de Big Data como

estratégia no plano de negócios desde a sua criação.
•• Algumas empresas de transporte aéreo têm utilizado Big Data

e sensores distribuídos para melhorar as suas atividades, como
a estimativa de tempo de chegada de um voo (conhecido como
ETA), aumentando a eficiência operacional e evitando que a equi-
pe de solo não esteja a postos quando a aeronave pousar.
•• A Sears, rede de lojas de departamento norte-americana, utiliza

os seus dados para gerar promoções de produtos de maneira
mais rápida e eficaz.
No Brasil, algumas empresas já estão usando o Big Data em áreas

críticas, nas quais as vantagens competitivas representam um incre-
mento de valor para o negócio. Dentre essas empresas, podemos citar:
Petrobras, Serasa Experian, Itaú e Banco do Brasil (DALMAZO, 2012).
Além da aplicação de economia de mercado no mundo corporativo,

o Big Data e suas ferramentas analíticas têm grande potencial para me-
lhorar a eficiência dos governos e a vida dos cidadãos, especialmente
quando aplicadas nas áreas da saúde, segurança pública e planejamen-
to estratégico de políticas públicas.
Um estudo realizado nos Estados Unidos, encomendado pela SAP

AG e publicado pela TechAmerica Foundation (TECHAMERICA FOUND,
[s/d]) revelou que 87% dos funcionários federais de TI afirmam que o
Big Data pode gerar impactos positivos imediatos sobre a forma com
que os governos trabalham. A pesquisa, feita com cerca de duzentos

funcionários públicos da área de TI dos Estados Unidos, constatou que
83% dos funcionários federais acreditam que as soluções de Big Data

podem ajudar o governo a cortar custos em, no mínimo, 10%, ou o equi-
valente a 380 bilhões de dólares.
Ainda segundo esses gestores de TI, o Big Data pode aprimorar a

qualidade de serviços sociais oferecidos à população, bem como salvar
vidas quando aplicado aos serviços de saúde. A análise em tempo real
das informações tem muito mais valor para os entrevistados do que
trabalhar da forma tradicional (TECHAMERICA FOUND, [s/d]).
PARA PENSAR
Uma das maiores barreiras para explorar os benefícios do Big Data nas
organizações e governos são as questões de privacidade. O desafio é
demonstrar de forma assertiva que a análise de Big Data não é equiva-
lente ao “Big Brother”. Outro desafio apontado é a incerteza quanto ao
Retorno sobre Investimento (ROI), pois o Big Data envolve tecnologia de
ponta de alto custo e mão de obra especializada.
Este capítulo apresentou algumas plataformas para Big Data, como
o Apache Hadoop e suas distribuições, o Weka e o Tableau.
As plataformas de Big Data ainda apresentam vários desafios técni-

cos e de gestão. A infraestrutura de Tl (hardware e software) deve estar
preparada para o processamento em tempo aceitável, escalabilidade
massiva de dados, integração de bases heterogêneas e computação
distribuída.
Já a infraestrutura de rede deve ser capaz de suportar a transferên-

cia de grandes conjuntos de dados em alta velocidade, mantendo níveis

elevados de segurança e controle de privacidade dos servidores e arma-
zenamento distribuídos.
Por fim, as empresas e os governos que utilizaram as plataformas de

Big Data, a exemplo das que foram apresentadas neste capítulo, eco-
nomizaram bilhões de dólares em gastos anuais ao tornarem a gestão
mais eficiente.
Referências
DALMAZO, Luiza. Um fenômeno chamado Big Data. Revista Exame, n. 1025,

out. 2012.
FEINLEIB, David. The Big Data landscape, [s/d]. Disponível em: <http://www.
bigdatalandscape.com/>. Acesso em: 6 jan. 2017.
LUBLINSKY, Boris; SMITH, Kevin; YAKUBOVICH, Alexey. Professional Hadoop

solutions. Hoboken: Wiley, 2013.
RUETER, Marc; FIELDS, Ellie. Tableau for the enterprise: an overview for IT.
Seattle, 2012. Disponível em: <https://www.tableau.com/sites/default/files/whi-
tepapers/whitepaper_tableau-for-the-enterprise_0.pdf>. Acesso em: 6 jan. 2017.
SAMMER, Eric. Hadoop operations: a guide for developers and administrators.

Sebastopol: O’Reilly Media, 2012.
SOURCEFORGE. Weka: machine learning software to solve data mining

problems. Dezembro, 2016. Disponível em: <https://sourceforge.net/projects/
weka/>. Acesso em: 6 jan. 2017.
TECHAMERICA FOUND. Big Data and the public sector: a survey of IT deci-
sion makers in federal and state public sector organizations. New York, [s/d].
Disponível em: <https://www.splunk.com/pdfs/fact-sheets/sap-public-sector-
-big-data-report-final-2.pdf>. Acesso em: 6 jan. 2017.
WHITE, Tom. Hadoop: the definitive guide. Sebastopol: O’Reilly Media, 2015.

Capítulo 10
Novas fontes de
dados para Big Data
Este capítulo vai apresentar algumas novas fontes de dados para Big
Data. A aderência dos portais web às premissas de dados abertos pode
ser considerada um importante passo rumo à web semântica.
Para nos aprofundarmos no assunto, vamos estudar os dados aber-

tos, a web semântica, os dados ligados e a internet das coisas. Dados
abertos são as informações produzidas e utilizadas livremente, reutili-
zadas e redistribuídas por qualquer pessoa, sem qualquer restrição. Já
a web semântica é uma teia de informações construída de maneira a
ser facilmente processável por máquinas em uma escala global, cons-
truindo um banco global de dados ligados, os quais, de alguma forma,
135
estão interligados na web. A internet das coisas, por sua vez, é uma
outra fonte de dados que deve ganhar muita importância nos próximos
anos.
1 Dados abertos
O conceito de dados abertos (ou open data, em inglês) é antigo e re-
mete a diferentes significados de acordo com o contexto em que é utili-
zado. Neste livro utilizaremos a definição do World Wide Web (W3C). De
acordo com essa definição, o conceito de dados abertos é a publicação
dos dados em seu formato bruto, compreensível por máquinas, para
o seu pleno reaproveitamento em aplicações desenvolvidas por outros
(W3C, 2013). É importante ressaltar que o conceito de “compreensível
por máquinas” implica a publicação dos dados e os seus metadados
em formato que pode ser interpretado eletronicamente, permitindo pro-
cessamento eletrônico.
PARA SABER MAIS
O W3C é um consórcio internacional cujo objetivo é conduzir e apri-

morar a World Wide Web (www) para que atinja todo seu potencial,
desenvolvendo protocolos e diretrizes que garantam seu crescimen-
to de longo prazo.
O melhor uso que poderá ser feito com os seus dados certamente
será desenvolvido por outros, e não por você (BERNERS-LEE; HENDLER;
LASSILA, 2001). Em outras palavras, uma pessoa externa consegue vi-
sualizar melhor novas possibilidades de combinação dos dados com
outras fontes disponíveis.
O quadro a seguir apresenta os princípios fundamentais dos dados

abertos, definidos por três leis (W3C, [s/d]a):

•• Se ele não pode ser encontrado na web e indexado, ele não existe.
•• Se não estiver aberto e disponível em formato compreensível por

máquina, ele não pode ser utilizado.
•• Se qualquer dispositivo legal não permitir que ele seja reutilizado,

ele não é útil.
Quadro 1 – Princípios fundamentais dos dados abertos
PRINCÍPIO DESCRIÇÃO
Estar disponível e não limitado. Um dado público é o dado que não

Completo está sujeito a limitações válidas de privacidade, segurança ou privilégios
de acesso.
Primário Devem estar disponíveis sem agregação ou modificação.
Atual Publicados tão rapidamente quanto necessário para preservar o seu valor.
Para o maior número possível de usuários e para o maior número possível

Acessível
de finalidades.
Processável por
Razoavelmente estruturados para permitir processamento automatizado.
máquina
Não discriminatório Disponíveis para todos, sem necessidade de cadastro.
Não proprietários Formato sobre o qual nenhuma entidade tem controle exclusivo.
Os dados não estão sujeitos a nenhuma regulação de direitos autorais,

patentes, propriedade intelectual ou segredo industrial. Restrições
Licença livre
sensatas relacionadas à privacidade, segurança e privilégios de acesso
podem ser permitidas.
Podemos concluir que o objetivo principal dos dados abertos é a pu-

blicação dos dados de forma completa e primária, de maneira que se-
jam acessíveis, estejam prontamente disponíveis para todos e possam
ser reutilizados, permitindo a apresentação integrada de dados.
Esse objetivo atende perfeitamente ao conceito de governo aberto, ou

dados governamentais abertos, que será apresentado a seguir.
Novas fontes de dados para Big Data 137

1.1 Dados governamentais abertos
Os dados governamentais abertos (ou open government data, em
inglês) são informações públicas governamentais que são compartilha-
das com os cidadãos na forma digital, por meio da web, promovendo
sua análise e reutilização (W3C [eGovernment], [s/d]a). O conceito ga-
nhou popularidade no movimento de transparência e governo aberto
em todo mundo (W3C [eGovernment], [s/d]a), cujo princípio é compar-
tilhado pela abertura de dados: tratar o acesso à informação pública
como regra, não como exceção.
PARA SABER MAIS
Prover o acesso às informações governamentais, permitindo o seu

reuso, é uma tendência dos governos eletrônicos de vários países.
No entanto, o uso ético e lícito deve ser garantido. Entre as preocupa-
ções acerca deste assunto está a utilização dos dados para fins de
comercialização por empresas privadas, por meio de grandes bases
de dados consolidados e o uso dos dados por criminosos para a
descoberta de potenciais alvos de sequestro e extorsão.
No Brasil, alguns dispositivos legais regulamentam e tornam obriga-

tória a transparência pública. A Lei complementar 131/2009 é uma ex-
tensão do princípio constitucional elencado no artigo 37 da Constituição
Federal do Brasil, que dispõe: “A administração pública direta e indireta
de qualquer dos Poderes da União, dos Estados, do Distrito Federal e
dos Municípios obedecerá aos princípios de legalidade, impessoalidade,
moralidade, publicidade”. O principal objetivo dessa lei é regulamentar a
criação de mecanismos para disponibilizar informações pormenoriza-
das para a sociedade, em tempo real, sobre a execução orçamentária e
financeira da União, dos Estados e Municípios.
A aderência às premissas de dados abertos pode ser considerada

um importante passo rumo à web semântica.

2 Web semântica
A web está evoluindo para uma nova versão que possibilitará que
computadores interpretem, integrem-se, estabeleçam inferências e re-
lações sobre os dados. Essa nova versão da web é denominada web
semântica (BERNERS-LEE; HENDLER; LASSILA, 2001).
A arquitetura da web semântica se apoia em um conjunto de cama-

das para a identificação de recursos na web, proposto pelo W3C. Um
recurso pode ser definido como um objeto qualquer, ou seja, algo que o
usuário deseja descrever. Os recursos podem ser autores, livros, publi-
cações, lugares, pessoas, hotéis, salas, resultado de buscas, etc. Todo
recurso tem uma URI (uniform resource identifier) ou qualquer outro tipo
de identificador único associado (W3C, 2013).
Além da identificação de recursos, são definidas camadas com re-

gras para a representação sintática, estrutural, semântica e lógica de
informações referentes a esses recursos (W3C, 2013). Essas camadas
estão formalizadas em um conjunto de especificações.
A próxima figura ilustra as camadas da arquitetura da web semânti-

ca: a camada básica de dados (os padrões URI e unicode), a camada de
descrição sintática (o padrão XML), a camada de descrição semântica
e estrutural (o padrão RDF), a camada de descrição semântica e lógica
(os padrões SPARQL, OWL, RIF e RDF-S), a camada de descrição lógica
(o framework de lógica), a camada de prova e a camada de confiança
(W3C, 2013).

Figura 1 – Proposta atual do W3C para a web semântica
Interface do usuário e aplicações
Confiável
Provas
Lógica
Ontologia: OWL Regras: RIF

Consulta:
SparQL
Assinatura
RDF-S
digital
Troca de dados: RDF
XML
URI Unicode
Fonte: adaptado de W3C (2013).
No contexto deste livro, apenas os padrões URI, RDF, SPARQL e OWL

serão tratados e apresentados a seguir.
2.1 Uniform resource identifier
A uniform resource identifier (URI) é uma cadeia compacta de ca-

racteres, usada para identificar ou denominar um recurso na web. Ela
permite a interação com representações do recurso por meio do HTTP
(ANTONIOU; VAN HARMELEN, 2008).
Uma URI é composta por um localizador (URL) ou um nome (URN),

ou ainda, por ambos. A uniform resource locator (URL) é um método de

pesquisar um recurso, já a uniform resource name (URN) define a iden-
tidade de um recurso.
A utilização de URIs para identificar unicamente qualquer recurso e
a relação entre eles é muito importante, pois permite um esquema de
nome único e global por toda a web. Isso pode minimizar o problema
atual de homônimos de recursos na representação dos dados distribuí-
dos pela web (ANTONIOU; VAN HARMELEN, 2008).
2.2 Resource description framework

O resource description framework (RDF) é uma recomendação W3C
para a padronização de descrições de metadados para recursos base-
ados na web, sendo uma forma bastante adequada para representar
dados (ANTONIOU; VAN HARMELEN, 2008).
Um bloco básico em RDF é uma declaração composta de uma tripla
seguida de um recurso, uma propriedade e um valor, respectivamente.
A tripla é composta por um sujeito (S), um predicado (P) e um objeto
(O). Já os recursos são identificados por URI e geralmente por URLs.
As propriedades são um tipo especial de recurso e descrevem relações
entre recursos, por exemplo, “escrito por”, “idade”, “título”, etc. Por fim, os
valores podem ser literais, que são valores atômicos (strings), ou ainda
outros recursos. Desta maneira é construída uma teia ou grafo.
NA PRÁTICA
Imagine que desejamos representar as informações de uma pessoa

(nome, e-mail e irmãos) em RDF, no caso, o João da Silva. A tripla
RDF para o exemplo é composta por três sujeitos “S={pedro, joao,
maria}”, três predicados “P={temNome, temIrmao, temEmail}” e dois
objetos “O={“João da Silva”, “joao@email.com”}”. A figura a seguir
ilustra essa tripla. É possível perceber ainda que temos mais de uma
tripla; para saber a quantidade correta, basta contar a quantidade de
sujeitos (neste caso, três triplas).

Figura 2 – Exemplo de tripla RDF
“João da Silva”
temnome
temirmao joao
pedro
temEmail
temirmao
maria
“joao@email.com”
Por meio dessa representação é possível perceber que João tem

dois irmãos, Pedro e Maria. Outro detalhe interessante é que para a pro-
priedade “temEmail” o “joao” é um sujeito. Já para as duas propriedades
“temIrmao”, o “joao” é um objeto. Desta forma é construído o grafo RDF
com inúmeras triplas.
2.3 Ontology web language
A ontology web language (OWL) é a linguagem padronizada pelo W3C

para a construção de ontologias (ANTONIOU; VAN HARMELEN, 2008).
Ela é uma linguagem para uso em aplicações que precisam processar
o conteúdo da informação, facilitando a interpretação do conteúdo da
web por máquinas e com expressividade maior do que o RDF.
Além disso, fornece um vocabulário adicional juntamente com uma

semântica formal. A linguagem OWL é uma das principais linguagens
da arquitetura da web semântica e possui três sublinguagens em nível
crescente de expressividade: OWL Lite, OWL DL e OWL Full.

2.4 Protocol and RDF query language
A SPARQL protocol and RDF query language (SPARQL) é uma lingua-

gem de consultas para RDF e OWL e foi padronizada pela RDF Data
Access Working Group (DAWG) do W3C. Ela é considerada uma tecno-
logia-chave da web semântica para recuperar informações.
A SPARQL permite consultas compostas por triplas, conjunções,

disjunções e padrões opcionais, e possibilita extrair valores de dados
estruturados e semiestruturados, realizar combinações complexas de
bases heterogêneas em uma única simples consulta e transformar da-
dos RDF de um vocabulário para outro. Uma consulta SPARQL é com-
posta de:
•• PREFIX: para abreviar a URI;
•• Definição de dataset: define o grafo RDF que será consultado.

No contexto deste livro, dataset é uma coleção de dados publi-
cados e mantidos por um único provedor, disponível em RDF na
web, e acessível, por exemplo, por meio de URIs (ANTONIOU; VAN
HARMELEN, 2008);
•• Cláusula de resultado: identifica qual informação será retornada

pela cláusula de consulta;
•• Cláusula de consulta: define o que consultar no dataset

especificado;
•• Modificador da consulta: filtros, ordenação e outros ajustes no

resultado da consulta.
PARA SABER MAIS
Se você quiser aprender mais sobre a sintaxe da linguagem SPARQL,

poderá obter detalhes nas páginas oficiais do W3C.

Após a disponibilização dos dados abertos, o próximo passo é a
reutilização desses dados, interligando-os com outras fontes de dados
disponíveis.
3 Dados ligados
O conceito de dados ligados (ou linked data, em inglês) refere-se à
utilização da web para interligar dados relacionados que não estavam
previamente interligados ou simplesmente a uma boa prática reco-
mendável para expor, compartilhar e conectar fragmentos de dados,
informação e conhecimento na web semântica por meio de URIs e RDF
(CYGANIAK; JENTZSCH, 2014).
NA PRÁTICA
Um exemplo de dados abertos em funcionamento é a DBPedia. Tra-

ta-se de um esforço comunitário para extrair informações estrutura-
das da Wikipédia e disponibilizá-las na web. Ela permite a realização
de sofisticadas consultas na enciclopédia on-line, além da interliga-
ção de seu conteúdo com outros datasets disponíveis na web.
4 Internet das coisas

A internet das coisas (ou Internet of Things [IoT], em inglês) refere-
-se a objetos unicamente identificáveis e que sejam capazes de trocar
informações por meio de uma estrutura de rede, como a internet. É
uma revolução tecnológica que representa o futuro da computação e
da comunicação, e cujo desenvolvimento depende da inovação técnica
dinâmica em campos da eletrônica, como os sensores sem fios, a nano-
tecnologia e os dispositivos embarcados (W3C, [s/d]b).

Em outras palavras, a IoT é o termo genérico utilizado para denomi-
nar a ampla disponibilidade de sensores e comunicação em rede por

objetos ou máquinas que antes não tinham essa característica, desde
máquinas-ferramenta no chão de fábrica até automóveis e edifícios,
muitos objetos geralmente considerados “não conectados”.
Para que seja possível ligar os objetos e aparelhos a grandes ba-

ses de dados e redes de comunicação, é necessário primeiro que haja
um sistema eficiente de identificação que colete e registre dados sobre
cada uma dessas coisas.
Embora algumas vezes identificada puramente como a sucessora

dos códigos de barras, a tecnologia de identificação por rádio frequên-
cia (ou radio frequency identification, em inglês [RFID]) permite não só
a identificação de um objeto, como também a coleta de informações
importantes sobre o seu estado e localização.
Etiquetas (ou tags) RFID, inicialmente usadas na indústria farma-

cêutica e em grandes armazéns, hoje já são utilizadas para as mais
diversas aplicações, tais como: acompanhamento do estado de saúde
de pacientes; armazenamento de informações digitais em documentos,
como passaportes e habilitações de motorista; ou para fins de paga-
mento em dispositivos móveis (W3C, [s/d]b).
A IoT também se beneficia da capacidade de detectar mudanças na

qualidade física das coisas ou no meio à sua volta (sensibilidade ao
contexto), usando as tecnologias sensoriais (redes de sensores), que
podem se comunicar por meio de cabos ou mesmo sem fios. Devido
aos baixos custos de infraestrutura necessária para acomodar a co-
municação eletrônica sem fio, esse tipo de sistema tem prevalecido no
mercado.
É interessante ressaltar que não necessariamente todos os elemen-

tos de uma IoT devam estar conectados à internet e publicamente dis-
poníveis. Eles podem estar simplesmente conectados em uma rede

local, parcial ou totalmente confinada. É o que acontece, por exemplo,
em um sistema instalado em um prédio inteligente: as informações
captadas a partir dos sensores podem estar disponíveis apenas local-
mente para fins de gerenciamento e controle das variáveis, não devendo
ser expostas na internet.
PARA SABER MAIS
Poderemos usar óculos para receber chamadas de vídeo, e os aten-

dimentos médicos poderão ser prestados de forma antecipada gra-
ças a diagnósticos mais rápidos e eficientes (W3C, [s/d]b).
Este capítulo apresentou algumas novas fontes de dados para Big
Data, por exemplo os dados abertos e os dados abertos de governo, a
web semântica e a internet das coisas.
O uso de dados abertos pode permitir a produção de novas infor-

mações e aplicativos, propiciando ao interessado usar essa informa-
ção da forma mais apropriada para atingir seus objetivos, obtendo um
panorama mais preciso do trabalho, e adaptá-la às suas necessidades
particulares, em especial, para o acompanhamento de ações e políticas
do governo.
Para o desenvolvimento da web semântica estão sendo utilizadas

diversas técnicas (W3C, 2013), dentre elas as ontologias. O uso de onto-
logias para representar o conhecimento e anotar a informação contida
na web permitirá o desenvolvimento de novos mecanismos de integra-
ção de dados, a interoperabilidade semântica e as buscas semânticas.
Entretanto, criar ontologias e anotar o conteúdo de forma estruturada é
um processo complexo e demorado (CHU, 2013).

A IoT deve aumentar ainda mais o volume de dados existentes
atualmente (MAYER-SCHONBERGER; CUKIER, 2013). Como as imple-

mentações tendem a ser rápidas e os dados são gerados automatica-
mente, os requisitos de consistência e unicidade geralmente requeridos
para bancos de dados tradicionais são substituídos por agilidade de
criação das aplicações e facilidade de paralelização.
Referências
ANTONIOU, Grigoris; VAN HARMELEN, Frank. A semantic web primer. Boston:
The MIT Press, 2008.
BERNERS-LEE, Tim; HENDLER, James; LASSILA, Ora. The semantic web: a new
form of web content that is meaningful to computers will unleash a revolution
of new possibilities. Scientific American, v. 284, p. 34-43, 2001.
CYGANIAK, Richard; JENTZSCH, Anja. The linking open data cloud diagram.
Insight. Dublin, 2014. Disponível em: <http://lod-cloud.net/>. Acesso em: 5 jan.
2017.

W3C. W3C semantic web activity. W3C, 2013. Disponível em: <https://www.
w3.org/2001/sw/>. Acesso em: 5 jan. 2017.
______. eGovernment at W3C: better government through better use of the web.
W3C, [s/d]a. Disponível em: <https://www.w3.org/egov/>. Acesso em: 5 jan.
2017.
______. Web of things at W3C. W3C, [s/d]b. Disponível em: <https://www.w3.org/

WoT/>. Acesso em: 5 jan. 2017.

148
Sobre o autor
Alexandre Lopes Machado possui doutorado (2013) e mestrado

(2007) em engenharia eletrônica e computação, ambos pelo Instituto
Tecnológico de Aeronáutica (ITA) e graduação em sistemas de informá-
tica (2001). Atualmente é analista do Serviço Federal de Processamento
de Dados (Serpro) e professor de graduação e pós-graduação do Centro
Universitário Senac (Senac/SP). Membro dos grupos: SemantiComp
(Semantic Computing Group) do ITA, The International Association for
Ontology and its Applications (IAOA) e World Wide Web Consortium
(W3C) Escritório Brasil. Além disso, tem experiência na área de ciên-
cia da computação, com ênfase em sistemas de computação, atuando
principalmente nos seguintes temas: banco de dados, Big Data, mode-
lagem conceitual, ontologias, ontologia legal, web semântica, computa-
ção em nuvem e governo eletrônico.
Currículo Lattes disponível em: <http://buscacv.cnpq.br/buscacv/#/

espelho?nro_id_cnpq_cp_s=1039770849500809>.
149
150

Merged All

Enviado por

Dados do documento

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

Merged All

Enviado por

Direitos autorais:

Formatos disponíveis

Gestão

De posse de tal conhecimento, explicaremos quais habilidades são esperadas de um

Na sequência, conceituaremos cada tipo de requisito a partir de exemplos práticos.

Por fim, apresentaremos os principais modelos de processo de desenvolvimento de

Ao fim desta aula, esperamos que o aluno conheça a importância da engenharia de

Mas, afinal, o que é requisito?

Para o Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE, 2014), requisito é

A grande questão envolvida é que os engenheiros de requisitos não conhecem os

Senac São Paulo - Todos os Direitos Reservados 3

Se os stakeholders têm pouca ou nenhuma experiência com software, uma forma

Senac São Paulo - Todos os Direitos Reservados 4

De acordo com o IEEE (2014), a engenharia de requisitos é o processo que envolve

• Elicitação dos requisitos: é a fase que envolve o levantamento de informações para

• Documentação dos requisitos: os requisitos elicitados anteriormente serão

• Validação e negociação dos requisitos: os requisitos de software devem ser

• Gerenciamento de requisitos: é uma fase “guarda-chuva”, que está presente

2 Habilidades de um engenheiro de requisitos

Senac São Paulo - Todos os Direitos Reservados 5

Em uma organização que demanda um software, um dos maiores desafios do engenheiro

O engenheiro de requisitos possui um papel-chave em um projeto de software. Pohl e

Senac São Paulo - Todos os Direitos Reservados 6

Para Sommerville (2011, p. 59), “[...] os requisitos funcionais de um sistema descrevem

• A casa deve possuir uma cozinha com duas janelas de 1 m x 1,10 m;

• A residência deve ter um banheiro vinculado a cada dormitório;

• A casa deve possuir grades de proteção em todas as portas e janelas;

• Em todas as torneiras de água, devem estar disponíveis água quente e fria.

Agora que entendemos que os requisitos funcionais estão ligados essencialmente à

• O sistema deve permitir o cadastro de veículos;

• O sistema deve possibilitar o registro do abastecimento de cada um dos veículos;

• O usuário poderá incluir no cadastro os acessórios pertencentes a cada veículo.

Requisitos não funcionais ou de qualidade

Senac São Paulo - Todos os Direitos Reservados 7

Para Sommerville (2011), os clientes de um sistema têm dificuldades em determinar

Tabela 1 – Métricas para especificar requisitos não funcionais

Fonte: Sommerville (2011, p. 63).

Senac São Paulo - Todos os Direitos Reservados 8

• Cada cômodo da residência deve suportar até 20.000 kg de carga líquida;

• Devem ser utilizados equipamentos (torneiras, fechaduras, louças) que possuam

• O tempo de qualquer transação realizada pelo usuário não pode exceder 20 s;

• Deve ser construído com arquitetura de software em três camadas: apresentação,

4 Requisitos e modelos de processos

4.1 Modelo cascata

Senac São Paulo - Todos os Direitos Reservados 9

falha do modelo cascata é se vincular a um processo de fabricação, e não de criação. Não

Figura 1 – Modelo cascata

Fonte: Pfleeger (2004, p. 39)

• A entrega de software funcional para o cliente ocorrerá apenas no final do projeto e,

4.2 Modelo incremental

Figura 2 – Modelo Incremental

A Comunicação B Planejamento C Modelagem (análise, projeto)

Fonte: Pressman (2011, p. 61).

Dessa forma, utilizando o modelo incremental, a engenharia de requisitos é uma fase

• O custo das mudanças é reduzido. Quando há um ajuste nas definições de requisitos,

• Considerando a baixa capacidade de abstração que os stakeholders têm, apresentar

Senac São Paulo - Todos os Direitos Reservados 11

4.3 Processos ágeis

Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento; processos ágeis

Sommerville (2011) defende que a aproximação com stakeholders oferece maiores

Devemos ressaltar, portanto, o papel fundamental da engenharia de requisitos como

O engenheiro de requisitos, por sua vez, é ator essencial e central em um processo

Senac São Paulo - Todos os Direitos Reservados 12

responsabilidade por definir requisitos consistentes para que as fases posteriores do

Vimos também a conceituação de requisitos funcionais e não funcionais, o que nos

Por fim, apresentamos os principais modelos de processo de desenvolvimento de