DEFININDO O ESCOPO DE UMA LINHA DE PRODUTOS PARA WEBSITES BASEADOS EM WORDPRESS

DEFININDO O ESCOPO DE UMA LINHA DE PRODUTOS PARA WEBSITES BASEADOS EM WORDPRESS

JÔNATAS CASTRO DOS SANTOS

Universidade Cândido Mendes – UCAM Rio de Janeiro Maio/2014

DEFININDO O ESCOPO DE UMA LINHA DE PRODUTOS PARA WEBSITES BASEADOS EM WORDPRESS

JÔNATAS CASTRO DOS SANTOS

Trabalho de Conclusão de Curso apresentado como requisito para a conclusão do curso de Pósgraduação em Gestão de Tecnologia da Informação e da Comunicação da Universidade Cândido Mendes.

Frederico Sauer, D.Sc. Orientador

Universidade Cândido Mendes – UCAM Rio de Janeiro Maio/2014

SUMÁRIO

INTRODUÇÃO ................................................................................................................ 3 1 - CAPÍTULO I – FUNDAMENTAÇÃO TEÓRICA ...................................................... 5 1.1 – Reuso de software ..................................................................................... 5 1.2 – Linha de Produtos de Software .................................................................. 7 1.2.1 – Desenvolvimento do Núcleo de Artefatos ............................................ 9 1.2.2 – Desenvolvimento do Produto ............................................................. 14 1.2.3 – Gerenciamento .................................................................................. 15 1.3 – Evolução das metodologias de LPS ......................................................... 16 2 - CAPÍTULO II – WORDPRESS: SISTEMA DE GERENCIAMENTO DE CONTEÚDO ..................................................................18 2.1 – Desenvolvimento de features no Wordpress............................................ 21 3 - CAPÍTULO III - WPPL: LINHA DE PRODUTOS PARA WEBSITES WORDPRESS ..................................................................................23 3.1 – Identificação das features ........................................................................ 26 3.2 – Definição do escopo ................................................................................. 32 3.3 – Avaliação.................................................................................................. 34 CONCLUSÃO ................................................................................................................ 39 REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................ 41

ii

3

INTRODUÇÃO

O uso da internet cresceu exponencialmente nos últimos anos, transformando a World Wide Web em um “parque ecológico” de informações e conhecimento (HUBERMAN e ADAMIC, 1999). Grande parte desse conteúdo é gerada por usuários comuns. Isso foi possível graças aos Sistemas de Gerenciamento

de

Conteúdo

(Content

Management

Systems

–

CMS)

(MCKEEVER, 2003). CMS é um sistema que auxilia a produção e organização de conteúdos com o objetivo de produzir páginas dinâmicas de fácil utilização. Entre as plataformas de CMS mais populares está o Wordpress1. Em Maio de 2013, o Wordpress possuía 57% de participação no mercado contra apenas 3.4% do seu maior concorrente, o Blogger (CASTELLUCCIO, 2013). O objetivo inicial de CMS como o Wordpress era o gerenciamento de blogs pessoais. Blog é o termo utilizado para descrever websites que mantêm as informações em ordem cronológica (MULLENWEG, 2014). Entretanto, tem-se utilizado o CMS Wordpress como a base para o desenvolvimento de muitos sites dinâmicos. O LinkedIn e FordSocial2, por exemplo, são sites que utilizam o Wordpress para gerenciamento de conteúdo. A indústria de Marketing Digital frequentemente utiliza esse tipo de tecnologia para construir sistemas web com páginas dinâmicas porque o CMS 1

Disponível em http://www.wordpress.org e http://www.wordpress.com

2

Acessíveis por http://www.linkedin.com e http://social.ford.com, respectivamente

4

oferece uma interface facilitada e produtiva, tanto para o usuário administrador do sistema como para o editor de conteúdo. Organizações que produzem esse tipo de software necessitam de mecanismos que aumentem a eficiência do processo de construção dessas aplicações, dado que esse processo se torna mais complexo à medida que novas funcionalidades não suportadas pelo CMS são implementadas. Entretanto, notase que grande parte dos sistemas produzidos possui funcionalidades similares e poucas variações sugerindo práticas que potencializem a reutilização. Portanto, o objetivo deste trabalho é apoiar a construção de sistemas web que utilizam a plataforma Wordpress utilizando práticas de reuso sistematizado. Para isso, será definido o escopo de uma Linha de Produtos de Software para uma organização que produz esse tipo de software. O capítulo 1 deste trabalho descreve os fundamentos teóricos sobre reuso de software e Linhas de Produto de Software. O capítulo 2 apresenta a plataforma Wordpress e identifica os desafios a serem superados do desenvolvimento de sistemas web baseados em Wordpress. O capítulo 4 descreve a contribuição do trabalho, através da apresentação do escopo de uma linha de produtos de software para uma empresa desenvolvedora de sistemas web que utiliza Wordpress, e a conclusão encerra o trabalho.

5

CAPÍTULO I FUNDAMENTAÇÃO TEÓRICA

1.1 – REUSO DE SOFTWARE

As práticas de Engenharia de Software surgiram em meados dos anos 70 quando houve a preocupação de desenvolver software através de um processo organizado (LARMAN e BASILI, 2003) (REINEHR, 2008). Entretanto, o reuso de software é uma prática que surgiu desde os primórdios da programação (KANG, 2005). Reuso de software se trata da utilização de um software ou artefato existente para construir um novo software. Reusabilidade é uma característica de um software que indica a capacidade de ser reutilizado (KANG, 2005). O reuso de software permite melhorar a produtividade e qualidade de um software e, com isso, maximizar a lucratividade das organizações. Para atingir esses objetivos, é necessário aplicar o capital de investimento adequadamente. Geralmente, é preciso um investimento proativo e o retorno

6

sobre o investimento apenas é percebido quando os produtos são desenvolvidos e mantidos (KANG, 2005). Muitas

abordagens

e

estudos

sobre

reusabilidade

foram

desenvolvidos ao longo dos anos. O conceito de Engenharia de Domínio tornouse fundamental no reuso de software. Esse conceito baseia-se em admitir que a maioria dos softwares não são novos, mas são variantes de softwares que já existem. Os software construídos são direcionados a pequenas linhas de negócio, denominados domínios. Portanto, as variações desse software serão construídos sobre o mesmo domínio (KANG, 2005). Engenharia de Domínio também é definido como a atividade de coletar, organizar e armazenar a experiência anterior na construção de sistemas ou partes de sistemas, em um domínio particular, na forma de ativos reutilizáveis, assim como prover formas adequadas de reusar estes ativos ao construir novos sistemas (REINEHR, 2008) (CZARNECKI e EISENECKER, 2000). É importante atentar-se ao fato de que os métodos de Engenharia de Domínio geralmente dão mais ênfase à análise de domínio, omitindo as práticas de instanciação dos produtos. No entanto, a Engenharia de Domínio tratada como uma disciplina que complementa a abordagem de Engenharia de Linha de Produto ou ainda, Linha de Produtos de Software (REINEHR, 2008). Esta é considerada uma das práticas mais eficazes de reuso sistematizado de software (KANG, 2005).

7

1.2 – LINHA DE PRODUTOS DE SOFTWARE

O SEI - Software Engineering Institute – da Carnegie Mellon Univesity é um instituto financiado pelo departamento de defesa dos EUA, notoriamente conhecido no mundo por seus estudos e pesquisa na área de Engenharia de Software. O instituto promoveu o primeiro workshop sobre a prática de Linha de Produtos de Software (LPS). O evento tinha como objetivo compartilhar experiências da indústria de software e do governo com a prática de LPS, visando o conhecimento de aspectos conceituais e técnicos (BAS, 97) (LAZILHA, 2002). Como pioneiro na abordagem de LPS, o SEI tem como iniciativa a Product Line Practise (PLP). A iniciativa já possui um compilado de boas práticas, bem como, uma série de programas de treinamento e certificados profissionais. O SEI tem o objetivo de tornar LPS uma prática de baixo risco, e bom custobenefício para empresas (SEI, 2012). Linha de Produtos de Software (LPS) é definida como um conjunto intensivo de sistemas de software que compartilham e gerenciam características comuns e variabilidades, satisfazem as necessidades de um segmento particular de mercado ou missão e são desenvolvidos a partir de um núcleo de artefatos (SEI, 2012) (NORTHOP e CLEMENTS, 2002). Trata-se de um agrupamento de aplicações com arquitetura comum e componentes compartilhados, sendo que, cada aplicação é especializada para atender as necessidades dos clientes. A LPS envolve a criação de documentos

8

de requisitos, arquitetura e implementação de componentes para compor uma família de sistemas, onde cada membro é um produto derivado e configurado. A LPS geralmente surge de aplicações existentes. Quando uma organização desenvolve uma aplicação e um sistema similar é requisitado, grande parte do seu código é reutilizada informalmente. O mesmo ocorre quando outras aplicações similares são requisitadas.

Isso tende a corromper a estrutura da

aplicação porque cada vez que instâncias novas são produzidas, a criação de uma nova versão se torna mais complexa. Por conseguinte, pode-se solucionar este problema com a criação de uma LPS. Torna-se necessário, portanto, identificar funcionalidades comuns nas instâncias das aplicações para inclui-las em uma arquitetura base. Esta é cuidadosamente estruturada para simplificar o reuso e a reconfiguração. A LPS, segundo a estrutura definida pelo (SEI, 2012), que se encontra em sua quinta versão, é composta três ciclos de vida que são essenciais na construção de uma LPS: 

Desenvolvimento do núcleo de artefatos,



Desenvolvimento do produto, e



Gerenciamento da Linha de Produtos.

Todos os três ciclos da LPS possuem suas essencialidades dentro da LPS. Conforme a disposição da Figura 1, as setas cíclicas mostram que as três atividades interagem entre si e podem ocorrer em qualquer ordem. É importante ressaltar que alterações de atividades em um dos ciclos impactarão necessariamente nos outros (NORTHOP e CLEMENTS, 2002).

9

Figura 1 - Ciclos de vida da Linha de Produtos de Software (SEI, 2012)

1.2.1 – DESENVOLVIMENTO DO NÚCLEO DE ARTEFATOS

O Desenvolvimento do Núcleo de Artefatos, também reconhecido como Engenharia de Domínio (NORTHOP e CLEMENTS, 2002), é responsável por estabelecer uma plataforma reutilizável na linha de produtos, isto é, o núcleo de artefatos comuns3. Trata-se da base para a geração de produtos na LPS. Esse ciclo ocorre sobre a influência de diversos fatores, dentre os quais, existem quatro mais importantes: (i) restrições de produto, (ii) restrições de produção, (iii) estratégia de desenvolvimento e (iv) artefatos pré-existentes (SEI, 2012).

3

Ou base de ativos comuns; tradução de Core assets.

10

As restrições de produto estão intrinsicamente relacionadas ao conceito de feature. Basicamente, feature pode ser definida como uma característica que o usuário final considera importante na descrição e distinção de um produto (GRISS, 2000). Definir e distinguir as features que são comuns daquelas que variam entre os produtos é um dos principais desafios na Engenharia de Domínio. A definição dos requisitos, escopo da LPS e o entendimento do domínio sobre o qual se trata a LPS são atividades que ajudam a definir as restrições do produto (SEI, 2012). As restrições de produção

abordam questões de tempo,

planejamento, recursos e decisões estratégicas relacionadas ao objetivo da organização quanto aos produtos. Nesse aspecto procura-se ter o conhecimento sobre: prazos em que os produtos devem estar disponíveis no mercado; padrões de desenvolvimento que serão adotados pela organização; tamanho, nível e ambiente da equipe técnica que irá desenvolver os produtos. Esse fatores irão direcionar sobre que tipo de mecanismo de variação o núcleo de artefatos irá prover. A estratégia de desenvolvimento diz respeito à abordagem que a organização utilizará quanto ao Desenvolvimento do Núcleo de Artefatos e o Desenvolvimento do Produto. A estratégia pode ser: proativa/pesada, quando se preocupa desenvolver o núcleo de artefatos antes de instanciar os produtos; ou reativa/leve, quando já existe um conjunto de produtos de onde se extraem componentes reutilizáveis para formar o núcleo de artefatos (SEI, 2012). A escolha da abordagem irá implicar no custo da LPS ao longo do tempo (Figura 2 – Comparação entre as estratégias de desenvolvimento de LPS e abordagem convencional (produtos únicos). Adaptado de .). Na estratégia pesada, há um

11

custo inicial maior, entretanto, após o desenvolvimento de três produtos, o custo de novas instâncias é menor em relação à estratégia convencional. No caso da estratégia leve, o custo inicial é menor do que na estratégia pesada, no entanto, o retorno do investimento é mais tardio (MCGREGOR, NORTHROP, et al., 2002).

Figura 2 – Comparação entre as estratégias de desenvolvimento de LPS e abordagem convencional (produtos únicos). Adaptado de (MCGREGOR, NORTHROP, et al., 2002).

A existência de produtos já desenvolvidos e sistemas legados podem embasar o domínio de conhecimento de uma organização. Por isso, artefatos pré-existentes, que já foram testados e possuem elevado grau de robustez, podem ser utilizados para compor parte do núcleo de artefatos. A seleção desses artefatos requer um esforço de filtragem e análise com o objetivo de tornar esses artefatos reutilizáveis. A reutilização desse tipo de artefato não se limita apenas a sistemas legados pertencentes a organização, mas pode-se tirar proveito de outros softwares disponíveis como, por exemplo, Web Services ou produtos open source (SEI, 2012).

12

Figura 3 – Ciclo de Desenvolvimento do Núcleo de Artefatos (SEI, 2012)

O ciclo de Desenvolvimento do Núcleo de Artefatos deve gerar como saída três elementos que são essenciais para a capacidade de produzir produtos na LPS: (i) escopo da LPS, (ii) o núcleo de artefatos e (iii) o plano de produção. O escopo da LPS é a descrição do domínio da linha de produtos, isto é, consiste na relação de produtos que a LPS possui ou de produtos que a LPS poderá conter (SEI, 2012). É preciso definir o escopo cautelosamente para que não haja esforços desnecessário que desvirtuariam a LPS. Se o escopo da LPS for muito amplo, por exemplo, seria muito custoso manter o núcleo de artefatos de forma a acomodar variabilidades de todos os produtos convergindo para um esforço do desenvolvimento tradicional.

Se o escopo é pequeno demais, o núcleo de

13

artefatos poderá não comportar o crescimento dos produtos levando a estagnação da LPS, ou seja, não haveriam retornos econômicos suficientes que justifiquem a LPS (SEI, 2012). A definição do escopo de uma LPS é uma tarefa que envolve a análise de diversos fatores de forma conjunta. Mudanças em condições de mercado, alterações no planejamento organizacional e surgimento de novas oportunidades são exemplos desses fatores (SEI, 2012). O núcleo de artefatos é a principal saída da Engenharia de Domínio. Trata-se de um repositório que inclui todos os artefatos de software que poderão ser utilizados para criar os produtos. Os artefatos podem ser qualquer documento de requisitos, modelos, teste ou código-fonte. Essa saída também inclui uma arquitetura que todos os produtos da LPS irão compartilhar (SEI, 2012). O plano de produção prescreve como os produtos serão produzidos a partir do núcleo de artefatos. Cada artefato terá anexado consigo um processo que especifica como o artefato será utilizado no desenvolvimento dos produtos. Além desses processos, existem elementos que devem associar os artefatos entre si. O conjunto dos processos anexados e esses elementos de associação formam o plano de produção. Este plano deve seguir ou formar uma abordagem para satisfazer de forma coerente às restrições de produção, bem como, à estratégia de desenvolvimento. A abordagem escolhida deve especificar modelos, processos e ferramentas que serão utilizados na produção dos produtos (SEI, 2012). Além disso, o plano de produção também inclui componentes relacionados ao projeto que viabilizará os processo de produção e ainda outros

14

subsídios como cronograma, métricas de software e contabilização de materiais utilizados na LPS (SEI, 2012).

1.2.2 – DESENVOLVIMENTO DO PRODUTO

O Desenvolvimento do Produto também é chamado de Engenharia de Aplicação (NORTHOP e CLEMENTS, 2002). É a atividade responsável por gerar os produtos, de fato. Essa atividade depende das três saídas do ciclo de Desenvolvimento do Núcleo de artefatos além de uma descrição de produto para cada produto único da LPS (Figura 4).

Figura 4 – Ciclo de Desenvolvimento do Produto (SEI, 2012)

No Desenvolvimento do Produto, o núcleo de artefatos será utilizado para disponibilizar as peças que irão compor os produtos. O plano de produção

15

irá fornecer os detalhes sobre como o núcleo de artefatos será utilizado para construir os produtos. O escopo da LPS deve indicar se o produto a ser construído possui o perfil adequado para a LPS ou ainda ser decomposto em componentes do núcleo de artefatos. A descrição do produto caracteriza a instancia de cada elemento fim da LPS. Geralmente, a descrição de cada produto é explicitada como a variação do produto em relação a uma descrição genérica contida no escopo da LPS (SEI, 2012). O Desenvolvimento do Produto tem como saída: os produtos, elementos finais da LPS; feedbacks dos desenvolvedores concernentes a problemas e dificuldades encontradas na manipulação dos artefatos durante a construção do produto; novos artefatos que irão compor os núcleo de artefatos; e restrições de produto, que podem revelar novas features para a LPS (SEI, 2012).

1.2.3 – GERENCIAMENTO

O Gerenciamento é uma atividade crítica da LPS. Os recursos aplicados às atividades da LPS precisam ser devidamente coordenados e supervisionados com o objetivo de manter a integridade da LPS. O Gerenciamento ocorre tanto no nível organizacional como no nível técnico. No nível organizacional, o gerenciamento precisa garantir que as unidades organizacionais recebam recursos suficientes para manter a atividade de LPS. O gerenciamento organizacional também deve prover uma estrutura que viabilize a LPS dentro da instituição. Outro aspecto tratado pelo gerenciamento

16

organizacional são os riscos nocivos a LPS, que tem ser mitigados. Segundo o (SEI, 2012), o gerenciamento organizacional é a autoridade responsável pelo sucesso ou fracasso final da LPS. No

nível

técnico,

o

gerenciamento

deve

garantir

que

os

desenvolvedores estejam comprometidos com as atividades da LPS e sigam corretamente os processos definidos pela abordagem da LPS (SEI, 2012).

1.3 – EVOLUÇÃO DAS METODOLOGIAS DE LPS

A primeira geração de metodologias de LPS é caracterizada por uma separação lógica entre a Engenharia de Domínio e a Engenharia de Aplicação. Essa separação gerava um problema evidente quando um novo produto era inserido na LPS: era necessário manter uma nova equipe de desenvolvedores dedicados ao produto. Outro problema frequente é que cada produto pode agregar um contexto único e isolado em que os artefatos são reutilizados. Em casos não triviais, isso dificulta o reaproveitamento do núcleo de artefatos indo de encontro ao objetivo da LPS (KRUEGER, 2006). Estudos mais recentes possibilitaram que novos métodos fossem criados para apoiar o reuso sistemático em LPS diminuindo, consequentemente, os problemas das metodologias da primeira geração. A metodologia de Customização de Software em Massa, por exemplo, diminui os efeitos negativos da Engenharia de Aplicação através da automatização deste ciclo. Em vez de utilizar uma equipe voltada apenas para o

17

desenvolvimento do produto, são utilizados “configuradores de LPS” para instanciar produtos automaticamente a partir de duas entradas: modelos de features e núcleos de artefatos. Dessa forma, todos os produtos gerados dependem dos ativos do núcleo de artefatos. A vantagem desta abordagem é que todo o trabalho existente na LPS é focado apenas no desenvolvimento e manutenção do núcleo de artefatos. Neste viés, mudanças no núcleo de artefatos implicam que todos os produtos serão atualizados de forma automática, sem intervenções manuais (KRUEGER, 2006).

18

CAPÍTULO II WORDPRESS: SISTEMA DE GERENCIAMENTO DE CONTEÚDO

Geralmente, os Sistemas de Gerenciamento de Conteúdo (CMS) surgem da necessidade de organizar e manter conteúdos. Entretanto, uma definição oficial de CMS ainda não foi convencionada (HAN, 2004). Devido o termo “conteúdo” possuir mais de um significado em diferentes disciplinas, o conceito de CMS é ambíguo. No entanto, Boiko define CMS como o processo de coletar, gerenciar e publicar conteúdos (BOIKO, 2004, p. 67). Muitas organizações passaram a utilizar CMS como base para suas aplicações web. Os CMS ou ainda, Web CMS, permite que as organizações criem e publiquem conteúdos digitais facilmente, tornando-os disponíveis para o público que tem com acesso internet (MCKEEVER, 2003). Aplicações

web

baseadas

em

CMS

apresentam

algumas

características que as fazem diferir de aplicações web tradicionais. Em (TRIAS, 2012), são relacionadas as principais características desse tipo de aplicação: (i) ser gerenciado por uma larga equipe produtora de conteúdo, onde a responsabilidade do website passa a ser dos editores e autores, interessados do

19

negócio, e não mais do desenvolvedor técnico; (ii) identificação e gerência dos papéis de usuários do website, bem como, grupo de usuários; (iii) foco principal na ser gerência de conteúdos e componentes e não páginas - os conteúdos podem ser páginas HTML, XML, imagens, vídeos, documentos, e-mails, catálogos, produtos etc.; (iv) todo o conteúdo é guardado em um repositório ou fonte de dados; (v) metadados;

(vi)

conteúdos devidamente categorizados utilizando-se

independência

entre

conteúdo

e

apresentação;

(vii)

gerenciamento dinâmico do leiaute e aparência visual; (viii) suporte para definição de fluxos de trabalho. Wordpress é um CMS que possui uma série de recursos que tornam a experiência como editor na internet facilitada (MULLENWEG, 2014). Trata-se de uma plataforma gratuita de publicação pessoal que permite gerenciar conteúdos que serão publicados na internet. Nesse caso, os conteúdos podem ser páginas, postagens de blog, bem como, listas de links, eventos, galeria de imagens e vídeos, comentários, entre outros (JONES e FARRINGTON, 2011). O

Wordpress

está

disponível

em

duas

versões

distintas:

Wordpress.com e Wordpress.org. A versão .org é disponibilizada como um pacote de software que deve ser configurado e hospedado em um ambiente particular. Já a versão .com oferece um ambiente que já inclui o domínio e a hospedagem do website de forma gratuita. As duas versões funcionam com o mesmo software desenvolvido na linguagem PHP em conjunto com o sistema de banco de dados MySQL. O software é Open Source e está em constante atualização

pela

comunidade

(CASTELLUCCIO, 2013).

de

desenvolvedores

Open

Source

20

Inicialmente, o Wordpress era um CMS com o foco em publicação pessoal, isto é, blogs. Posteriormente, a estrutura do Wordpress foi evoluída possibilitando a construção de diversos tipos de website a partir de sua estrutura (MULLENWEG, 2014). Portanto, o Wordpress é rico em funcionalidades de gerenciamento de conteúdo para websites. O sistema do Wordpress permite o gerenciamento de um website de forma eficiente criando uma separação lógica entre os papeis de administração e edição do website. Os administradores podem configurar, customizar e incluir/alterar funcionalidades no website, enquanto os editores inserem e gerenciam seu próprio conteúdo sem se preocupar com aspectos mais técnicos (JONES e FARRINGTON, 2011).

Website Tema Header.php Index.php

Wordpress CMS

single.php

Category.php

Footer.php Styles.css

Plug-in 1

Plug-in 2

Figura 5 - Estrutura de um website com Wordpress

A estrutura do Wordpress (Figura 5) possibilita a customização de websites em duas formas: através de um tema e através de plug-ins. O tema é um conjunto de arquivos que são interpretados pela plataforma para prover o projeto visual e features ao website. Basicamente, os arquivos possuem códigos em PHP e definições de folha de estilo em

21

cascata(CSS). Os temas tiram vantagens de funções que a plataforma fornece para prover diferentes tipos de features ao website (MULLENWEG, 2014). Os plug-ins permitem modificar, customizar ou melhorar a estrutura do Wordpress. A ideia dos plug-ins é oferecer um novo serviço ou uma feature ao website sem alterar a estrutura da plataforma (MULLENWEG, 2014). Em Janeiro de 2014, a comunidade open source disponibilizava mais de 30.500 plug-ins com todo o tipo de feature (MULLENWEG, 2014). A criação de websites utilizando a plataforma Wordpress, portanto, gira em torno da criação ou reutilização de um tema e a criação ou reutilização de plug-ins. No entanto, a construção desses artefatos pode se tornar complexa a medida que funcionalidades que não são suportadas nativamente pelo CMS são adicionadas.

2.1 – DESENVOLVIMENTO DE FEATURES NO WORDPRESS

É comum que as organizações pequenas do segmento de Marketing Digital iniciem um novo projeto de website construindo um tema para o Wordpress que é direcionado para um projeto único. Posteriormente, a medida que novos websites são criados, trechos de código de temas anteriores são manualmente reutilizados. Isso ocorre porque muitos websites possuem features em comum. Quando um projeto é iniciado, algumas features podem não estar disponíveis nativamente pelo Wordpress, nesse caso, busca-se por plug-ins que

22

atendam os requisitos desejados pelo cliente. Entretanto, alguns projetos demandam a criação de plug-ins para atender features específicas. A vantagem da criação de plug-ins é a facilidade de reutiliza-los em outros projetos que utiliza a plataforma e o domínio de conhecimento sobre o código-fonte de plug-in que é de autoria da própria organização. Algumas empresas optam pela reutilização de plug-ins já existentes na comunidade Open Source. Essa alternativa nem sempre é uma adequada devido a volatilidade de atualizações do plug-in e do próprio sistema do Wordpress. Contudo, a criação e manutenção de temas e plug-in é um desafio constante para organizações que utilizam a plataforma como base para o desenvolvimento de seus websites. Conforme essas organizações crescem, a demanda de projetos aumenta e isso requer mecanismos que auxiliem a construção e gerencia dos websites. Isso envolve melhorar o processo de reutilização dos temas e plug-ins do CMS. A abordagem de Linha de Produtos de Software busca solucionar problemas de reutilização em massa como é o cenário dessas organizações. A seguir, propõe-se utilizar práticas de LPS para apoiar a construção em massa, semiautomática, de websites Wordpress.

23

CAPÍTULO III WPPL: LINHA DE PRODUTOS PARA WEBSITES WORDPRESS

Quando empresas que já desenvolvem softwares há um tempo decidem utilizar a abordagem de Linha de Produtos de Software, pode-se optar pela estratégia reativa/leve. Nesse caso, a organização já possui um conjunto de produtos e, portanto, é desejado que os componentes desses produtos sejam reutilizados. Neste trabalho, através da estratégia reativa/leve, deseja-se definir o escopo de uma linha de produtos para websites baseados em Wordpress – WPPL (Wordpress-based websites Product Line). A ideia é focar apenas na Engenharia de Domínio através de um modelo de features que abstrai um núcleo de artefatos para a WPPL. A seguir será especificado um cenário hipotético

de uma

organização que possui um conjunto de websites baseados em Wordpress já criados e publicados. Para facilitar o estudo, serão apresentados apenas dois websites já desenvolvidos pela organização de onde serão extraídas as features. O primeiro

24

(Figura 6) é de uma igreja cristã protestante denominada Assembleia de Deus e o segundo (Figura 7) é de uma instituição cristã que tem o objetivo de capacitar adultos e disseminar o conhecimento cristão para o público infantil – Aliança PróEvangelização de Crianças. Ambos são baseados na plataforma Wordpress. Para facilitar a identificação, o primeiro site será chamado de projeto A e o segundo, de projeto B.

Figura 6 – Website da igreja evangélica Assembleia de Deus (projeto A)

25

Figura 7 – Website da Aliança Pró-Evangelização de Crianças – RJ (projeto B)

26

3.1 – IDENTIFICAÇÃO DAS FEATURES

Nesta etapa, busca-se, listar e entender as features de cada website. Posteriormente, será preciso distinguir as features que são comuns entre os websites daquelas que não são comuns entre websites. Todas as features serão extraídas sobre os temas e plug-ins de Wordpress utilizados pelos projetos. Inicialmente, portanto, serão identificadas e listadas as features de cada projeto. A Figura 8 apresenta uma lista de features do projeto A e a Figura 9 apresenta uma lista de features do projeto B. Conforme as figuras Figura 8 e Figura 9, ambos os projetos apresentam uma página principal, também chamada de Index, que está sendo considerada uma feature. Esta página é o ponto inicial de navegação do website. Ela apresenta algumas features que serão descritas a seguir: 

Menu superior no cabeçalho – um menu editável que contém links para páginas estáticas e é posicionado no cabeçalho, parte superior da parte principal.



Busca de conteúdos – possibilita o usuário buscar facilmente qualquer conteúdo do website através de palavras-chave digitadas em um campo de texto.



Menu horizontal – outro menu editável que contém links para páginas estáticas e é posicionado logo abaixo do cabeçalho, próximo a área central do site.

27

Features do Projeto A Página principal •Menu superior no cabeçalho •Busca de conteúdos •Menu horizontal •Slideshow de destaque •Seleção de últimas notícias •Seleção de notícias destacadas •Exibição de fotos do Flickr •Informações de contato no rodapé •Menu inferior no rodapé Página de postagem •Comentários •Breadcrumbs •Seleção de notícias relacionadas •Compartilhamento em redes sociais Página estática •Breadcrumbs •Formulário de contato •Exibição de postagem relacionada a mesma categoria Página de categoria

Página 404

Otimizações de SEO •Otimização de Títulos •Arquivo robots.txt •Sitemap

Figura 8 – Listagem de features do Projeto A

28

Features do Projeto B Página principal •Menu superior no cabeçalho •Busca de conteúdos •Menu horizontal •Slideshow de destaque •Seleção de últimas notícias •Exibição da agenda •Agenda baseada em conteúdos (Super Seminários) •Informações de contato no rodapé •Menu inferior no rodapé Página de postagem •Comentários •Breadcrumbs Página estática •Breadcrumbs •Formulário de contato

Página de categoria Página 404 Otimizações de SEO •Otimização de Títulos •Arquivo robots.txt •Sitemap Agenda

•Integração ao Google Calendar

Figura 9 – Listagem de features do Projeto B



Slideshow de destaque – um conjunto de slides de imagens que passam automaticamente com algum efeito de transição e está posicionado em uma posição destacada e visível do website.



Seleção de últimas notícias – exibe um conjunto de postagens recentes.

29



Seleção de notícias destacadas (apenas projeto A) – exibe um conjunto de notícias que são selecionadas pelo editor.



Exibição de fotos do Flickr (apenas projeto A) – exibe um conjunto de fotos de uma conta do Flicker.



Informações de contato no rodapé – exibe as informações de contato relacionado a instituição posicionadas na parte inferior da página.



Exibição dos últimos itens da agenda (apenas projeto B) – exibe os próximos eventos que ocorrerão.



Agenda baseada em conteúdos (Super Seminário) (apenas projeto B) – exibe um conjunto de eventos denominados “Super Seminários”, no caso do projeto B, em forma de agenda, exibindo aqueles que irão ocorrer a partir da data corrente.



Menu inferior no rodapé – um menu que contém links para páginas estáticas do website e é posicionado na parte inferior, no rodapé. Além da página principal, os websites apresentam uma página de

postagem que também é considerada uma feature. A página de postagem corresponde ao leiaute de apresentação das postagens. Esse leiaute pode apresentar as seguintes features: 

Breadcrumbs – indicam o local e o caminho de navegação da página que o usuário se encontra. Ex: Página principal > Notícias > Categoria da notícia > “Página da notícia corrente”



Comentários – permite que os usuários postem comentários na página da postagem. Os comentários serão exibidos na página sob a moderação do editor.

30



Seleção de notícias relacionadas (apenas projeto A) – exibe um conjunto de notícias, selecionado automaticamente por categoria ou palavra-chave, que esteja relacionado com o mesmo assunto da página de postagem.



Compartilhamento de redes sociais (apenas projeto A) – exibe botões de redes sociais que possibilitam o compartilhamento da página de postagem. Os projetos também apresentam a feature página estática. Trata-se

do leiaute das páginas do website com conteúdo estático e pouco volátil. Assim como as páginas de postagem pode conter as features Breadcrumbs, além das features: 

Formulário de Contato – exibe um formulário para o preenchimento de informações de contato e uma mensagem a ser submetida para a instituição.



Exibição de postagens relacionadas a página (apenas projeto A) – exibe postagens que estejam relacionadas ao assunto da página estática. A feature Otimizações de SEO são melhorias realizadas para

melhorar a visibilidade do site para os robôs de indexação de sistemas de busca como o Google. As melhorias podem ser Otimização dos título, inclusão do arquivo robots.txt realizar uma filtragem das páginas que devem ser indexadas pelos robôs e o sitemap que é um documento que descreve todas as páginas do website. Todas essas melhorias são consideradas features. O projeto B apresenta a feature Agenda, que permite o cadastro de uma agenda integrada ao CMS. Esta agenda pode ser integrada a API do Google Calendar gerando mais uma possibilidade de feature. Outras features comum aos projetos é a página de categoria, que exibe o conjunto das postagens de uma determinada categoria, página 404, que é a apresentação da página um conteúdo não encontrado.

31

Tendo descrito as features extraídas dos dois projetos, faz-se necessário identificar as features comuns e aquelas que são exclusivas. A Figura 10 apresenta a listagem das features que são comuns aos projetos e com isso é possível identificar os pontos de variação entre os projetos, isto é, aquelas features que são exclusivas de um projeto.

Features comuns Página principal •Menu superior no cabeçalho •Busca de conteúdos •Menu horizontal •Slideshow de destaque •Seleção de últimas notícias •Informações de contato no rodapé •Menu inferior no rodapé Página de postagem •Comentários •Breadcrumbs Página estática

•Breadcrumbs •Formulário de contato Página de categoria

Página 404

Otimizações de SEO •Otimização de Títulos •Arquivo robots.txt •Sitemap

Figura 10 – Features comuns a ambos os projetos

32

3.2 – DEFINIÇÃO DO ESCOPO

A partir da identificação das features concernentes aos temas e plug-ins de Wordpress utilizados nos projetos, pode-se propor um modelo de features. A modelagem de features permite definir o escopo da LPS. Um modelo de features adequado consegue descrever as partes comuns e variáveis de uma LPS e é o passo inicial para iniciar o ciclo do Desenvolvimento do produto (ŠTUIKYS e DAMAŠEVICIUS, 2008). Para realizar a modelagem de features será utilizado o diagrama de features proposto em (ŠTUIKYS e DAMAŠEVICIUS, 2008), largamente utilizado em Linhas de Produtos de Software (NORTHOP e CLEMENTS, 2002). Website Wordpress

Página de Categoria

Busca de conteúdos

Página Principal (INDEX)

Seleção de últimas postagens

Slideshow

Página de Postagem

Página 404

Informações de contato no rodapé

Geração do sitemap

Comentários

Menu

Breadcrumbs Agenda

Menu superior

Menu horizontal

Menu inferior

Otimizações de SEO

Página Estática

Otimização de Títulos

Exibição de postagens relacionadas

Formulário de Contato Integração ao Google Calendar

Figura 11 – Diagrama de features para a WPPL

Geração automática do robots.txt

33

Para desenvolver o diagrama de features (Figura 11) para o WPPL, foi necessário extrair as features comuns e identificar os pontos de variação entre os projetos A e B. Após a identificação desses pontos de variação, foi necessário identificar: features mandatórias; features opcionais; features alternativas (mandatórias ou opcionais). Features mandatórias são aquelas requeridas para os produtos. No diagrama, são marcadas pelo símbolo de um círculo preenchido no topo do retângulo que representa a feature. A feature Página principal, por exemplo, foi considerada mandatória já que todos os produtos a serem desenvolvidos necessitam dessa feature. Do mesmo modo ocorre com Página de categoria, Página 404, Página de postagem, Página Estática e Menu. Neste último acaso, ocorre a classificação de feature alternativas nas features “filhas” de Menu, isto é, Menu superior, Menu horizontal e Menu inferior. Por ser um requisito do website, foi decidido que fosse criado a features Menu sendo uma agrupamento das features que foram extraídas do projeto. A notação significa que pelo menos uma dessas features “filhas” devem ser implementadas para viabilizar a feature “pai”. O restante das features, que são marcadas por um círculo não preenchido, são features opcionais. Estas não foram consideradas obrigatórias para os produtos. Todas as features exclusivas nos projetos A ou B recebem esta classificação. Percebe-se que no decorrer do processo de modelagem algumas features não são incluídas no modelo por serem consideradas muito específicas. É o caso da feature Agenda baseada em conteúdos (Super Seminário) do projeto B. A inclusão dessa feature no escopo da WPPL não teria um impacto

34

positivo para a geração dos produtos devido ao excesso de restrições específicas dessa feature.

3.3 – AVALIAÇÃO

Para avaliar a eficácia do diagrama de features definido, foi realizado um estudo experimental de geração de modelos de features de produtos específicos da WPPL. O objetivo da avaliação é medir o grau de reusabilidade das features contidas no modelo genérico (Figura 11 – Diagrama de features para a WPPL) em relação aos modelos específicos gerado. Portanto,

no

estudo

experimental,

foram

realizadas

três

especificações de novos websites requisitados para a organização hipotética. Os websites possuem um caráter semelhante ao que se costuma ser criado pela organização. A partir das especificações desses websites, foram geradas modelos de features e depois estes foram comparados com o modelo genérico. A técnica de Análise de Pontos de Função (ALBRECHT e GAFFNEY, 1983) foi utilizada para obter uma estimativa do tamanho das features. A métrica possibilitou ao estudo, obter uma relação entre features reutilizadas e consequentemente, verificar quanto da arquitetura genérica da WPPL seria reutilizado caso o produto fosse implementado.

35

Website 1

Página de Categoria

Página Principal (INDEX)

Seleção de últimas postagens

Menu superior

Menu inferior

Menu vertical

Página de Postagem

Página 404

Página Estática

Login com Facebook

Formulário de Contato

Breadcrumbs Agenda

Slideshow

Login com Twitter

Exibição de postagens relacionadas

Comentários

Website 2

Página de Categoria

Página Principal (INDEX)

Menu superior

Slideshow

Seleção de últimas postagens

Página de Postagem

Página 404

Página Estática

Login com Facebook

Breadcrumbs

Comentários

Contagem de visitantes

Comentários compartilhados no Facebook

Exibir amigos do Facebook que curtiram o website

Website 3

Página de Categoria

Página Principal (INDEX)

Menu superior

Menu inferior

Página de Postagem

Página 404

Agenda

Menu horizontal

Integração com o Google calendar

Página Estática

Breadcrumbs

Comentários

Formulário de Contato

Slideshow

Figura 12 – Diagramas de features dos websites especificados para o estudo experimental

36

A Tabela 1 mostra o resultado da medição para as features do modelo genérico (Figura 11). A Figura 12 apresenta os diagramas de features para os três websites especificados para o estudo experimental. Os diagramas indicam as features que foram extraídas e estão contidas no projeto dos websites. Esses modelos específicos não contém as restrições de mandatoriedade ou opcionalidade, pois representam o estado do website em termos de features. As features destacadas no diagrama representam aquelas que não estão presentes no modelo genérico do WPPL. A tabela 2 indica a estimativa em pontos de função para essas features.

Feature Página principal Busca de conteúdos Slideshow Seleção de últimas postagens Informações de contato no rodapé Menu Menu superior Menu horizontal Menu inferior Página de categoria Página 404 Página de postagem Página estática Otimizações de SEO Otimizações de título Geração do sitemap Geração automática do robots.txt Agenda Integração ao Google Calendar Comentários Exibição de postagens relacionadas Breadcrumbs Formulário de Contato

Nº de pontos de função (P.F.) 15 5 5 3 3 5 3 3 3 7 6 10 10 5 3 3 3 10 4 5 4 3 4

Tabela 1 - Contagem de pontos de função das features da WPPL

37

Feature Login com Facebook Login com Twitter Menu vertical Contagem de visitantes Comentários compartilhados no Facebook Exibir amigos do Facebook que curtiram o website

Nº de pontos de função (P.F.) 10 10 5 3 5 5

Tabela 2 – Contagem de pontos de função das features específicas encontradas nos website do estudo experimental

Para calcular a relação de reusabilidade para os três websites, foi realizada a soma dos pontos de função das features genéricas, isto é, aquelas que estão presentes no modelo genérico; e o resultado obtido foi divido pela soma dos pontos de função das features genéricas com os pontos de função das features específicas. A Tabela 3 apresenta os resultados obtidos.

Total de pontos genéricos

Total de pontos específicos

Pontos genéricos + pontos específicos

Relação

Website 1

88

25

113

77,9%

Website 2

67

23

90

74,4%

Website 3

88

0

88

100%

Website

Tabela 3 – Resultado do experimento: cálculo da relação de reusabilidade para cada website

A relação de reusabilidade expressa no resultado do experimento permite averiguar o quanto será reutilizado das features genéricas. Esse número pode servir como indicadores para:

38



O quanto será reutilizado, em termos de features; o website 3, por exemplo, seria composto 100% da artefatos reutilizados da WPPL;



O quanto será o esforço de implementação do produto; o website 1 possui uma relação de 77,9%; o que significa que 22,1% são features apenas que serão implementadas por completo, sem nenhuma reutilização da WPPL; as implementações de features por completo exigem um esforço maios do que reutilizá-las;



Decidir se o produto deve ser incluído na linha de produtos; por exemplo, um número próximo de 0% indica que o produto não deveria ser incluído.

39

CONCLUSÃO

A indústria de Marketing Digital utiliza o CMS Wordpress para aplicar eficiência na geração de websites de conteúdo dinâmico. Entretanto, a medida que as organizações crescem a demanda por projetos aumenta e são necessário mecanismos que auxiliem o processo de geração desses websites. No contexto de Engenharia de Software, o reuso é um processo fundamental para agilizar a construção de aplicações, uma vez que existe a repetição volumosa de código fonte. Além disso, procura-se reutilizar não apenas código fonte, mas os processos de construção de softwares. Por causa disso, a indústria de software buscou práticas eficientes de reuso, como é o caso da LPS. Essa prática de reuso tem sido aplicada em diversos domínios e áreas da Engenharia e Computação. Por isso, o foco desse trabalho foi buscar a utilização dessa prática para ajudar o processo de criação de websites Wordpress. A modelagem de features é uma atividade que se faz relevante para compreender o que se espera da LPS. Consequentemente, esse trabalho contribuiu com o processo de extração, identificação e classificação de features de websites Wordpress com objetivo de modelar e definir o escopo da WPPL. Um experimento foi realizado com o objetivo de medir o grau de reusabilidade em termos de features de produtos que seriam hipoteticamente implementados na WPPL. Os resultados do experimento mostraram que, em termos de features, o modelo foi eficaz para a identificação de variabilidades para

40

os produtos que seriam implementados e gerou alguns indicadores para os produtos a serem incluídos no escopo da WPPL. É importante ressaltar que o trabalho focou na identificação de features relacionadas apenas ao tema ou plug-in de Wordpress, e não nas features já oferecidas pelo CMS Wordpress. A relação entre este tipo de feature poderá ser analisada em trabalhos futuros.

41

REFERÊNCIAS BIBLIOGRÁFICAS

BOIKO, B. Content Management Bible. 2ª. ed. [S.l.]: Wiley, 2004. CASTELLUCCIO, M. The Wordpress dinasty. Strategic Finance, v. 95, n. 3, p. 59-60, September 2013. CZARNECKI, K.; EISENECKER, U. W. Generative programming: methods, tools, and applications. New York: ACM Press/Addison-Wesley Publishing, 2000. GOMAA, H. Software modeling and design: UML, use cases, patterns, and software architectures. 1ª. ed. Fairfax, Virginia: Cambridge University Press, 2011. GRISS, M. L. Implementing product-line features with component reuse. Proc. 6th Internacional Conference on Software Reuse. Palo Alto, CA, USA: Springer Berlin Heidelberg. 2000. p. 137-152. HAN, Y. Digital content management: the search for a content management system. Library Hi Tech, v. 22, n. 4, p. 355 - 365, 2004. ISSN 0737-8831. HUBERMAN, B. A.; ADAMIC, L. A. Internet: Growth dynamics of the World-Wide Web. Nature, v. 401, p. 131, 1999. ISSN 6749. JONES, K. M. L.; FARRINGTON, P.-A. Wordpress as Library CMS. American libraries, n. Maio/Junho 2011, p. 34, Maio 2011. ISSN 0002-9769. KANG, W. B. F. A. K. Software Reuse Research: Status and Future. IEEE Transactions of Software Engineering, v. 31, n. 7, p. 529-536, July 2005. KRUEGER, C. W. New Methods In Software Product Line Communications of the ACM, v. 49, n. 12, p. 37-40, 2006.

Practise.

LARMAN, C.; BASILI, V. R. Iterative and Incremental Development: A Brief History. IEEE Software, p. 2-11, June 2003. ISSN 0018-9162/03. LAZILHA, F. R. Uma Proposta de Arquitetura de Linha de Produtos para Sistemas de Gerenciamento de Workflow. Universidade Federal do Rio Grande do Sul. Porto Alegre, p. 119 f. 2002.

42

MCGREGOR, J. D. et al. Initiating Software Product Lines. IEEE Software, v. 19, n. 4, p. 24-27, July/August 2002. ISSN 0740-7459. MCKEEVER, S. Understanding Web content management systems: evolution, lifecycle and market. Industrial Management & Data Systems, v. 103, n. 9, p. 686-692, 2003. ISSN 0263-5577. MULLENWEG, M. Codex, pt-br: Wordpress. Wordpress.org, 2014. Disponivel em: . Acesso em: 16 Abril 2014. NORTHOP, L. M.; CLEMENTS, P. C. Software Product Lines: Practices and Patterns. [S.l.]: Addison Wesley Professional, 2002. REINEHR, S. D. S. Reuso sistematizado de software e linhas de produto de software no setor financeiro: estudos de caso no Brasil. Escola Politécnica da Universidade de São Paulo. São Paulo, p. 310. 2008. SEI. Software Product Lines Framework. Software Engineering Institute, 2012. Disponivel em: . Acesso em: 08 mar. 2014. SOMMERVILLE, I. Engenharia de Software. 9ª. ed. São Paulo: Pearson Prentice Hall, 2011. ŠTUIKYS, V.; DAMAŠEVICIUS, R. Development of Generative Learning Objects Using Features Diagram and Generative Techniques. Informatics in Education, v. 7, n. 2, p. 277-288, May 2008. TRIAS, F. Building CMS-based Web applications using a model-driven approach. 2012 Sixth International Conference on Research Challenges in Information Science (RCIS). Valencia: [s.n.]. 2012. p. 1-6.