UTILIZANDO LINHA DE PRODUTOS DE SOFTWARE PARA GERAÇÃO ESPECÍFICA DE SOFTWARES

Prévia do material em texto

CENTRO UNIVERSITÁRIO DE JOÃO PESSOA - UNIPÊ 
PRÓ-REITORIA DE ENSINO DE GRADUAÇÃO 
CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO 
 
 
 
LEOMAR ILÁRIO DOS SANTOS 
 
 
 
 
 
 
 
 
UTILIZANDO LINHA DE PRODUTOS DE SOFTWARE PARA GERAÇÃO 
ESPECÍFICA DE SOFTWARES 
 
 
 
 
 
 
 
 
JOÃO PESSOA - PB 
2016 
 
 
LEOMAR ILÁRIO DOS SANTOS 
 
 
 
UTILIZANDO LINHA DE PRODUTOS DE SOFTWARE PARA GERAÇÃO 
ESPECÍFICA DE SOFTWARES 
 
 
 
Monografia apresentada ao Curso de 
Bacharelado em Ciência da Computação do 
Centro Universitário de João Pessoa - UNIPÊ, 
como pré-requisito para a obtenção do grau de 
Bacharel em Ciência da Computação, sob 
orientação do Prof. Ms. Josias Paes da Silva 
Júnior. 
 
 
 
 
 
 
 
 
 
 
 
 
JOÃO PESSOA - PB 
2016 
 
 
 
S237u Santos, Leomar Ilário dos. 
 Utilizando Linha de Produtos de Software para geração 
específica de software / Leomar Ilário dos Santos. - João Pessoa, 
2016. 
 98f. 
 Monografia (Curso de Ciências da Computação) – 
 Centro Universitário de João Pessoa – UNIPÊ. 
 
1. Engenharia de Software. 2. Linha de Produtos de Software. 
3. Reusabilidade. 4. Variabilidade. I. Título. 
 
UNIPÊ / BC CDU - 004.41 
 
 
 
 
LEOMAR ILÁRIO DOS SANTOS 
 
 
UTILIZANDO LINHA DE PRODUTOS DE SOFTWARE PARA GERAÇÃO 
ESPECÍFICA DE SOFTWARES 
 
Monografia apresentada ao Curso de Bacharelado em Ciência da Computação do Centro 
Universitário de João Pessoa - UNIPÊ, como pré-requisito para a obtenção do grau de Bacharel 
em Ciência da Computação, apreciada pela Banca Examinadora composta pelos seguintes 
membros: 
 
Aprovada em 06/12/2016. 
 
 
 
BANCA EXAMINADORA 
 
 
 
_________________________________________ 
Prof. Ms. Josias Paes da Silva Júnior 
Orientador 
 
 
_____________________________________________ 
Prof. Dr. Rodrigo da Cruz Fujioka 
Examinador 
 
 
______________________________________________ 
Prof. Esp. Renato Atouguia Leite 
Examinador 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A todos que de alguma forma fizeram parte da minha formação e doaram um pouco de si para 
que a conclusão deste trabalho fosse possível. 
 
 
AGRADECIMENTOS 
 
 
 
A Deus, primeiramente, pois sem Ele eu não teria forças para essa longa jornada. 
 
A minha família por acreditar e investir em mim e por ter paciência com a minha ausência, 
assim como a todos os professores e colegas do curso que foram muito importantes na minha 
vida acadêmica. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
RESUMO 
É inegável que a Engenharia de Software contribui de forma fundamental para o 
desenvolvimento de sistemas, fazendo o uso de métodos que auxiliam em todo ciclo de criação 
e manutenção de um software. Convencionalmente, a Engenharia de Software gera sistemas 
classificados como software individual e software padrão que, atendem a maioria dos usuários. 
Entretanto, o valor dos softwares individuais, pela sua especificidade, é geralmente mais alto e 
o tipo software padrão, por serem tão genéricos, muitas vezes não atendem as diferentes 
perspectivas individuais dos clientes. A metodologia utilizada para esta pesquisa é do tipo 
exploratória através de levantamento bibliográfico sobre o tema. Assim, o paradigma de Linha 
de Produtos de Software vem com o intuito de unir os dois conceitos. A ideia é a produção em 
larga escala (como um software padrão), porém, realizando a individualização de cada sistema 
para que sejam satisfeitas as necessidades específicas de cada cliente (como um software 
individual). Dessa forma, Linha de Produtos de Software tenta absorver os conceitos e práticas 
da Engenharia de Software para tentar ampliar a forma de como o desenvolvimento de sistemas 
é realizado, a partir da reutilização de artefatos do projeto para a geração específica de software. 
 
Palavras Chave: Engenharia de Software. Linha de Produtos de Software. Reusabilidade. 
Variabilidade. 
 
 
ABSTRACT 
 
It is undeniable that the Software Engineering contributes in a fundamental way to the 
development of systems, making the use of methods that help in every cycle of creation and 
maintenance of software. Conventionally, Software Engineering generates systems classified 
as individual software and standard software that meets most users. However, the value of 
individual software, its specificity is generally higher and the type standard software, because 
they are so generic, often do not meet the different individual perspectives of customers. The 
methodology used for this research is exploratory through literature on the subject. Thus, the 
Software Product Line paradigm comes with the intention to unite the two concepts. The idea 
is the large-scale production (as a standard software), however, making the individualization of 
each system to the specific needs of each client are met (as an individual software). Thus, 
Software Product Line tries to absorb the concepts and practices of software engineering to try 
to expand as the development of systems is carried out from the reuse project artifacts for the 
specific generation of software. 
 
Key Words: Software Engineering. Software Product Line. Reusability. Variability. 
 
 
 
LISTA DE TABELAS 
 
Tabela 01 - Quantidade de produtos gerados de acordo com o número de features ......... 60 
 
 
 
 
LISTA DE GRÁFICOS 
 
Gráfico 01 - Reutilização em Linha de Produtos ................................................................... 15 
Gráfico 02 - Custo inicial de uma LPS .................................................................................. 41 
 
 
 
 
LISTA DE ILUSTRAÇÕES 
Figura 01 - Fases da Metodologia .......................................................................................... 17 
Figura 02 - As três atividades essenciais da ELPS ............................................................... 31 
Figura 03 - Processo de Engenharia de Domínio ................................................................. 32 
Figura 04 - Processo de Engenharia de Aplicação ............................................................... 34 
Figura 05 - Destaque da variabilidade na Engenharia de Domínio ..................................... 37 
Figura 06 - Exemplo de Modelo de Features ........................................................................ 40 
Figura 07 - Fluxo de compilação da linguagem Python ....................................................... 46 
Figura 08 - Modelo de features do GenCommerce ............................................................. 57 
Figura 09 - Tela de configuração das variabilidades ............................................................ 64 
Figura 10 - Tela inicial .......................................................................................................... 66 
Figura 11 - Tela de detalhes de produtos .............................................................................. 67 
Figura 12 - Tela de cadastro de usuário ................................................................................ 68 
Figura 13 - Tela de login ........................................................................................................ 69 
Figura 14 - Tela de contato ....................................................................................................69 
Figura 15 - Tela após login .................................................................................................... 70 
Figura 16 - Configuração para a feature Últimos Vistos ..................................................... 71 
Figura 17 - Resultado da feature Últimos Vistos ................................................................. 71 
Figura 18 - Configuração para a feature Destaque Promoção ............................................. 72 
Figura 19 - Resultado da feature Destaque Promoção em bloco ......................................... 72 
Figura 20 - Resultado da feature Destaque Promoção em lista).......................................... 73 
Figura 21 - Configuração para a feature de Pagamentos ..................................................... 74 
Figura 22 - Resultado da feature de Pagamentos .................................................................. 74 
Figura 23 - Resultado das 3 features de Pagamentos ........................................................... 75 
 
 
 
 
LISTA DE ABREVIATURAS E SIGLAS 
 
CSRF - Cross-Site Request Forgery 
BSD - Berkeley Software Distribution 
DRY - Don’t Repeat Yourself 
ELPS - Engenharia de Linha de Produtos de Software 
FODA - Feature Oriented Domain Analysis 
GUI - Graphical User Interface 
IEEE - Institute of Electrical and Electronics Engineers 
LPS - Linha de Produtos de Software 
MVC - Model-View-Controller 
MTV - Model-Template-View 
POA - Programação Orientada a Aspectos 
POO - Programação Orientada a Objetos 
UML - Unified Modeling Language 
XSS - Cross-Site Scripting 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
1 INTRODUÇÃO .................................................................................................................... 13 
1.1 RELEVÂNCIA DO ESTUDO ........................................................................................ 14 
1.2 OBJETIVOS .................................................................................................................... 16 
1.2.1 Objetivo Geral ............................................................................................................. 16 
1.2.2 Objetivos Específicos .................................................................................................. 16 
1.3 INDICAÇÃO DA METODOLOGIA .............................................................................. 16 
1.4 ORGANIZAÇÃO DO TRABALHO ............................................................................... 19 
2 LINHA DE PRODUTOS DE SOFTWARE .................................................................... 20 
2.1 ENGENHARIA DE SOFTWARE ..................................................................................... 20 
2.1.1 Entendendo o que é um software ................................................................................. 20 
2.1.2 Definição de Engenharia de Software .......................................................................... 22 
2.1.3 Qualidade de Software .................................................................................................. 23 
2.1.4 Processos de Software ................................................................................................... 24 
2.1.5 Reuso de software .......................................................................................................... 27 
2.2 LINHA DE PRODUTOS DE SOFTWARE ...................................................................... 28 
2.2.1 Definição de Linha de Produtos de Software .............................................................. 28 
2.2.2 Vantagens da Linha de Produtos de Software ............................................................ 29 
2.2.3 Engenharia de Linha de Produtos de Software .......................................................... 31 
2.2.3.1 Engenharia do Domínio ................................................................................................ 31 
2.2.3.2 Engenharia de Aplicação .............................................................................................. 33 
2.2.3.3 Gerenciamento .............................................................................................................. 35 
2.2.4 Variabilidade em Linha de Produtos de Software ..................................................... 36 
2.2.4.1 Modelo de Features ...................................................................................................... 38 
2.3 LIMITAÇÕES DE LINHA DE PRODUTOS DE SOFTWARE ....................................... 40 
3 TECNOLOGIAS UTILIZADAS ........................................................................................ 42 
3.1 PYTHON ............................................................................................................................ 42 
3.1.1 Django ............................................................................................................................. 47 
3.2 SQLite ................................................................................................................................. 51 
4 IMPLEMENTAÇÃO DA LPS ............................................................................................ 54 
4.1 ENGENHARIA DE REQUISITOS ................................................................................... 55 
4.2 PROJETO ........................................................................................................................... 60 
 
 
4.3 IMPLEMENTAÇÃO DO PRODUTO ............................................................................... 65 
4.3.1 Implementação da Feature Últimos Vistos .................................................................. 70 
4.3.2 Implementação da Feature Destaque Promoção ........................................................ 72 
4.3.3 Implementação das Features de Pagamento ............................................................... 73 
4.4 TESTES .............................................................................................................................. 75 
5 CONSIDERAÇÕES FINAIS .............................................................................................. 77 
REFERÊNCIAS ....................................................................................................................... 79 
APÊNDICE A - Documento de Requisitos .............................................................................. 83 
 
 
13 
 
 
1 INTRODUÇÃO 
A Engenharia de Software tem si mostrado importante para o desenvolvimento da sociedade 
por contribuir de forma produtiva na maneira como os softwares são criados. A mesma utiliza 
métodos e ferramentas de forma organizada no ciclo de desenvolvimento de software indo desde o 
início até o final do processo. Entretanto, o software desenvolvido às vezes não satisfaz totalmente o 
cliente que o adquiriu, no tocante a algumas características observáveis pelos mesmos, exemplo delas 
são o custo e quais tipos de funcionalidades possui o software. 
Sendo assim, da maneira convencional que a Engenharia de Software trabalha, são produzidos 
sistemas que são classificados como software individual e software padrão que, em partes atendem 
aos interesses dos usuários, mas não deixam de ter certas desvantagens. Os softwares do tipo padrão 
possuem menor custo e tempo de produção, porém, por terem suas funcionalidades pensadas para 
tentar atender o máximo de clientes possíveis, acabam sendo mais genéricos e não atendem às 
características específicas de cada cliente. Já os softwares individuais atendem essas características 
específicas, mas seu custo de desenvolvimento é mais elevado, tornando sua aquisição mais onerosa.É nesse cenário que os conceitos do paradigma de Linha de Produtos de Software - LPS se 
encaixam, propondo um diferencial na forma de desenvolvimento de sistemas. LPS tem o intuito de 
usar a reutilização de recursos de forma planejada para satisfazer as necessidades específicas dos 
clientes, utilizando o mesmo núcleo de sistemas de uma forma predeterminada (SEI, 2016). 
Dessa maneira, a LPS tenta abarcar as vantagens existentes nos tipos de desenvolvimento que 
foram apresentadas logo acima. A mistura do conceito de software individual e software padrão pode 
ser encontrada no modo de trabalho da LPS, através de sua forma de planejamento e conclusão dos 
produtos. A LPS une a vantagem de produção de softwares padrões (menor custo e tempo de 
desenvolvimento) e softwares individuais (características específicas atendidas) gerando uma linha 
de produção onde o que é comum se mantém e as variabilidades são inseridas de acordo com as 
necessidades de cada perfil de cliente. 
Diante do que foi exposto, é necessária a demonstração de como isso é viável de acontecer na 
prática. Unindo os conceitos de Engenharia de Software e LPS, como é possível realizar o 
desenvolvimento de vários sistemas (desenvolvimento em massa) gerando sistemas diferentes entre 
eles com características distintas e adaptáveis as peculiaridades de cada cliente? 
14 
 
 
Portanto, este trabalho busca responder a essa questão trazendo toda estrutura teórica 
necessária para entendimento do processo em si, como também uma parte prática através de um caso 
de uso que implementa LPS. 
1.1 RELEVÂNCIA DO ESTUDO 
Na maioria das vezes quando uma empresa desenvolve um sistema para negócios, onde o 
mesmo será utilizado por outras empresas, o software acaba sendo criado de uma forma mais genérica 
com o intuito de prover um produto que abarque os requisitos mais comuns, atendendo assim as 
principais características desejadas. Entretanto, essas empresas que adquiriram o software, 
geralmente possuem uma forma diferente de trabalhar e essas especificidades terão de ser incluídas 
pelo software para se ajustar a tal realidade. Porém, em alguns casos, esses fatores específicos podem 
afetar os de outros clientes. 
Com o uso da abordagem de LPS, pode-se ter como resultado produtos que se adequam às 
necessidades específicas de cada cliente com um menor custo, comparado com o desenvolvimento 
de um software contratado por clientes individuais (COUTO, 2010). Os benefícios ao utilizar uma 
LPS vão além da redução dos custos, como diz o SEI (2016), as melhorias são percebidas no tempo, 
produtividade, qualidade dentre outros fatores. 
Em um estudo de caso onde Clements e Brownsword (1996) desenvolveram sobre o uso de 
LPS na empresa CelsiusTech (um dos principais fornecedores de sistemas de comando e controle de 
navios militares da Suécia), foi constatado que: 
 A participação dos softwares no custo total de seus produtos diminuiu de 65% para 20%; 
 Houve uma redução na quantidade de funcionários responsáveis pelo desenvolvimento dos 
softwares de 200 para cerca de 50; 
 Houve uma redução no tempo de entrega, que antes era na casa de anos, passou e ser meses. 
Além desses dados, o estudo também ilustra que em média de 70% a 80% dos sistemas são 
constituídos por componentes comuns que são utilizados em outros sistemas sem nenhuma 
modificação. 
 
 
 
 
15 
 
 
O Gráfico 01 exibe o grau de similaridade entre os sistemas navais da empresa. Pode-se ver 
na horizontal os elementos que integram a linha de produto (software nos navios) representados por 
letras e na vertical os valores referentes a quantidade de funções de sistemas presentes em cada 
produto. Na lateral direita tem-se a descrição dos tipos das funções e suas respectivas cores. A de 
maior destaque é a de cor preta (funções comuns) que compõe a maior parte de cada membro (navios) 
da linha de produto. 
 
Gráfico 01 - Reutilização em Linha de Produtos 
 
Fonte: Adaptado de Clements e Brownsword (1996). 
Outro estudo de caso que pode ser citado é da Hewlett-Packard - HP, uma das mais 
importantes empresas de tecnologia existentes. Sua área de abrangência é larga, indo de dispositivos 
portáteis até instalações de computadores de grande desempenho (HEWLETT-PACKARD, 2016). O 
uso de LPS trouxe como resultado, em comparação com o desenvolvimento dos produtos anteriores, 
uma redução de 25% dos recursos de pessoal e 67% do tempo de desenvolvimento, como também foi 
percebido que, o uso de LPS levou a uma redução de 96% de defeitos em seus produtos (TOFT, 
COLEMAN e OHTA, 2000). 
Mais um exemplo de uso de LPS bem sucedido encontra-se no caso da empresa Deutsche 
Bank. O Deutsche Bank é um banco que oferece soluções financeiras no campo de carteira comercial 
e de investimento, atuando também na estruturação de operações de fusões e aquisições e de mercado 
de capitais, entre outros, abrangendo mais de 70 países (DEUTSCHE, 2016). Tradicionalmente seu 
sistema sofre muitas mudanças para se adaptar as características de cada país. Anteriormente, a 
consequência era um inchaço do software e uma separação do sistema original, assim, uma mudança 
no núcleo (atingindo de forma global todos os outros sistemas) trazia um custo muito elevado para a 
16 
 
 
empresa por causa de incompatibilidades com os módulos desenvolvidos localmente (FAUST e 
VERHOEF, 2003). 
O Deutsche Bank conseguiu reduzir sua problemática de forma considerável através da 
implantação de uma LPS. Após a migração para uma LPS, um dos maiores benefícios trazido foi 
visto no ramo financeiro, com uma redução de custo de cerca de 4 (quatro) milhões de dólares anuais, 
valor correspondente que atinge de 3% a 7% do orçamento anual da empresa (FAUST e VERHOEF, 
2003). 
Dessa forma fica claro que, com LPS é possível produzir sistemas onde a sua maior parte pode 
ser integrada por outras já criadas anteriormente e as diferenças são incorporadas especificamente em 
cada sistema, ocasionando uma maior facilidade de mudanças e adaptação ao perfil peculiar de cada 
cliente. 
Portanto, percebe-se a utilidade de demonstrar o uso de LPS no desenvolvimento de sistemas, 
pois é possível fazer com que o mesmo software seja ajustado para adequar-se aos diferentes perfis 
de clientes. 
1.2 OBJETIVOS 
1.2.1 Objetivo Geral 
Demonstrar que através do uso da tecnologia de LPS é possível desenvolver um produto 
específico para o mercado, porém com a capacidade de diversificá-lo para diferentes seguimentos de 
clientes. 
1.2.2 Objetivos Específicos 
 Descrever as tecnologias necessárias para implementação de uma LPS; 
 Demonstrar que com LPS é possível desenvolver sistemas que se adéquam ao perfil específico 
de diversos clientes; 
 Desenvolver um sistema Web como caso de uso utilizando o paradigma de LPS. 
 
1.3 INDICAÇÃO DA METODOLOGIA 
De acordo com os objetivos desse trabalho, o mesmo pode ser classificado como uma pesquisa 
exploratória, pois busca proporcionar mais familiaridade sobre o tema abordado tornando-o mais 
explícito e claro através do uso de um levantamento bibliográfico e análise de exemplos que 
estimulem a compreensão (GIL, 2002). Para melhor entendimento e compreensão do que foi 
17 
 
 
desenvolvido aqui, a Figura 01 exibe os passos que foram realizados tratando de todos os 
procedimentos efetuados na forma de divisão através de fases, possibilitando uma separação de 
atividades para melhor entendimento de todo ciclo. 
Na fase 1 foi o momento para definição do tema. Isso foi conseguido a partir de conversas 
com o orientador, onde foi observado a importância do tema e também o fato de existir pouco 
conteúdo acadêmico em língua portuguesa sobre assuntos referentes a LPS,considerando seus 
conceitos e práticas. Foi decidido que a prática seria o desenvolvimento de um estudo de caso que 
pudesse ser empregado a teoria do tema abordado. A partir de então seria necessário a captação de 
materiais de conteúdo referente a tal área, dando início a fase 2. 
 
Figura 01 - Fases da Metodologia 
 
Fonte: Próprio autor (2016). 
Na fase 2 ouve a busca e coleta de material bibliográfico para ser usado como referência de 
composição, para nortear os caminhos a serem seguidos desta monografia. A consulta foi feita através 
da Web em portais de pesquisa como: 
 ACM Digital Library1 - uma plataforma de pesquisa que contém um conjunto 
interligado de autores, obras, instituições e idade especializada; 
 IEEE Xplore Digital Library2 - biblioteca digital que disponibiliza acesso aos 
conteúdos científicos e técnicos publicados pelo Institute of Electrical and Electronics 
Engineers (Instituto de Engenheiros Elétricos e Eletrônicos) - IEEE; 
 
1 http://dl.acm.org 
2 http://ieeexplore.ieee.org 
18 
 
 
 SpringerLink3 - a plataforma online da editora Springer que possui publicações dos 
principais autores do mundo, incluindo livros, periódicos, obras de referência entre 
outros; 
 Google Acadêmico4 - ferramenta do Google que disponibiliza uma forma fácil de 
pesquisa de conteúdo acadêmico com filtros para melhorar os resultados, sendo 
integrado inclusive, com uma conta Google; 
 Software Engineering Institute5 - um centro de pesquisas e desenvolvimento 
patrocinado pelo Departamento de Defesa dos Estados Unidos e operado pela 
Universidade Carnegie Mellon, oferecendo uma grande quantidade de material técnico 
e científico. 
O resultado, foi uma compilação de materiais para serem usados com intuito de conseguir um 
embasamento teórico necessário para desenvolvimento desse trabalho, trazendo opiniões de autores 
da área para reforçar o que está sendo escrito aqui. 
Na fase 3, ouve a análise crítica de toda a literatura encontrada na fase 2, onde foi realizado 
uma leitura para filtrar o que poderia fazer parte do conteúdo do trabalho. Esta é uma fase muito 
importante, pois foi necessário tomar decisões que implicariam na construção de toda monografia. 
Após, teve a união das partes mais relevantes, para compor a estrutura desse trabalho. 
Na fase 4 foi o momento de desenvolver o caso de uso, porém antes disso, foi preciso um 
planejamento de quais as tecnologias que seriam utilizadas. Assim, foi realizado alguns estudos e 
tentativas para escolher as ferramentas que necessárias que se encaixasse de melhor maneira no que 
estava sendo buscado. 
Dessa forma, nessa última fase, ocorreu o desenvolvimento do caso de uso propriamente dito. 
Este caso de uso é um gerador de sistemas com as características principais de um e-commerce. Tanto 
o gerador quanto os sistemas que o mesmo produz, foi aqui desenvolvido, sendo também 
demonstrado seu uso através de exemplos. Com este caso de uso foi possível aplicar os preceitos 
abordados nas fases anteriores para exemplificar o paradigma de LPS. 
 
 
3 https://www.springer.com/gp/products/springerlink 
4 https://scholar.google.com.br/ 
5 http://www.sei.cmu.edu/ 
19 
 
 
1.4 ORGANIZAÇÃO DO TRABALHO 
Após esse capítulo introdutório, o conteúdo deste trabalho organiza-se da seguinte forma: 
 Capítulo 2 - LINHA DE PRODUTOS DE SOFTWARE apresentará quais teorias e 
respectivos autores mais contribuíram para a realização do estudo e as bases teóricas para 
a realização deste trabalho; 
 Capítulo 3 - TECNOLOGIAS UTILIZADAS apresentará as ferramentas que foram 
utilizadas para desenvolvimento do estudo de caso presente neste trabalho; 
 Capítulo 4 - IMPLEMENTAÇÃO DA LPS apresentará o desenvolvimento da pesquisa 
juntamente com a solução proposta e sua aplicabilidade; 
 Capítulo 5 - Apresentará as considerações finais e demais conclusões sobre a pesquisa 
realizada. 
 
20 
 
 
2 LINHA DE PRODUTOS DE SOFTWARE 
A LPS utiliza conceitos e práticas próprias para a correta realização de suas atividades. 
Existem técnicas específicas com características adaptadas para todo ciclo de desenvolvimento de um 
software. Porém a LPS não trabalha sozinha, existe uma forte ligação com a Engenharia de Software, 
fazendo com que esses dois conceitos compartilhem benefícios e interajam visando um ponto em 
comum, que é o sucesso no desenvolvimento de sistemas. Nas próximas linhas serão apresentadas 
tanto a Engenharia de Software como a LPS. 
2.1 ENGENHARIA DE SOFTWARE 
Este capítulo contém os principais conceitos sobre Engenharia de Software. Serão abordos 
aqui, as características necessárias a criação de um software, como também, a forma de como a 
Engenharia de Software evoluiu até o seu estado atual. 
2.1.1 Entendendo o que é um software 
Na definição de software, muitas pessoas usam apenas o conceito clássico, afirmando que o 
mesmo é um programa com conjunto de instruções a realizar uma determinada tarefa, porém esse é 
um entendimento muito simplório. O programa é um dos componentes que constituem um software, 
junto com a documentação do sistema, que contém a estrutura do sistema, a documentação do usuário, 
onde é condensada a explicação de como deve ser utilizado o sistema e arquivos de configuração, 
usados para configurá-lo e em alguns casos sites Web com suas informações (SOMMERVILLE, 
2007). 
No âmbito da Engenharia de Software, o software é tratado como um produto, ficando de fora 
desse escopo pequenos programas criados por alguém para resolver um problema, mas não serão 
utilizados por outros (PAULA FILHO, 2009). 
Segundo Sommerville (2007), sendo o software considerado um produto, isso quer dizer que 
o mesmo pode ser vendido para um cliente e categorizado em dois tipos fundamentais de produtos de 
software: 
 Produtos genéricos - são sistemas com funcionalidades pouco específicas para o usuário 
individual. Por serem desenvolvidos com características genéricas, são produzidos por 
empresas de desenvolvimento que os colocam a venda no mercado para qualquer tipo de 
cliente que esteja disposto a adquiri-los. Exemplos desse tipo de produto são processadores 
de texto, planilhas e gerenciador de banco de dados; 
21 
 
 
 Produtos personalizados - são aqueles desenvolvidos sob encomenda, aonde uma empresa 
de software irá produzi-lo para um determinado cliente. Este produto possui características 
específicas de acordo com os desejos do cliente. 
A principal diferença entre esses tipos de software, encontra-se no fato de que os produtos 
genéricos têm suas especificações determinadas pela organização que o desenvolveu, enquanto nos 
produtos personalizados, as especificações são ditadas por quem encomendou o software. 
Outras características dos softwares são seus diversificados campos de atuações. Pressman 
(2011) traz algumas categorias de software que exigem desafios contínuos, onde engenheiros de 
software trabalham em novos projetos ou em outros projetos já existentes: 
 Software de sistema - uma característica marcante é a interação intensiva com o hardware do 
computador. Geralmente sua função é atender a outros programas. Exemplos podem ser, o 
sistema operacional, servindo de camada entre o hardware e as aplicações, drivers, necessários 
para um componente específico de hardware se integrar corretamente ao sistema operacional, 
softwares de rede, compiladores, entre outros; 
 Software de aplicação - processam dados comerciais ou técnicos com a intenção de facilitar 
a tomada de decisão. São programas que atendem a uma necessidade específica de negócio, 
auxiliando o usuário a realizardeterminada tarefa. Usa processamento de dados já existentes 
e armazenados, como também controlam funções em tempo real, por exemplo, transações de 
venda e controle dos processos de fabricação em tempo de produção. Navegadores de internet, 
leitor de arquivos, editor de imagens, são alguns exemplos dessa categoria; 
 Software científico - caracteriza-se por um grande processamento numérico. Essas aplicações 
envolvem cálculos de diversas áreas, que vão desde a biologia molecular até a astronomia; 
 Software embutido - está presente no interior de um produto ou sistema ajudando o usuário 
no controle do próprio sistema, realizando tarefas bem definidas, como controle de um painel 
de um forno de micro-ondas, funções digitais de um automóvel, tal como níveis de 
combustíveis; 
 Software para linha de produtos - busca atender as necessidades específicas de vários 
usuários com gostos e perfis distintos sem ter que criar um software do zero totalmente 
diferente para cada um; 
 Aplicações para Web - são softwares acessados através da rede em ambiente de sites Web 
com diversas funcionalidades, fornecendo recursos especializados para o usuário final, 
22 
 
 
normalmente integrados a banco de dados e aplicações comerciais; 
 Software de inteligência artificial - procura estudar e solucionar problemas através de 
algoritmos não numéricos. Exemplos são redes neurais artificiais, robótica, reconhecimento 
de padrão de imagens e voz, prova de teoremas e outros. 
2.1.2 Definição de Engenharia de Software 
Atualmente, é inegável a necessidade das pessoas, empresas e países por sistemas ou 
computadores dependentes de softwares. Essa forte presença acaba forçando que sua produção seja 
realizada visando a qualidade e custos satisfatórios. 
Entretanto, tais objetivos não são fáceis de serem alcançados. A busca pelo aperfeiçoamento 
no desenvolvimento de software teve maior importância com relação a seu crescimento, na época da 
chamada Crise do Software. Essa expressão surgiu em uma conferência no final dos anos de 1960, a 
qual representa as dificuldades existentes no desenvolvimento de software naquela época. 
Foi nessa mesma conferência que houve o surgimento da ideia de reuso de software através 
de um artigo escrito por Doug McIlroy, assim como a ideia de dividir o sistema em componentes 
podendo ser reutilizados posteriormente (FUKS e PIMENTEL, 2012). Nesse artigo McIlroy (1968) 
afirma, entre outras coisas, que naquela época existiam condições suficientes de criar esses 
componentes, porém, ainda não existia uma coerência na forma de produção e uso dos mesmos, 
alertando os projetistas de software para a importância de se pensar também em reutilizar e não só 
construir. 
Segundo Sommerville (2007), essa conferência colocou em destaque a discussão do termo 
“crise de software”, suas causa e efeitos, mas também surgiram conceitos importantes entre eles a 
ideia inicial de Engenharia de Software. 
Dessa forma, o conceito de Engenharia de Software nasceu, assim, em meio à confusa forma 
adotada de desenvolvimento até aquele período. Foi nessa conferência que se admitiu a existência da 
necessidade de mudanças e que realmente encontravam-se problemas na criação de software. Com 
isso, foi reconhecido que os projetos de sistemas devem ser considerados como trabalhosos e difíceis, 
e como tal, merecem uma atenção diferente da abordada até então, demonstrando assim, uma 
crescente preocupação com a confiabilidade do software naquele momento (DIJKSTRA, 1972). 
Sommerville (2007) define Engenharia de Software como uma disciplina da engenharia que 
tem como responsabilidade se relacionar com todos os pontos de construção de um software, do início 
ao final, passando pela etapa de especificação até a sua manutenção. A Engenharia de Software abraça 
23 
 
 
as fases trazendo maior organização para o desenvolvimento de sistemas, contribuindo de maneira 
enfática para o melhoramento da forma de produção. 
Sendo assim, a Engenharia de Software não abrange somente a elaboração de programas em 
si, mas sua atuação encontra-se também na questão de documentação dos respectivos estágios de 
desenvolvimento (VASCONCELOS et al, 2006). Relaciona-se também com processos não técnicos, 
como a atividade de gerenciamento e desenvolvimento de ferramentas, métodos e teorias que 
auxiliam a criação de software (SOMMERVILLE, 2007). 
Portanto, a Engenharia de Software possui como um de seus principais papeis estabelecer 
métodos e ferramentas de forma organizada para o desenvolvimento de software, visando concebê-
los a custos adequados e alta qualidade. 
2.1.3 Qualidade de Software 
No desenvolvimento de software, é comum se ouvir muito em qualidade e o quanto ela é 
importante para o produto final. Dessa maneira, entender sua definição e o que é um software com 
qualidade, é primordial para o estudo da Engenharia de Software. 
Para Paula Filho (2009), a qualidade de um projeto de software depende do quanto às funções 
e características do modelo de requisitos foram atendidas. Assim, o produto resultante atenderá as 
necessidades identificadas no projeto, através do grau de conformidade entre o que foi planejado e o 
que foi realizado. 
A qualidade com relação a conformidade não é o único fator a ser observado. A essa ideia 
Pressman (2011) acrescenta que a satisfação do usuário deve ser lavada em consideração, dando 
devida atenção ao fato de perceber se o produto de software fornece ou não benefícios ao usuário, 
pois, em caso positivo, é possível que o usuário venha a tolerar eventuais problemas de confiabilidade. 
Quando a conformidade com os requisitos não está satisfatória, os problemas decorrentes 
trazem um desempenho abaixo do esperado. Paula Filho (2009) exemplifica dizendo que esses 
problemas aparecem de diversas maneiras e em alguns casos podem surgir como funções que não são 
executadas corretamente dependendo das condições impostas ou certos valores de entrada. 
Para alcançar a qualidade de software é necessária uma prática bem realizada dos métodos e 
preceitos da Engenharia de Software usando-a para nortear a procura pela qualidade. Em Pressman 
(2011) encontram-se quatro grandes atividades que ajudam na obtenção do aumento do padrão da 
qualidade de software: 
 Métodos de Engenharia de Software - é necessário entender o problema a ser resolvido para 
ser capaz de desenvolver um projeto adequado ao problema. A Engenharia de Software 
24 
 
 
apresenta métodos apropriados para se ter um entendimento mais completo do problema que 
quando aplicados aumentam a probabilidade de sucesso na qualidade; 
 Gerenciamento de software - o gerenciamento feito de forma incorreta pode acarretar 
grandes danos a qualidade de software. Para diminuir os riscos de uma má gerência e fazer 
com que a qualidade do software seja afetada de forma positiva por ela, é necessário traçar 
estimativas satisfatórias para as datas de entrega, obedecer ao cronograma, bem como realizar 
um planejamento de riscos para os possíveis problemas que venham a ocorrer; 
 Controle de qualidade - esse controle é prescrito pela Engenharia de Software através de um 
conjunto de ações que ajudam a atingir as metas de qualidade. Aqui é empregado vários testes 
com a intenção de descobrir possíveis erros e naturalmente corrigi-los; 
 Garantia da qualidade - a garantia de qualidade é um conjunto de funções de auditoria e de 
relatório para uma avaliação das ações de controle de qualidade, tendo como objetivo 
assegurar a qualidade fornecendo dados ao pessoal técnico e administrativo sobre a qualidade 
do produto. Caso esses dados identifiquem problemas, é de responsabilidade da gerência tratá-
los buscando sua resolução. 
2.1.4 Processos deSoftware 
Um processo de software é um conjunto de atividades que auxiliam na produção de um 
software propriamente dito, através de linguagens de programação ou na criação de um novo produto 
ampliando ou modificando um já existente, como também na integração de softwares ou componentes 
de sistemas (SOMMERVILLE, 2007). 
Paula Filho (2009) complementa dizendo que os processos podem ser utilizados nas operações 
de desenvolvimento, manutenção, aquisição e contratação de software, assim como, para cada 
operação dessas, pode-se definir subprocessos. Um exemplo pode ser no desenvolvimento com seus 
subprocessos de aquisição de requisitos, análise, implementação e testes. 
Contudo, o processo de software não garante um desenvolvimento sem falhas. Pressman 
(2011) alerta para o fato de que, mesmo com a existência de um processo, pode-se ocorrer a entrega 
fora do prazo, assim como, a adoção do processo de software não garante que as necessidades do 
cliente serão realmente atendidas de forma correta ou que será alcançada as características de 
qualidade satisfatórias. 
Para diminuir o grau de dificuldade e facilitar o entendimento dos processos de software 
existem modelos de ciclo de vida de um projeto. Em um processo de desenvolvimento de software a 
escolha de um modelo de ciclo de vida é o ponto inicial para a arquitetura de um processo (PAULA 
25 
 
 
FILHO, 2009). Tais modelos possuem descrições do processo de desenvolvimento, com atividades 
de produção, manutenção e a ordem de como devem ser executadas (VASCONCELOS et al, 2006). 
De acordo com Sommerville (2007) um modelo de processo de software é a forma de 
representar um processo de software, onde cada modelo reflete um processo a partir de uma 
determinada visão, possuindo cada um, suas próprias características. Entretanto, mesmo existindo 
muitos modelos de processo de software diferentes, algumas atividades são comuns entre eles, como: 
levantamento de requisitos, projeto, implementação e testes. 
A engenharia de requisitos é o processo de aquisição, refinamento e verificação dos serviços 
e restrições do software de acordo com as necessidades do cliente (IEEE, 1984). Logo, os requisitos 
são as características que o cliente planeja que o software possua depois de pronto. 
Para Sommerville (2007) os requisitos são frequentemente classificados em requisitos 
funcionais, requisitos não funcionais e requisitos de domínio: 
 Requisitos Funcionais - declarações de serviços que o sistema deve prover, como deve reagir 
diante de certas ações dos usuários e em alguns casos, estabelecem de forma explícita o que 
o sistema não deve fazer; 
 Requisitos Não Funcionais - são aqueles que não estão diretamente relacionados com as 
funções fornecidas pelo sistema, podendo estar relacionados com as propriedades do sistema, 
como a confiabilidade, tempo de resposta e espaço de armazenamento; 
 Requisitos Domínio - requisitos advindos do domínio (características específicas do negócio 
tratado no sistema) do sistema em vez das necessidades dos usuários do sistema. Na maioria 
das vezes possuem certas terminologias específicas desse domínio. 
A atividade de projeto de software é um conjunto de princípios, conceitos e práticas com o 
intuito de levar o desenvolvimento de um sistema ou produto a obter alta qualidade (PRESSMAN, 
2011). Essa atividade caracteriza-se por trabalhar para permitir que os requisitos adquiridos 
anteriormente sejam transformados em uma representação do software a ser desenvolvido. 
Essa tradução é feita de forma iterativa fazendo com que sejam adicionados mais detalhes a 
cada iteração, aproximando-se cada vez mais dos algoritmos e das estruturas de dados a serem 
implementados (VASCONCELOS et al, 2006). Desse modo, com a fase de aquisição e análise de 
requisitos, possibilita o que o sistema deve fazer, já a fase de projeto, determina como as 
funcionalidades do sistema devem ser implementadas. 
Na fase de projeto é comum utilizar estruturas para descrever a arquitetura do sistema através 
de diagramas. Na maioria das vezes, para representar esses diagramas usa-se a notação Unified 
26 
 
 
Modeling Language - UML (BOOCH, 1998). A UML é uma notação de modelagem que pode ser 
usada independentemente do tipo de processo de desenvolvimento e possui uma série de modelos 
para representar as principais atividades que terão de ser realizadas no sistema, com detalhes o 
suficiente para permitir um planejamento eficiente da fase de construção (PAULA FILHO, 2009). 
Vasconcelos et al (2006) complementam ao mostrarem que na UML os requisitos funcionais 
são representados com diagramas de casos de uso através de uma sintaxe precisa e bem definida. 
Porém os requisitos não funcionais ainda continuam com sua especificação sendo feitas com a 
linguagem natural, trazendo assim, poucos detalhes. 
Os diagramas adquiridos na etapa de projeto agora servirão como base na etapa de 
implementação. Aqui, o software é criado como um conjunto de unidades utilizando uma linguagem 
de programação como também usando ferramentas de apoio, que servem como plataforma de 
desenvolvimento. 
Para Vasconcelos et al (2006) o julgamento da qualidade de um código produzido pode ser 
baseado em alguns fatores como a qualidade da documentação, o uso de um padrão de codificação, a 
legibilidade, o nível de complexidade, o tamanho, como também o tempo de execução. Existem 
outros atributos que podem ser levados em consideração para descobrir a qualidade do código como 
a revisão e até mesmos testes. 
Na atividade de testes, há uma execução de uma implementação do software com dados de 
testes, verificando a saída realizada pelo sistema e seu comportamento, examinando se o desempenho 
está de acordo com o esperado (SOMMERVILLE, 2007). O teste é um conjunto de tarefas planejadas 
e executadas sistematicamente, com isso, deverá existir para o processo de software um modelo de 
testes a ser seguido, que contenha técnicas e casos de teste (PRESSMAN, 2011). 
A importância da realização de testes encontra-se na possibilidade de falhas no processo de 
desenvolvimento de software. Portanto, para garantir uma maior chance de conseguir um maior nível 
de qualidade do sistema, os custos por causa das falhas justificam um planejamento criterioso na 
atividade de testes (VASCONCELOS et al, 2006). 
Segundo Sommerville (2007) existem dois tipos de testes para serem explorados em 
determinado estágio do processo de software, cada um com um fim, verificando o desempenho do 
sistema: 
 Teste de validação - é destinado a validar as características do sistema observando os 
requisitos do cliente, buscando descobrir se o desejo do cliente foi atingido; 
 Teste de defeitos - tem a finalidade de verificar se certo segmento de código fonte foi 
27 
 
 
realmente implementado de forma correta, procurando identificar inconsistências entre o 
código e sua especificação. 
2.1.5 Reuso de software 
No contexto da Engenharia de Software a reusabilidade está relacionada geralmente aos 
componentes de vários tamanhos. De acordo com Sommerville (2007) as unidades de software 
reusadas podem ser menores como objetos e funções, maiores como componentes/subsistemas de 
uma aplicação ou até mesmo um sistema completo, como acontece no caso de uma absorção e 
integração por outros sistemas. 
Para entender melhor o que é realmente é uma reutilização, Dusink e Katwijk (1995) a 
definem como sendo o uso de um artefato de software existente no momento da construção de um 
novo sistema ou em uma incorporação de um artefato de software em um sistema novo. Sobre o que 
é um artefato, os mesmos autores afirmam que é uma parte de conhecimento com características que 
possam realizar uma contribuição noprocesso de Engenharia de Software. 
Para Hirama (2011) o reuso pode trazer como benefícios um software desenvolvido mais 
rapidamente, aumento na qualidade e custos reduzidos, entre outros, possibilitando que as 
organizações obtenham um retorno maior sobre os investimentos relacionados aos softwares. 
Para poder implementar o reuso em um projeto, é necessário um planejamento observando 
fatores importantes que influenciam nos resultados da reusabilidade. Alguns desses fatores são 
elencados por Sommerville (2007) e exibidos a seguir: 
 Cronograma - o tempo de desenvolvimento de um software pode ser reduzido reusando 
sistemas prontos e não só pequenos componentes, mesmo a adaptação podendo ser imperfeita, 
existe uma minimização no trabalho de desenvolvimento; 
 Ciclo de vida - caso o sistema tenha um ciclo de vida longo, a manutenção do sistema e as 
implicações do reuso devem ser analisadas olhando o longo prazo e não só nas possibilidades 
imediatas do reuso; 
 Conhecimentos - para utilizar as práticas de reuso em um projeto de desenvolvimento de 
software é necessário que a equipe esteja preparada, possuindo habilidades e experiência que 
conduzam à uma implementação eficaz da reutilização; 
 Requisitos não funcionais - para softwares que possuam requisitos de desempenho exigentes, 
reutilizar componentes vindos de geradores de código, pode não ser aconselhável, pois esses 
geradores tendem a criar códigos muitas vezes pouco eficientes; 
 Domínio da aplicação - em alguns domínios como industriais e médicos, existem produtos 
28 
 
 
genéricos e configuráveis que podem ser reusados em situações específicas; 
 
2.2 LINHA DE PRODUTOS DE SOFTWARE 
Esta seção contém os principais conceitos sobre LPS. Aqui serão apresentados conceitos e 
principais características desse paradigma de desenvolvimento. 
2.2.1 Definição de Linha de Produtos de Software 
Uma LPS é uma união de vários sistemas que compartilham um conjunto comum de recursos 
gerenciando-os para satisfazer as necessidades específicas de um determinado segmento de mercado 
(NORTHROP e CLEMENTS, 2012). 
Esta definição exibe que a LPS pode trazer benefícios no desenvolvimento de sistemas, uma 
vez que uma linha de produtos é derivada a partir de características comuns, algo que não acontece 
quando o software é desenvolvido separadamente sendo sempre iniciado a partir do zero. 
Essa economia vê-se na construção de um novo produto (sistema) onde, durante sua 
construção, existe uma conexão e integração de componentes já desenvolvidos anteriormente, se 
parecendo mais com uma montagem de características necessárias ao sistema que está sendo 
desenvolvido em vez de apenas criá-lo programando código por código (NORTHROP e 
CLEMENTS, 2012). Dessa maneira, cada produto é formado por uma base comum de 
características/funcionalidades e a ela é aplicada componentes que possam ser necessários para 
montar a coleção dos produtos da linha. 
Porém, é necessário distinguir também o que não é uma LPS. Northrop (2008) traz uma lista 
com abordagens que não podem ser confundidas com LPS. Abaixo encontram-se algumas delas: 
 Desenvolvimento de um único sistema com reuso - quando se usa partes de um sistema 
anteriormente desenvolvido em um novo sistema. Isso produz um novo sistema através do 
reuso, não dois sistemas construídos a partir do compartilhamento de uma mesma base comum 
de características. 
 Reutilização de pequenas partes - bibliotecas que podem ser reutilizadas contendo 
algoritmos, módulos ou objetos; 
 Várias versões de um único sistema - uma empresa pode criar um sistema e depois modificá-
lo lançando-o com uma versão diferente. Porém, uma LPS trabalha com vários produtos 
simultaneamente e todos estão passando por seus próprios ciclos e controle de versão; 
29 
 
 
2.2.2 Vantagens da Linha de Produtos de Software 
As vantagens de uma LPS encontram-se no fato de se conseguir fornecer produtos 
personalizados a custos menores. Porém os benefícios vão além destes e a baixo vê-se alguns dos 
principais de acordo com Pohl, Böckle e Linden (2005) para o desenvolvimento de software sob o 
paradigma da linha de produtos: 
 Menor custo de desenvolvimento - artefatos reutilizados em vários sistemas implicam em 
redução de custos de desenvolvimento por cada sistema; 
 Melhoria na qualidade - os componentes reutilizados são testados em cada produto, 
implicando numa significativa chance de encontrar e corrigir possíveis erros, trazendo assim, 
como consequência, um aumento na qualidade de cada sistema; 
 Menor tempo de desenvolvimento - o tempo de desenvolvimento de um único software (sem 
uso do paradigma de LPS) é considerado constante, pois compreende o período para criação 
desse software. Para uma LPS, o tempo inicial é elevado, uma vez que os artefatos comuns a 
todos os produtos devem ser criados. Contudo, após esse início, o tempo de desenvolvimento 
é consideravelmente diminuído, visto que muitos artefatos anteriormente gerados podem ser 
reutilizados nos novos sistemas; 
 Menor esforço de manutenção - quando um produto precisa ser alterado, por exemplo, para 
corrigir erros, as correções podem ser disseminadas para todos os outros produtos da linha, 
reduzindo o esforço na manutenção. A reutilização de procedimentos de testes está dentro do 
foco da ideia de LPS, isto também traz uma ajuda para menor redução no esforço de 
manutenção; 
 Lidar com a evolução - a necessidade de introduzir uma nova funcionalidade no produto 
pode ser satisfeita adicionando artefatos específicos. Dessa forma, fica mais fácil organizar a 
evolução de todos os produtos da linha, pois se fossem sistemas distintos, a evolução teria de 
ser construída em cada um dos sistemas. Entretanto, numa LPS só precisa fazer uma única 
vez; 
 Melhorar a aferição dos custos - como as partes comuns dos produtos são as mesmas, é 
necessário realizar cálculo dos custos para elas apenas uma vez, faltando mensurar somente 
as partes específicas de cada produto; 
 Vantagens para os clientes - os clientes obtêm produtos que se encaixam às suas 
necessidades específicas de seu perfil, como também adquiri-los por um valor mais baixo e 
qualidade maior, pois como já dito antes, LPS reduz os custos de desenvolvimento como o 
30 
 
 
aumento da qualidade. Além disso, os requisitos são avaliados e atendidos de forma mais 
consistente chegando o mais próximo possível da realidade idealizada pelo desejo do cliente. 
Os clientes também têm como benefícios, interfaces e funcionalidades semelhantes que torna 
mais fácil para o cliente migrar de um produto para outro sem a necessidade de aprender novas 
maneiras de usar outro produto. 
A reutilização usada de forma estratégica é a base dos benefícios da LPS, trazendo às 
organizações vantagens competitivas significativas, uma vez que realizada a obtenção das partes 
comuns (núcleo) da linha de produtos, como consequência natural, ocorrerá uma economia em torno 
de cada novo produto construído. Assim, quanto mais complexo for o software, maior será o proveito 
sobre o retorno trazido pela LPS, pois toda carga de problemas já terá sido resolvida anteriormente. 
Northrop e Clements (2012) mostram que os benefícios podem ser observados de forma mais 
específica, associados a vários níveis do desenvolvimento do software: 
 Requisitos - os requisitos dos novos produtos da linha serão mais simples de descrever, uma 
vez que as exigências já foram especificadas anteriormente; 
 Arquitetura - para uma linha de produtos, arquitetura é o modelo a ser seguido na montagem 
dos novos produtos, a partir dos componentes da base comum que compõem o núcleo. A 
arquitetura é algo trabalhoso e de significativo investimento,porém para os produtos 
seguintes, a parte mais importante do projeto já foi realizada; 
 Componentes - Até 100% dos componentes que formam a base comum da linha são 
reaproveitados para cada produto. Caso necessitem serem alterados, essas modificações serão 
pequenas, pois toda sua estrutura já está bem formada e pronta para ser usada; 
 Testes - o plano de testes genérico, casos de testes, dados de testes, forma de reportar e corrigir 
problemas e todo o ambiente relacionado a testes, já foram construídos, devendo apenas 
adaptá-los para as variações específicas de cada produto; 
 Planejamento - o orçamento e o cronograma já existem através de outros produtos 
desenvolvidos anteriormente, assim fornecem uma base confiante para os próximos produtos; 
 Processos - o controle de configuração, processo de gestão e todo o processo global de 
desenvolvimento encontram-se bem alinhado, pois foram utilizados antes e estão bem 
robustos e confiáveis; 
 Pessoas - a quantidade de pessoas necessária para desenvolver um novo produto é menor. 
31 
 
 
2.2.3 Engenharia de Linha de Produtos de Software 
Segundo Pohl, Böckle e Linden (2005) a Engenharia de Linha de Produtos de Software - ELPS 
é um processo de desenvolvimento de software que usa uma arquitetura comum e fornece 
componentes reutilizáveis que podem ser utilizados para customização em massa. Assim, a ELPS dá 
apoio através de um framework para geração de sistemas customizados. 
Para Northrop e Clements (2012) existem três atividades essenciais para uma ELPS, que são 
a Engenharia do Domínio, Engenharia da Aplicação e Gerenciamento, como é visto na Figura 02. 
 
Figura 02 - As três atividades essenciais da ELPS 
Fonte: Adaptado de Northrop e Clements (2012). 
Na Figura 2 cada círculo representa uma das atividades, onde são ligadas uma as outras. As 
setas indicam um movimento contínuo, mostrando que elas possuem um alto grau de interatividade 
entre si, podendo essa interatividade ocorrer em qualquer momento. Tanto a Engenharia de Domínio, 
quanto a Engenharia da Aplicação e o Gerenciamento serão tratados com mais detalhes nas próximas 
seções. 
2.2.3.1 Engenharia do Domínio 
Na engenharia de domínio ocorre a definição e separação das características comuns e as 
variabilidades da linha de produtos (POHL, BÖCKLE e LINDEN, 2005). A Engenharia de Domínio 
verifica se a variabilidade realmente existe e, se é adequada para implementar uma LPS. 
É na engenharia de domínio onde ocorre a atividade de criação dos core assets (VOELTER e 
VISSER, 2011). Para entender melhor essa terminologia, Northrop e Clements (2012) dizem que os 
core assets são recursos que formam a base para uma LPS, os quais também são conhecidos como 
ativos, podendo abranger os artefatos de requisitos, documentação, orçamentos, plano de testes, 
32 
 
 
componentes de software reutilizáveis, entre outros. 
Para Pohl, Böckle e Linden (2005), os objetivos principais do processo de engenharia de 
domínio podem ser resumidos em três: identificar o que é comum e as variabilidades da LPS; definir 
o escopo da LPS; identificar e construir artefatos que sejam reutilizáveis para se conseguir a 
variabilidade planejada. 
A Figura 03 exibe os subprocessos da engenharia de domínio. Cada um será explicado 
separadamente a seguir. Apesar de a Figura 03 ser composta pela Engenharia de Domínio na primeira 
metade da imagem e pela Engenharia de Aplicação na outra parte, aqui será exposto a Engenharia de 
Domínio e em outro tópico a Engenharia de Aplicação. 
 
Figura 03 - Processo de Engenharia de Domínio 
Fonte: Adaptado de Pohl, Böckle e Linden (2005). 
 Gerenciamento de Produto - aqui a preocupação é com a gestão dos produtos, aplicando 
técnicas para definir o escopo, identificando o que está dentro e o que está fora do âmbito da 
linha de produtos. O Gerenciamento de Produto tem como saída uma espécie de mapa dos 
produtos que contém as principais características comuns e variáveis dos futuros novos 
33 
 
 
produtos; 
 Engenharia de Requisitos de Domínio - abrange todas as atividades de identificar e 
documentar os requisitos tanto do núcleo comum quanto das variabilidades da LPS. Recebe 
como entrada o resultado do Gerenciamento de Produto e sua saída é o modelo com os 
requisitos da linha de produtos. Assim, a Engenharia de Requisitos de Domínio está 
relacionada à linha de produtos que está sendo desenvolvida e não aos requisitos de uma 
aplicação em particular. Portanto, seu foco encontra-se nas exigências comuns e variáveis de 
toda LPS em questão; 
 Projeto de Domínio - nesse subprocesso ocorre a definição da arquitetura de referência da 
linha de produtos, que fornece uma estrutura comum para todos os aplicativos da linha de 
produtos; 
 Realização de Domínio - a Realização do Domínio consiste em detalhar e implementar os 
componentes de software reutilizáveis da linha de produtos. Tais componentes são 
configuráveis e acopláveis e serão usados posteriormente como parte da construção dos 
produtos da linha, logo, não devem ser confundidos com aplicativos que podem entrar em 
execução individualmente; 
 Testes de Domínio - tem a responsabilidade de fazer a validação e verificação dos 
componentes reutilizáveis, realizando testes, onde os componentes são comparados com sua 
especificação. Este subprocesso também gera artefatos de teste que posteriormente serão 
utilizados para testar o sistema, reduzindo o esforço de produção desses testes. 
2.2.3.2 Engenharia de Aplicação 
Segundo Pohl, Böckle e Linden (2005) alguns dos principais objetivos da Engenharia de 
Aplicação é documentar os requisitos, arquitetura, componentes e testes relacionando-os aos artefatos 
de domínio do sistema; vincular todas as características variáveis de acordo com as necessidades do 
sistema; calcular as diferenças entre das características da aplicação e de domínio da arquitetura, com 
relação a requisitos, componentes e testes. 
A Engenharia de Aplicação, assim como a Engenharia de Domínio, pode ser dividida em 
subprocessos. Cada um deles utiliza artefatos gerados pela Engenharia de Domínio e produz artefatos 
para a aplicação. 
A Figura 04 está destacando a parte referente à Engenharia de Aplicação e seus subprocessos. 
Cada um será explicado separadamente a seguir. 
 
34 
 
 
Figura 04 - Processo de Engenharia de Aplicação 
Fonte: Adaptado de Pohl, Böckle e Linden (2005). 
 Engenharia de Requisitos de Aplicação - abrange todas as atividades relacionadas com as 
especificações de requisitos de aplicação. Aqui se busca encontrar as diferenças entre os 
requisitos da aplicação com aqueles produzidos na Engenharia de Requisitos de Domínio; 
 Projeto de Aplicação - produz a arquitetura que será usada para produção da aplicação. Essa 
arquitetura define a estrutura da aplicação a ser desenvolvida, pertencente a linha de produtos; 
 Realização da Aplicação - nesse subprocesso é criada a aplicação com base na seleção e 
configuração dos componentes reutilizáveis e também na criação de novos componentes 
específicos da aplicação. Dessa forma a aplicação é formada por ativos reutilizáveis e 
específicos da aplicação considerada; 
 Testes de Aplicação - aborda as operações relacionadas a validação e verificação da 
especificação com o que foi desenvolvido em busca de possíveis incompatibilidades, 
realizando diversos testes. 
35 
 
 
2.2.3.3 Gerenciamento 
Considerando que o grau de dependência de componentes em uma LPS é bem elevado, o 
Gerenciamento deve ser realizado de forma eficiente no controle de todo processo (SILVA JUNIOR, 
2011). Para Northrop (2008) o Gerenciamento desempenha um papel crucial para o sucesso ou não 
da práticada LPS. 
O Gerenciamento é composto por uma gestão de nível técnico e de nível organizacional. Esses 
dois enfoques devem estão fortemente ligados com o esforço de criação, desenvolvimento e 
manutenção da LPS. 
Northrop e Clements (2012) demonstram as características tanto da gestão técnica quanto da 
gestão organizacional. A gestão organizacional define um modelo para garantir a evolução dos 
principais ativos da linha de produtos. Também coordena as atividades técnicas essenciais no 
desenvolvimento dos ativos de núcleo (aqueles que formam as partes comuns dos produtos da linha), 
assim como o desenvolvimento de cada produto. A administração deve garantir que tais operações e 
os caminhos usados para conseguir sucesso no esforço de implementação da LPS sejam devidamente 
documentados. 
A gestão organizacional deve assumir a responsabilidade de gerar uma estrutura organizada 
que certifique que as unidades participantes recebam os recursos necessários e adequados em 
quantidades suficientes, como por exemplo, pessoal treinado. 
A tarefa da gestão técnica no desenvolvimento de ativos de núcleo e no desenvolvimento de 
produtos é garantir que quem esteja construindo esses recursos estejam trabalhando nas atividades 
realmente necessárias, seguindo os processos já definidos na linha de produtos. Também tem como 
função observar e recolher dados que sejam suficientes para examinar o progresso, realizando um 
acompanhamento constante do processo como um todo. 
A gestão técnica e a gestão organizacional trabalham de forma conjunta para contribuir na 
criação dos ativos do núcleo com intuito de deixar cada vez mais reutilizáveis os artefatos ligados ao 
gerenciamento, de forma mais específica, cronogramas e orçamentos, para serem utilizados no 
desenvolvimento de cada produto da linha. 
As duas atividades (Engenharia de Domínio e Engenharia de Aplicação) juntamente com a 
atividade de Gerenciamento, são individualmente importantes, porém sua união, uma mistura de 
tecnologia com práticas de negócio, é essencial. Entretanto, o caminho a ser tomado de como realizar 
essa mistura depende da organização que está implantando a LPS. Assim, diferentes empresas podem 
realizar caminhos diferentes através das três atividades. 
36 
 
 
Algumas organizações começam a implantação da LPS, usando como início a análise e 
desenvolvimento dos ativos comuns. Em compensação, outras preferem começar a partir de apenas 
um produto ou um pequeno conjunto de produtos que ela já possui, e então começar com a produção 
dos recursos do núcleo da LPS e os próximos produtos futuros. Northrop e Clements (2012) afirmam 
que no primeiro caso, as empresas usaram a abordagem proativa e no segundo caso a abordagem 
reativa. 
Para Northrop (2008) na abordagem reativa há o cálculo de todo o escopo da linha para ser 
usado como padrão a ser seguido como base para todos os produtos. Assim, novos produtos tem a 
chance de serem colocados no mercado mais rapidamente, pois toda sua base já foi desenvolvida 
anteriormente. Porém, essa abordagem necessita de um investimento inicial maior e de conhecimento 
prévio considerável. 
A abordagem reativa começa com um ou mais produtos que a própria organização já possuía. 
Baseado neles, são gerados os ativos que possuem características comuns, formando o núcleo da linha 
de produtos e a partir daí os produtos futuros. Nessa abordagem a evolução do escopo acontece de 
forma mais lenta, em contra partida, o custo inicial é menor com relação à abordagem proativa. 
Apesar de serem abordagens diferentes, elas podem ser usadas de maneira incremental, assim 
a empresa pode iniciar com uma delas e depois usar os conceitos e práticas da outra para sua 
implantação de LPS. Northrop e Clements (2012) demonstram esse fato a partir de um exemplo: uma 
abordagem proativa pode ser usada para iniciar a criação de apenas alguns ativos fundamentais que 
constituem o núcleo, no lugar de construir todos de uma vez. Dessa forma, os primeiros produtos 
usariam apenas esses poucos ativos desenvolvidos e os produtos subsequentes, só iriam usar mais 
ativos, quando os mesmos fossem desenvolvidos aos poucos e sendo adicionados à coleção. 
2.2.4 Variabilidade em Linha de Produtos de Software 
Variabilidade está ligada com a ideia de poder modificar ou personalizar um sistema, 
implicando em conseguir facilidade para se chegar a alguns tipos de mudanças (QUEIROZ, 2009). 
No início do planejamento de desenvolvimento de um software, pelo fato de ainda as restrições serem 
poucas, acaba existindo diversos possíveis sistemas a serem construídos, porém, durante o 
desenvolvimento esse número vai caindo, até chegar ao sistema propriamente dito na fase de 
execução (SILVA et al, 2011). Assim, a variabilidade vai sendo limitada de acordo com o avanço 
natural do projeto. 
Com relação a LPS, as variabilidades possuem uma importância central, pois são elas que 
fazem com que o paradigma de LPS realize papel de destaque com relação de possibilidade e 
37 
 
 
facilidade em obter resultados satisfatórios nas diferenciações de cada um de seus produtos 
(FERREIRA, 2012). A variabilidade em uma LPS pode ser facilmente observada durante todos os 
seus ciclos de implementação. 
Segundo Pohl, Böckle e Linden (2005) as variabilidades podem ser encontradas fortemente 
estabelecidas na Engenharia de Domínio, pois é nesse momento onde ocorre a separação das partes 
comuns para compor os ativos de núcleo e as variabilidades de cada produto. Na Figura 05 vemos em 
foco que dentro da Engenharia de Domínio deve-se reservar uma atenção para o conteúdo variável 
tanto dos requisitos, como arquitetura, componentes e testes. 
 
Figura 05 - Destaque da variabilidade na Engenharia de Domínio 
Fonte: Adaptado de Pohl, Böckle e Linden (2005). 
Para Ferreira (2012) a variabilidade está diretamente relacionada com outro conceito no 
universo de linha de produto de software que são os elementos comuns que compõem a base de ativos. 
Considerando que esses elementos comuns formam uma estrutura de características que estão 
presentes em todos os produtos da linha, as diferenciações desses produtos, um em relação ao outro, 
faz com que essas variabilidades encontradas sejam entendidas como as particularidades específicas 
38 
 
 
de cada sistema (produtos da linha) que espelham as expectativas desejadas do cliente. 
As variabilidades existentes na abordagem de LPS são representadas por pontos de variação 
e variantes que são resolvidos antes da criação dos produtos (SILVA et al, 2011): 
 Ponto de Variação - é o local de certo artefato da linha de produtos onde seu conteúdo ainda 
não foi determinado e está esperando por uma variação. O ponto de variação determina pontos 
em que é possível inserir as variantes; 
 Variante - corresponde a uma alternativa dentro de uma gama de variações projetadas, que 
podem ser usadas para representar as variabilidades de um produto. 
Assim, uma variante é formada por características peculiares de um produto e o ponto de 
variação é o local onde está variante vai ser inserida, determinando as características da variabilidade. 
Porém, Ferreira (2012) chama a atenção para o fato de poder ocorrer riscos na gerência das 
variabilidades no tocante a evolução dos produtos durante o decorrer do tempo, trazendo 
consequentemente, mudanças em suas variabilidades, mas que isso pode ser contornado ao realizar 
essa evolução seguindo as escolhas das variantes do produto. 
Para melhor separação e compreensão das partes comuns e também das variabilidades de um 
sistema, é utilizado o modelo de features (SILVA JUNIOR, 2011). Com o modelo de features é 
possível ter uma melhor organização e visualização dos componentes que formam os produtosde 
uma LPS. 
2.2.4.1 Modelo de Features 
O conceito de features (características) foi apresentado em 1990 pelo método Feature 
Oriented Domain Analysis - FODA para representar características variáveis e também as 
características comuns de um grupo de sistemas (SCHOBBENS et al, 2006). Seguindo esse modelo, 
uma feature é uma característica presente no sistema sendo visível ao nível do usuário final (SILVA 
JUNIOR, 2011). Assim, uma feature é uma característica de um produto que no olhar dos usuários e 
clientes representa uma importância relevante na distinção de um determinado produto da linha 
(GRISS, 2000). 
Segundo Ferré e Vegas (1999) além do FODA existem outros métodos semelhantes como por 
exemplo o IDeA, STARS e DADO, onde podem ser utilizados na arquitetura e design de exibição de 
features dentro em uma LPS. Neste trabalho será usado o FODA por possuir uma maior quantidade 
de conteúdo, enquanto os outros, possuem material muito limitado. 
O modelo de features é estruturado em diagramas visivelmente semelhantes a uma árvore, 
39 
 
 
onde cada nó representa uma característica (feature) e suas arestas se referem ao tipo de 
relacionamento entre elas (FERREIRA, 2012). Já a sua raiz é responsável por representar o sistema 
mostrado no respectivo modelo, podendo possuir ramificações em features e em subfeatures (SILVA 
JUNIOR, 2011). Um exemplo desse modelo pode ser visto na Figura 06. 
Dentro de uma LPS, a estrutura produzida e representada pelo diagrama de um modelo de 
features muitas vezes acaba sendo a estrutura da própria LPS (SILVA et al, 2011). Dentro dessa 
estrutura existem mais de um tipo de feature. Segundo Kang et al (1990) as features podem ser 
separadas de acordo com seu tipo, da seguinte forma: 
 Obrigatórias - quando a característica não pode faltar em nenhum produto da linha; As 
features obrigatórias são as funcionalidades que todos os membros da linha de produtos 
devem possuir (partes comuns); 
 Opcionais - são aquelas que são optativas para fazerem parte ou não de um produto; 
 Variáveis - aqui existe um conjunto de features podendo escolher uma o mais delas. As 
features desse conjunto são relacionadas entre si e no momento da escolha e uso, é necessário 
realizar a diferenciação da alternativa OR (que possibilita a escolha de mais de uma feature) 
ou a alternativa que possibilita optar por apenas uma das opções. 
Para diferenciar visualmente esses tipos de features são usadas convenções de cardinalidade. 
De acordo com Deursen e Klint (2001) as features obrigatórias são representadas por um ponto 
fechado, as features opcionais são indicadas a partir de um ponto aberto. Para as features do tipo 
variáveis, são indicadas tanto por um triângulo aberto, que representa as features excludentes entre 
si, como por um triângulo fechado, que representa features que podem ser escolhidas e usadas ao 
mesmo tempo. 
Na Figura 06 encontra-se um exemplo do modelo de features, com ele é possível identificar 
os tipos de features. Na raiz da árvore está a feature correspondente ao nome no sistema. A ela está 
conectada quatro subfeatures três obrigatórias para todas as aplicações, a saber, Catálogo, Pagamento 
e Graphical User Interface - GUI (Interface Gráfica do Usuário). As outras duas são opcionais, 
podendo ser usadas ou não, Segurança e Banners. A feature Catálogo possui as subfeatures Ofertas 
e Pesquisa sendo opcionais e Informação que é obrigatória. Esta última possui a indicação de um 
triângulo preenchido determinando de é possível escolher entre uma ou mais de suas subfeatures 
(Imagem, Descrição e Preço). O mesmo ocorre na feature Pesquisa com suas subfeatures Básico e 
Avançado. A feature Pagamento dá a possibilidade de escolher Cheque, Cartão de Crédito ou ambos 
e em Cartão de Crédito, a escolha é Visa, American Express ou os dois tipos de cartões. 
40 
 
 
Figura 06 - Exemplo de Modelo de Features 
Fonte: Adaptado de SEGURA et al (2010). 
Na feature Segurança, o triângulo aberto informa que apenas uma de suas subfeatures pode 
ser escolhida, não as duas ao mesmo tempo. Na feature de interface (GUI) as opções são as 
subfeatures PC e Mobile (dispositivos móveis) podendo escolher apenas uma ou as duas ao mesmo 
tempo. O modelo informa também que a feature Banner não é obrigatória, podendo fazer parte ou 
não do sistema a ser desenvolvido. 
2.3 LIMITAÇÕES DE LINHA DE PRODUTOS DE SOFTWARE 
O paradigma de LPS baseado na reutilização estratégica de ativos possibilita uma grande 
oportunidade de alcançar benefícios significativos no desenvolvimento de software. Porém, a decisão 
de usar ou não LPS deve ser tomada de forma cautelosa, pois o investimento inicial geralmente é um 
pouco mais oneroso que a forma tradicional como a Engenharia de Software trabalha, assim como os 
custos para manter a base de ativos essenciais. 
Para Northrop e Clements (2012) os custos adicionais trazidos com o uso de LPS podem ser 
observados em algumas etapas do processo de desenvolvimento da linha de produtos. Por exemplo, 
a aquisição dos requisitos para uma linha de produtos, considerando que a mesma é um conjunto de 
sistemas, pode ser complexa, exigindo grande análise para identificar quais requisitos irão compor a 
base de ativos comuns e quais serão os requisitos das variabilidades de todos os sistemas 
individualmente. 
Com relação à arquitetura, ela é o modelo a ser seguido pela linha de produtos servindo como 
base para montar os componentes do núcleo de ativos. Aqui, a desvantagem encontra-se no momento 
em que a arquitetura vai ser definida, pois as variações de cada produto devem ser levadas em 
consideração aumentando as restrições e isso provoca uma maior dificuldade em sua obtenção por 
parte dos engenheiros. 
41 
 
 
A desvantagem encontrada na criação dos componentes da linha de produtos, é que cada 
componente deve ser elaborado seguindo a perspectiva de estarem sempre preparados para serem 
adaptados ao contexto dos produtos, como também devem ser previstos na elaboração, os pontos de 
variação dos produtos. Desse modo, geralmente os componentes devem ser concebidos de uma forma 
mais geral e sem perda de desempenho. 
As necessidades iniciais de negócio como análise de mercado, estimativas de custo e 
cronograma formam as necessidades envolvidas em qualquer produto. Para LPS, esses artefatos 
deverão ser genéricos o suficiente para englobar as características variantes de cada produto. Isso 
demanda uma análise maior para chegar a uma adequação satisfatória. 
Os casos de testes, planos de testes e dados de testes são desenvolvidos e revistos para todos 
os componentes. Assim, os artefatos de testes devem ser mais robustos, pelo fato deles terem que ser 
realizados para mais de um produto. Consequentemente, devem ser extensíveis às variações entre 
cada produto da linha. 
Já no caso das pessoas, suas habilidades e formação, a LPS exige uma equipe bem treinada, 
não só em Engenharia de Software em geral, mas também em específico, entendimento prático em 
LPS, para conseguirem realizar os procedimentos básicos com o uso dos ativos da linha que está 
sendo desenvolvida. Sendo assim, materiais de treinamentos devem ser criados e devem permanecer 
sempre atualizados, pois serão usados principalmente por novos funcionários. 
Outro fator a ser considerado é o custo inicial de desenvolvimento de sistema utilizando LPS. 
O Gráfico 02 exemplifica esse acontecimento, onde é comparado os custos acumulados de 
desenvolvimento entre a abordagem sem LPS e com LPS. 
Gráfico 02 - Custo inicial de uma LPS 
Fonte: Adaptado de Pohl, Böckle e Linden (2005). 
42 
 
 
Com mais detalhes, no mesmo gráfico, é possível observar que a linha contínua representa um