• Nenhum resultado encontrado

Linhas de Produto de Software

N/A
N/A
Protected

Academic year: 2022

Share "Linhas de Produto de Software"

Copied!
5
0
0

Texto

(1)

Linhas de Produto de Software

Agnaldo de Almeida Júnior, Marcus Vinícius M. W. Santos e Paulo R. C. de Oliveira Universidade Salvador (UNIFACS)

Rua Dr. José Peroba, 251 – Salvador – BA – Brasil

Abstract. The article discusses the concepts of Software Product Lines and analyzes the application of these concepts in a software factory from the local market.

Resumo. O artigo aborda os conceitos de Linhas de Produto de Software e analisa a aplicação desses conceitos em uma fábrica de software do mercado local.

1. Introdução

Desde meados dos anos 90, com o crescimento das demandas para a produção de sistemas para as mais variadas áreas de conhecimento e de mercado, vem-se implementando a idéia de se utilizar um processo fabril no desenvolvimento de software, tentando-se trazer para a construção de sistemas, metodologias moldadas em preceitos como o taylorismo e o fordismo. Junto com essa tendência produtiva, cresce também o conceito de Linhas de Produto de Software (LPS), que traz para as fábricas de software, metodologias para agilizar o processo produtivo com a reutilização de componentes, requisitos, projetos e conhecimentos, fazendo-se valer de experiências bem sucedidas em projetos anteriores, através do reuso de recursos que sejam comuns aos sistemas, aumentando-se a eficácia do processo, explorando- se as similaridades e controlando-se as variabilidades entre os projetos.

2. Objetivo

O objetivo deste trabalho é verificar a aplicação dos conceitos de Linha de Produto de Software no processo produtivo das fábricas de software no mercado atual, focando nos possíveis ganhos a médio e longo prazo de sua utilização, assim como nas dificuldades encontradas para a sua implantação. A partir do cenário de uma fábrica de software do mercado local, mostra-se o quanto do conceito LPS pode ser aproveitado pela mesma, as ferramentas utilizadas no processo de produção de software, os casos de sucesso e o que não foi possível ser aplicado dentro do contexto da organização.

3. Fundamentos

Uma Linha de Produto de Software é um conjunto de produtos de software com alto grau de similaridade entre si, que atendem às necessidades específicas de um segmento de mercado ou missão, e que são desenvolvidos de forma prescritiva a partir de um conjunto de artefatos básicos [1].

De acordo com Clements e Northrop [1], a Linha de Produto de Software permite que a organização ganhe vantagem competitiva devido ao aumento da produtividade em larga escala, aumento da qualidade, redução dos custos, redução do tempo de entrega e minimização dos riscos dos produtos.

Contudo, iniciar uma linha de produtos de software é uma decisão de negócio que não pode ser feita aleatoriamente. Antes de começar a desenvolver uma linha de produto, a organização deve estabelecer objetivos sólidos e específicos para adotar essa estratégia de reuso. Uma linha de produtos de software requer um investimento inicial, como também custos progressivos com a manutenção dos ativos base (core assets). Inicialmente, os custos da linha de produtos são um pouco maiores que os

(2)

benefícios, pois, muitos dos custos estão associados com a sua implantação. Os benefícios, por outro lado, aumentam a cada entrega de produto. Uma vez a abordagem estabelecida, a produtividade da organização acelera, e então os benefícios superam os custos. Mudanças tecnológicas e em práticas organizacionais e gerenciais são barreiras para a adoção bem sucedida da linha de produtos. O sucesso da prática de linha de produtos é uma combinação cuidadosa de aprimoramento tecnológico, organizacional, do processo e dos negócios.

4. Conteúdo

• Linhas de Produto de Software

Nas Linhas de Produtos de Software (LPS) a idéia básica é o trabalho sobre um grupo de sistemas compartilhando um conjunto comum e gerenciado de funcionalidades (features) que satisfazem necessidades específicas de um segmento, desenvolvidos a partir de um aglomerado comum de artefatos base e de forma previamente planejada. Em outras palavras LPS faz uso da reusabilidade para construir sistemas com menos esforço, desde que estes pertençam a uma mesma família, ou seja, que possuam pontos em comum [2].

Artefatos reutilizáveis abrangem todos os tipos de artefatos de desenvolvimento de software, tais como modelos de requisitos, modelos de arquitetura, componentes de software e planos de teste.

• Processos de Desenvolvimento

O paradigma de linha de produtos de software é dividido em dois processos: a Engenharia de Domínio, responsável pela plataforma de reutilização que define o que é comum e o que varia na linha de produtos. A plataforma consiste em todos os tipos de artefatos de software (requisitos, design, testes, etc.) também chamados ativos base e a Engenharia de Aplicação, responsável por derivar aplicações concretas a partir da plataforma estabelecida na engenharia de domínio, explorando a variabilidade da linha de produtos e assegurando a sua correta instanciação de acordo com as necessidades específicas das aplicações finais.

• Abordagens de Construção de Linha de Produtos de Software

Segundo Chen [5], existem três abordagens principais de desenvolvimento em linha de produtos de software:

Proativa: os ativos base são desenvolvidos primeiro para futuros produtos. Aqui são considerados todos os produtos a serem gerados previamente, fazendo-se um planejamento inicial completo.

Reativa: os ativos base já existem, bem como uma versão da linha de produtos. O que acontece é a evolução desta linha, realizando-se incrementos na mesma, à medida que novos requisitos aparecem.

Extrativa: inicialmente são analisados os produtos já existentes, e como eles são estruturados, de modo a extrair as suas similaridades e variabilidades, para então poder se derivar uma versão inicial da Linha de Produtos.

• Variabilidade

O conceito de variabilidade está relacionado às possibilidades de mudar ou personalizar um sistema. No início, a quantidade de sistemas possíveis é grande, pois as restrições são mínimas. Durante a execução do projeto, na construção do sistema, as possibilidades diminuem, até que finalmente, em tempo de execução, existe

(3)

exatamente um sistema apenas. Em cada etapa do desenvolvimento, decisões de design são feitas. Cada decisão restringe o número de possíveis sistemas.

Com a abordagem de LPS, as variabilidades são modeladas na arquitetura de

referência da LPS (através da representação dos Pontos de Variabilidade e respectivos Variantes) e resolvidas antes da instalação dos produtos.

Um Ponto de Variabilidade corresponde a um aspecto de variação funcional num elemento de software base. O ponto de variabilidade define o conjunto de possíveis variantes, o mecanismo de variabilidade a se utilizar para instanciá-los e o tempo de ativação dos variantes, por exemplo: instanciação da arquitetura de software do produto, tempo de compilação e execução.

Um Variante corresponde a uma opção do conjunto de possíveis instâncias de variação que um ponto de variabilidade poderá originar. Em geral há sempre um certo grau de variabilidade difícil de manter em LPS. Reusabilidade e flexibilidade têm sido a força motriz por trás do desenvolvimento de técnicas como orientação a objetos, frameworks orientados a objeto e LPS.

• Gerenciamento de Variabilidades

Ao desenvolver uma LPS, o objetivo final é torná-la flexível o suficiente para atender às novas exigências. Os pontos de variabilidade mais importantes precisam ser identificados antecipadamente, a fim de alcançar este objetivo. Acontece que muitas vezes é bastante difícil de adaptar uma arquitetura existente para suportar um certo ponto de variabilidade.

Segundo Muhammad [6] a gestão da variabilidade consiste nas seguintes tarefas:

Identificar as Variabilidades: o objetivo deste processo não é chegar a um especificação completa da LPS, mas sim identificar a diferença entre os produtos (ou seja, onde as "coisas" tendem a variar) e quais características são compartilhadas por todos os produtos. Os Feature Models apresentam uma excelente forma de representar variabilidades; Introduzir a variabilidade no sistema: uma vez que a variabilidade foi identificada, o sistema deve ser projetado de tal forma que ela possa ser introduzida. Existe uma ampla gama de mecanismos e técnicas para esta tarefa. O mecanismo escolhido depende do nível em que a variabilidade é introduzida, o tempo que o sistema será ligado a um variante particular e a forma como novas variantes (se houver) serão adicionadas ao sistema; Agrupar as variantes: esta fase resulta em um conjunto de variantes associadas a um ponto de variabilidade. A coleção de variantes pode ser implícita ou explícita. No caso da implícita o sistema baseia-se no conhecimento dos desenvolvedores ou usuários para escolherem variantes adequadas quando assim for necessário. Uma coleção explícita, por outro lado, implica que o sistema pode, por si só, decidir qual variante usar. A coleção pode ser fechada, o que significa que nenhuma nova variante pode ser adicionada, ou ela pode permanecer aberta para novas adições; Vincular o sistema a uma variante: resulta em um sistema onde um ponto de variabilidade particular é associado a uma de suas variantes. Esta vinculação pode ser feita internamente ou externamente, a partir da perspectiva de sistemas. Uma ligação interna implica que o sistema possui a capacidade de vincular uma variante particular, ao passo que se a ligação é realizada externamente, o sistema tem que contar com outras ferramentas, como ferramentas de gerenciamento de configuração para executar a vinculação. Relacionando esta com o agrupamento de variantes, vemos que a gestão de variabilidade pode ser implícita e externa, implícita e interna, ou explícita e interna. A seleção de qual variante usar envolve escolher uma variante dentre o conjunto de variantes.

• Feature Model

A similaridade e variabilidade entre produtos de uma linha pode ser expressa em termos de features. O conceito de feature foi originalmente apresentado pelo método

(4)

Feature Oriented Domain Analysis (FODA). De acordo com este modelo uma feature é uma característica do sistema visível ao usuário final. Uma feature é definida como uma unidade lógica de comportamento que é especificada por um conjunto de requisitos funcionais e de qualidade. Além disso, o comportamento deve ser relevante para um ou vários stakeholders de um produto [7].

O conceito de feature simplifica o trabalho com os requisitos, porque ele pode ser usado para agrupar um conjunto de requisitos relacionados. Em outras palavras, as features são uma forma de abstrair os requisitos. É importante perceber que existe uma relação n-para-n entre features e requisitos.

• Configuration Knowledge

O feature model, por si só, apenas representa a modelagem do domínio, mas não representa o modo como os produtos deste domínio serão gerados a partir dos artefatos da linha de produtos. O mapeamento entre o feature model e os artefatos de implementação é o que se chama de Configuration Knowledge [8].

Os artefatos de implementação podem estar modelados direto no modelo que representa o configuration knowledge ou em um modelo à parte. Neste caso, o configuration knowledge associará os artefatos de um modelo com as features do feature model.

• Atividades essenciais em Linha de Produtos de Software

Existem três atividades essenciais para colocar em campo uma linha de produtos:

desenvolvimento de artefatos-núcleo, desenvolvimento de produtos utilizando esses artefatos-núcleo e suporte desses desenvolvimentos pela terceira atividade:

gerenciamento técnico-organizacional [2].

5. Experiência Prática

Para este artigo, uma filial de fábrica de software foi visitada onde se realizou uma entrevista com a gerente de projeto, que procurou analisar as atividades realizadas por esta fábrica no contexto de LPS. O objetivo da entrevista era saber que conceitos estavam sendo utilizados ou prospectados dentro da fábrica, no intuito de se implantar uma LPS.

A FSW funciona como filial em Salvador, tendo mais três filiais e uma matriz no Brasil. A estrutura de cargos varia nas filiais. Existe uma gerência nacional de fábrica responsável pela gestão de recursos. Para a filial de Salvador, o quadro é composto por um gerente de unidade, um gerente de projeto, um arquiteto de software, um analista de requisitos, três programadores e um analista de testes.

A FSW trabalha com demandas regionais. No entanto, pode assumir, eventualmente, algumas demandas de outras regiões do país de acordo com cada tipo de contrato. Basicamente a fábrica trabalha com a etapa de construção do código. As demandas vêm em forma de requisitos e devem ser processadas para gerarem os artefatos das demais fases do desenvolvimento como código-fonte, diagrama de classes de implementação, pacote compilado, evidências de testes e artefatos de testes. Eventualmente, a FSW pode trabalhar com a elaboração da especificação de requisitos, mas isso não é comum. Em apenas um contrato ela constrói e mantém cinco projetos com características muito peculiares.

A FSW utiliza algumas ferramentas para o desenvolvimento das suas atividades como: Project, para gerenciamento de Projetos; SharePoint, para controle; Mantis, para reportar erros nos aplicativos gerados; SVN (Subversion), para o controle de versão; EA (Enterprise Architect), para leitura dos artefatos de requisito; Eclipse, como IDE e PGAdmin, para adminstrar o SGBD PostgreSQL.

(5)

Questionou-se quais eram as iniciativas da fábrica que estavam sendo adotadas com o intuito de economizar tempo, reduzir custo e aumentar a confiabilidade com o reuso. A princípio, a gerente da Unidade reconheceu a importância do reuso para ganho substancial na qualidade e redução de custos porém admitiu que em função da grande diversidade nos projetos mantidos, o reuso quase que inexistia. Sempre que uma nova funcionalidade em um projeto era lançada, apenas parte do código e, às vezes, quase nada, era aproveitado para aquela funcionalidade.

No início do contrato com seu cliente principal, a fábrica criou um componente de autenticação WEB que poderia ser reaproveitado em diversos projetos, no entanto, devido às exigências arquiteturais deste cliente, não foi possível utilizá-lo.

A rotatividade de pessoal colabora com a perda de conhecimento fazendo com que a fábrica tenha que treinar os novatos para se adequarem aos projetos em andamento. Para minimizar este problema, a solução encontrada é manter a sua documentação sempre consistente e atualizada.

A fábrica visitada utiliza alguns frameworks para reduzir o tempo de desenvolvimento e aumentar a produtividade, como Jaguar, Struts, Hibernate e Spring.

A exemplo do Hibernate, a fábrica admitiu que muitos projetos exigem que apenas uma fração das funcionalidades seja codificada no padrão JDBC puro, ora por ser um sistema legado, ora por ser um sistema que ainda necessite de maturidade.

6. Conclusão

Percebemos que a adoção de LPS pode trazer vários benefícios, porém envolve também muitos desafios em função do novo paradigma: reestruturação de processos, mudanças comportamentais, custos de investimento e domínio da abordagem.

No estudo de caso, observou-se que, a nível nacional, a fábrica poderia planejar melhor a elaboração de artefatos. Um banco de dados de conhecimento poderia ser implantado, mas, por razões estruturais e econômicas, isso ainda não pode ser feito.

O reuso aplicado é considerado baixo apesar de esta fábrica se utilizar de muitos frameworks consagrados no mercado. A rotatividade de pessoal, a falta de planejamento e a grande diversidade dos projetos são fatores que colaboram para este cenário.

7. Referências

[1] Clements, P. and Northrop, L. (2001). Software Product Lines: Practices and Patterns. Addison-Wesley Professional, 3rd edition.

[2] C.A. Long. Software product lines: practices and patterns [book review].

Software, IEEE.

[3] Couto, M. (2010). Extração de linhas de produtos de software: Um estudo de caso usando compilação condicional. Master’s thesis, PUC Minas.

[4] Queiroz, P. (2009). Uma abordagem de desenvolvimento de linha de produtos com uma arquitetura orientada a serviços. Master’s thesis, Universidade de São Paulo.

[5] Y Chen, G C Gannod, and J S Collofello. A software product line process simulator. Software Process: Improvement and Practice, 11(4):385–409, 2006.

[6] Muhammad Ali Babar, Lianping Chen, and Forrest Shull. Managing variability in software product lines. IEEE Software, 27:89–91, 94, 2010.

[7] Jan Bosch. Design and use of software architectures: adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 2000.

[8] Krzysztof Czarnecki and UlrichW. Eisenecker. Generative programming:

methods, tools, and applications. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 2000.

Referências

Documentos relacionados

Já o Ministério do Turismo (2010), divulga não apenas as atribuições gerais que o guia deve cumprir, mas também as atribuições específicas de acordo com a

 Forte parceria com todas as incorporadoras listadas e mais de 600 incorporadores não listados gera grandes oportunidades para a Brasil Brokers para a venda de Remanescentes;

Obtivemos as respostas listadas a seguir: Sujeito 1: “Brincar na educação infantil é muito importante para o desenvolvimento da criança que nessa fase tem o lúdico como elemento

No Quadro 14, está a representação da incompatibilidade número 10 onde na modelagem BIM, conforme o projeto estrutural, a passagem da eletrocalha foi projetada a 2,97m

Neste sentido, o nosso trabalho foi realizado em dois momentos: o Campo de Observação com 20 horas semanais e Campo de Docência com 20 horas semanais, encontros significativos

A forma em que as empresas do arranjo do segmento cama-mesa-banho estão inseridas no mercado externo pode ser enquadrada em relações de redes de empresas, nas

Nesta temática, diversos instrumentos têm sido desenvolvidos para avaliar a imagem corporal infantil dentre eles, destaca-se a Children’s Figure Rating Scale

(a) uma das formas para compatibilizar direitos consagrados na Constituição Federal de 1988 diretamente relacionados com a dignidade da pessoa humana – como o respeito à vida privada