linhas de produto de software

Avaliação de Qualidade deLinha de Produto de Software

baseada em Arquitetura e Métricas

Prof. Dr. Edson A. Oliveira Junior

Universidade Estadual de Maringá (UEM)Departamento de Informática (DIN)

[email protected]

Avaliação de Qualidade de Linha de Produto de Software – SBQS 2011 2

Palestrante Edson A. Oliveira Junior

Vínculo Institucional: Prof. Adjunto do Departamento de Informática (DIN) da UEM

Contato: [email protected] ou www.edsonjr.pro.br

Formação Acadêmica: Bacharel em Informática (2003) – UEM Mestre em Ciência da Computação (2005) – UEM Doutor em Ciências de Computação e Matemática Computacional (2010)

– USP Visiting Scholar na University of Waterloo, Canadá (2009)

Área de Pesquisa: Engenharia de Software:

Desenvolvimento baseado em Componentes e Frameworks Linha de Produto de Software Engenharia de Software Experimental Modelagem UML e Metamodelos Cloud Computing Sistemas Embarcados Críticos


Agenda do Mini-curso Contextualização

Linha de Produto de Software (LPS) Definições Desenvolvimento de LPS Gerenciamento de variabilidades

Avaliação de LPS Definições e tipos de avaliação Principais abordagens de avaliação de LPS Métodos relacionados à avaliação de LPS

Exemplo de Avaliação de LPS Apresentação Objetivos Técnicas possíveis e métodos de análise Definição de artefatos Planejamento Execução Análise de dados e documentação

Considerações Finais


Contextualização

Desenvolvimento tradicional de software: um processo/método é realizado gerando um único

produto de software Ex. Unified Process

Todo o ciclo de vida se repete para um novo produto de software: Ex. Elaboração, Concepção, etc

Complexidade dos sistemas de software vem aumentando a cada ano consequências: Número maior de horas de trabalho Número maior de equipes de desenvolvimento Re-trabalho Cronogramas mais extensos Aumento do time to market Maior risco e maior custo Pode provocar baixa reusabilidade Insatisfação do(s) cliente(s)


Contextualização

Engenharia de domínio:

Dá suporte ao desenvolvimento de software

Permite identificar os requisitos comuns a um determinado domínio. Ex. de domínio? de requisitos?

Permite identificar variações em requisitos de um mesmo domínio. Exemplos?

Exige maior esforço (horas + pessoas) e conhecimento do domínio em questão

Adia decisões de projeto de acordo com o domínio

Aumenta a possibilidade de reutilização para produtos do mesmo domínio!?!? O que vocês acham? PQ?


Contextualização

Como é possível: aumentar a resusabilidade diminuir esforço de produção diminuir o tempo que o produto leva para chegar ao

mercado aumentar a qualidade do software diminuir custos e aumentar o lucro

Resp.: Equacionando…

Engenharia de Domínio + Desenvolvimento Tradicional

+ Outras técnicas = n produtos = Linha de Produto de Software (LPS)


Contextualização

Avaliação de Qualidade de software

Como saber se um produto de software tem a qualidade mínima necessária?

Quais técnicas podem ser aplicadas para verificar se um produto de software tem qualidade?

Qualidade e Desenvolvimento Tradicional

É possível verificar a qualidade de cada produto durante e após o seu desenvolvimento

Qualidade e LPS

Como saber se uma LPS tem a qualidade exigida? Verifica-se produto por produto ou a LPS como um todo?

Quais técnicas podem ser aplicadas?

Linha de Produto de Software (LPS)



Não é um assunto “novo”

Desenvolvimento customizado: Ideia de Henry Ford Produção de carros com equipamentos

customizados (adicionais, acessórios)

Linhas de produção e montagem

Produtos com características: Comuns Variáveis


Linha de Produção de H. FordFord T. (EUA) 1903


Linha de Produção de H. FordFord de Bigode (Brasil) 1908 (US$850) – 1927 (US$290)

Características:

- Pintura: “qualquer cor, desde

que seja preta” (H. Ford)

- Bancos: veludo, tecido, couro

- Carroceria: Pickup, Camionete,

Cupês e Sedãs

- Painel: Amperímetro e Odômetro

- Opcionais: Faróis, Buzina


Linha de Produção de H. FordLinha completa do Ford T.

5 PassageirosCarro de Passeio

Totalmente Equipado3 Passageiros

Totalmente Equipado2 PassageirosConversível

Totalmente Equipado

2 Passageiros3 Lâmpadas de ÓleoKit de Ferramentas

2 PassageirosEstio Torpedo

Totalmente Equipado

6 Passageiros3 Lâmpadas de ÓleoKit de Ferramentas


Linha de Produção

Hoje encontramos linhas de produção para: Carros Produtos alimentícios (MacDonalds, Burger

King, Pizza Hut...) Relógios Computadores (iMac, Vaio, Pavilion...) Impressoras SmartPhones Aviões Mais alguma??

- Características Comuns e Variadas

- Possibilidade de Customização

- Desenvolvimento em Série


Objetivo de LPS

Resumidamente, LPS visa estabelecer uma capacidade de produção que possa:

Rapidamente, e de forma correta, produzir múltiplos produtos com base em um contexto bem definido

Alcançar metas de negócio específicas que podem ser afetadas pela forma como uma organização produz seus produtos


Alguns Número Reais sobre LPS

Melhoria de Produtividade: ~10x

Aumento de Qualidade: ~10x

Redução de Custos: até 60%

Redução de mão de obra: até 87%

Redução do time to market: até 98%


Casos de Sucesso de LPS

Segundo o Hall of Fame do SEI:

Overwatch Textron Systems

Nokia

Philips Medical



Definições de LPS:

Termos importantes e sinônimos:

Característica (feature) Características comuns similaridades Segmento de mercado particular domínio Customização em massa desenvolvimento em série

“conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades específicas de um segmento de mercado particular ou missão, desenvolvidas a partir de ativos centrais comuns de maneira prescritiva”

“paradigma para desenvolver aplicações de software usando customização em massa e de plataforma”



Sinônimos de LPS: Linha de Produção (production line) Família de Produtos (product family) Família de Produção (production family)

Sinônimo para Produto: Membro da família (family member) Configuração de LPS

Sinônimos para Ativos Centrais (core assets): Plataforma (platform) Núcleo de Artefatos Infraestrutura central (infrastructure)



LPS constitui uma forma prática de: Aumentar a reutilização Diminuir o time to market Reduzir custos e esforço de desenvolvimento Melhor qualidade por conta da reutilização

Reutilização de software: Subrotinas (anos 60) Módulos (anos 70) Objetos (anos 80) Componentes (anos 90) LPS (2000 em diante)



Custo e Esforço de Desenvolvimento



Redução do time to market


Outros Benefícios de LPS

Redução do esforço de manutenção

Estimativa mais precisa de custos

Retorno de investimento após a produção de poucos produtos

Contribui para a evolução da linha

Reduz a complexidade inerente

Cliente recebe produtos adaptados às suas necessidades


Características (Features)

Conceito tem origem na Eng. de Domínio

“...capacidade do sistema que é relevante e visível para o usuário final...”

Podem ser: Obrigatórias Alternativas (1..n) Opcionais (0..1)


Modelo de Características

Representa a organização das características de forma hierárquica

Permite a identificação das primeiras variabilidades de uma LPS

Várias notações propostas


Exemplo de Modelo de Caract. (1)



Media Management

Mobile Media

Delete Media

Create Media

View Photo

Copy Media

SMS Transfer

Send Media

ReceiveMedia

SortingFavouritesBasic Media Operations

View Favourites

Edit Media Label

Media Selection

Photo Music Video

Play Music Play Video

Album Management

Create Album

Delete Album


Desenvolvimento de LPS

Etapas principais:

Engenharia de domínio: Desenvolvimento de ativos centrais

Engenharia de aplicação: Desenvolvimento do produto

Gerenciamento: Técnico e Organizacional


Desenvolvimento de LPSModelo Product Line Practice – PLP (SEI)

Engenharia de Domínio

Engenharia de

Aplicação

Técnico e Organizacional


Engenharia de DomínioModelo Product Line Practice – PLP (SEI)


Engenharia de AplicaçãoModelo Product Line Practice – PLP (SEI)


Abordagens de Desenvolvimento de LPS

Pró-Ativa: Análise prévia dos possíveis produtos a partir das

características estabelecidas Desenvolve-se uma LPS “do início”

Extrativa: LPS desenvolvida a partir de produtos existentes As características para uma LPS são extraídas dos

produtos existentes Tem-se a primeira release da LPS

Reativa: Desenvolvimento baseado em evolução da LPS Ex.: Novas características são adicionadas


Principais Metodologias de LPS

Feature-Oriented Development Analysis (FODA)

Product Line Practice (PLP)

Feature-Oriented Reuse Method (FORM)

Family-Oriented Abstraction, Specification and Translation (FAST)

Product Line UML-based Software Engineering (PLUS)

Método de Klauss Pohl (2005)


Gerenciamento de Variabilidades

Variabilidade é:

“... a forma como os membros de uma família de produtos podem se diferenciar entre si...”

descrita por:

pontos de variação – local específico em que uma decisão de projeto foi adiada

variantes – alternativas de projeto para instanciar uma determinada variabilidade

A representação explícita de variabilidade

Torna possível a geração de produtos específicos de uma LPS


Gerenciamento de Variabilidades

O gerenciamento de variabilidades está diretamente relacionado

a todas as atividades de desenvolvimento de LPS

Principais atividades: Identificação de variabilidades

Delimitação de variabilidades (multiplicidade e tempo de resolução)

Rastreamento e Controle de variabilidades

Identificação de Mecanismos de Implementação

Análise e Configuração de Produtos


Principais Abordagens de Gerenciamento de Variabilidades

Morisio et al. (2000): Estereótipos <<V>> e <<xorV>> em classes

Clauss (2001): Adiciona 2 estereótipos <<inclusive>> e <<exclusive>> em classes à

abordagem de Morisio

Gomaa (2005): Representação de variabilidade em casos de uso, classes e colaborações

Korherr e List (2007): Perfil UML para classes e diagramas de atividades

SMarty (2010): Perfil UML (SMartyProfile) para casos de uso, classes e componentes Processo (SMartyProcess) e diretrizes para realizar as atividades de

gerenciamento e aplicar o perfil UML

Outras abordagens não-UML Notações particulares, não padronizadas, mas importantes


Representação de Variabilidades com SMartyProfile


Gerenciamento de Variabilidades com SMartyProcess


Representação de Variabilidades com SMarty

Avaliação de LPS


Definições Avaliar:

Elaborar um juizo de valor, qualitativo ou quantitativo, sobre uma ação

Estimar, aquilatar, aferir, apreciar

Avaliação: Ato de avaliar, apreciação, estimativa

Avaliador: Que avalia, apreciador

Evaluation: To determine the value of; to assess

Assessment: The act of determining an amount to be paid; an

official evaluation of property, or income, for the purpose of taxation


Avaliação de LPS

Aspectos a considerar:

[Arquitetura da LPS / Arquiteturas dos Produtos] + Atributos de qualidade

Momento em que a(s) Arquitetura(s) é(são) avaliada(s)

Técnicas qualitativas e/ou quantitativas a serem adotadas ou propostas


Avaliação de LPS

Momento de Avaliar Arquitetura(s):

Antes da concepção da Arquitetura da LPS (Existing PA)

Durante a Eng. Domínio

Durante a Evolução da Arquitetura de LPS (Evolution

Related PLA)

Durante a Instanciação dos Produtos (During Derivation)

Durante a Eng. Aplicação

Durante a Evolução da Arquitetura dos Produtos (Evolution

Related PA)


Avaliação de LPS


Avaliação de LPS

Técnicas Quantitativas:

Elaboração de Cenários

Questionários

Checklists

Técnicas Quantitativas:

Simulação

Prototipagem

Modelos Matemáticos e Experimentais

Métricas


Avaliação de LPS

Panorama de Avaliação de LPS: Avaliação de Atributos de Qualidade de Arquitetura

de LPS Cenários, GQM, ATAM, SAAM, ADL, Casos de Uso

Avaliação Estrutural de Arquitetura de LPS Métricas: tempo de resposta entre componentes, latência,

utilização de CPU, tempo de execução, structural soundness (utilização de serviços de componentes individuais e da arquitetura)

Definição e Avaliação de Contexto de LPS: Análise de riscos e benefícios, adoção de LP, melhoria no

processo de desenvolvimento, manutenção de LP, modelos de custos e estimativas, análise de domínios candidatos


Avaliação de LPS

Neste mini-curso focaremos a avaliação de LPS:

qualitativa e quantitativa

por meio de sua arquitetura

com a aplicação de métricas para apoiar

análises de trade-off de atributos de

qualidade

Considerando os potenciais produtos da LPS


Avaliação de LPS

Avaliação de Arquitetura de LPS deve garantir que a arquitetura seja flexível o suficiente para

suportar diferentes produtos e permitir a sua evolução

Em LPS temos 2 níveis de abstração arquitetural: Arquitetura da LPS Arquitetura de todos os produtos da LPS

Avaliar a arquitetura de todos os possíveis produtos de

uma LPS não é viável Porém, é possível avaliar uma amostra significativa dos

produtos com relação à arquitetura de LPS


Avaliação de LPS Métodos de Avaliação de Arquitetura de LPs

Durante a Eng. De Domínio:

Family Architecture Assessment Method (FAAM)

Arquiteturas de LPS para de sistemas de informação

Architecture Quality Analysis (AQA)

Análise Qualitativa de Arquitetura de LPS

Reliability Evaluation of Domain Architectures (REDA)

Distributed SAAM (D-SAAM)

Variação do SAAM para arquiteturas de referência


Avaliação de LPS Métodos de Avaliação de Arquitetura de LPs

Arquiteturas de LPS Existentes:

Abordagem de Gannod e Lutz: Avaliação de requisitos funcionais e de qualidade

Abordagem de Maccari Avaliar evolução

Abordagem de Riva e Rosso Adaptação da abordagem de Maccari

Avaliação Específica de Variabilidade:

Scenario-based Architecting (SBA) Quantifica potenciais benefícios de diferentes opções de

arquiteturas com relação às variabilidades


Avaliação de LPS

Métodos tradicionais de avaliação de

arquitetura de software vem sendo usados para

avaliar arquiteturas de LPS:

Architecture Tradeoff Analysis Method (ATAM)

Realiza análises de trade-off para priorizar atributos de

qualidade e fornecer uma visão comportamental da

arquitetura

Software Architecture Analysis Method (SAAM)

Compara duas ou mais arquiteturas de software com

relação a alguns critérios pré-estabelecidos


Avaliação de LPSO Método ATAM

Revelar como uma arquitetura de software satisfaz

os seus atributos de qualidade

Identificar como atributos de qualidade interagem

entre si

Pode ser aplicado em estágios iniciais de

desenvolvimento

Pode ser aplicado em sistemas legados e sistemas

em evolução



Decisões arquiteturais dependem de alcançar

ou não os atributos de qualidade

Para tanto, é necessário estabelecer previamente os

atributos de qualidade, que são motivados pelas metas de

negócio (business drivers ou business goals)

As metas de negócio...

... representam os objetivos de negócio que uma

arquitetura de software deve atingir, com base nos

seus atributos de qualidade.



Etapas do Método ATAM:

1. Apresentação do método ATAM

2. Apresentação das metas de negócio

3. Apresentação da arquitetura

4. Identificação das abordagens arquiteturais

5. Geração da árvore de utilidade dos A.Q.

6. Análise das abordagens arquiteturais (Fase 1)

7. Brainstorming e priorização de cenários

8. Análise das abordagens arquiteturais (Fase 2)

9. Apresentação dos resultados



Árvore de utilidade (utility tree)

Relacionam as metas de negócios aos atributos de qualidade por meio de cenários.

Cenários (scenarios)

Descreve brevemente a interação de um stakeholder com o sistema.

Stakeholders

Um indivíduo, equipe ou organização com interesse ou relacionado a um sistema.



Benefícios possíveis:

Financeiro – economia de $$$

Preparação, documentação e entendimento do sistema

Captura do Rationale

Identificar erros arquiteturais antes da construção do

sistema

Garante que a arquitetura satisfaz os cenários, A.Q. e

metas de negócio estabelecidas

Torna a arquitetura mais flexível e geral

Reduz riscos


Avaliação de LPSExtensões do ATAM para Arq. de LPS

Extended ATAM (EATAM)

Baseia-se em 4 etapas:

1. Identifica os 4 A.Q. comuns à uma arquitetura de LPS:

modificabilidade, portabilidade, escalabilidade e

extensibilidade

2. Descobre as visões arquiteturais com base nos 4 A.Q.

3. Marca pontos de variação nos A.Q. com tags

4. Repete as etapas do ATAM para validar as arq. dos produtos

Duas fases:

Avaliação da arquitetura de LPS

Avaliação das arquiteturas dos produtos



Holistic Product Line Software Architecture

Assessment (HoPLSAA)

Cobre avaliação de arquitetura de LPS e dos produtos

Assim como o EATAM, possui 2 estágios:

Análise da arquitetura de LPS

Análise das arquiteturas dos produtos

Focada em metas de negócio, contexto da LPS,

similaridades e variabilidades para estabelecer

cenários



Holistic Product Line Software Architecture Assessment (HoPLSAA)


Avaliação de LPS

Resumindo:

Existem várias abordagens...

Existem várias técnicas...

Existem vários momentos de avaliação...

Existem vários conceitos envolvidos...

Existem vários “exemplos” na literatura...

Existem muitos “silver bullets”...

Enfim, como avaliar uma LPS com

relação à arquitetura?


Avaliação de LPS Resposta:

Não existe uma “receita de bolo”...

Faz-se necessário:

1. Definir o que se espera da avaliação (FINS): Quais (tipos de) resultados queremos? Quais ativos se quer como saída?

2.1 Analisar os recursos disponíveis: Quais stakeholders participarão? Quais ativos serão usados?

2.2 Definir como chegar aos resultados (MEIOS): Quais abordagens/técnicas serão

consideradas/adaptadas/estendidas/propostas? Como os stakeholders participarão? Como os ativos serão usados?

Exemplo de Avaliação de LPS


Exemplo de Avaliação de LPS Será avaliada a LPS Arcade Game Maker (AGM):

LPS de jogos do tipo arcade para dispositivos móveis:

Brickles, Pong e Bowling (~80 variações)

Desenvolvida pelo Software Engineering Institute

(SEI)

LPS pedagógica para o ensino de conceitos de LPS e

experimentação

Fornece documentação completa e código fonte dos

ativos centrais e dos jogos

Variabilidades representadas com UML (SMarty)


Exemplo de Avaliação de LPS


Brickles


Pong


Bowling


Arcade Game Maker (AGM)Modelo de Características

Modelo de Características:

Composto por 4 características principais:

services: define os serviços play, pause e save;

rules: define regras seguidas pelos jogos;

action: ações necessárias para movimentação e

colisões; e

configuration: configurações básicas dos

ambientes e dos jogos.


Arcade Game Maker (AGM)Modelo de Características


Arcade Game Maker (AGM)Modelo de Casos de Uso

Atores: GamePlayer GameInstaller

Casos de Uso: Play Selected Game Play Bowling, Play Brickles e Play Pong Install Game Uninstall Game Save Game Save Score Check Previous Best Score Exit Game Animation Loop Initialization


Arcade Game Maker (AGM)Modelo de Casos de Uso com Variabilidades


Arcade Game Maker (AGM)Classes – Ativos Centrais


Arcade Game Maker (AGM)Classes – Bowling


Arcade Game Maker (AGM)Classes – Brickles


Arcade Game Maker (AGM)Classes – Pong


Arcade Game Maker (AGM)Modelo de Classes com Variabilidades


Arcade Game Maker (AGM)Arquitetura

Formada por vários componentes:

Game

DBClient

Operating System

DisplayDriver

MouseDriver

SoundDriver

KeyBoardDriver

Somente o componente Game é formado por

classes com variabilidades identificadas


Arcade Game Maker (AGM)Arquitetura (Visão Lógica)


Descrição da Avaliação

Deseja-se avaliar a arquitetura da LPS AGM:

com base nos seus potenciais produtos

verificando se as metas de negócio estabelecidas são

satisfeitas

por meio de análises de trade-off sobre os A.Q.

gerando resultados qualitativos e quantitativos

para que possam ser usados como parâmetro

para avaliar a LPS como um todo

Avaliação apoiada por:

ATAM, EATAM e HoPLSAA


Estratégia de Avaliação

Etapa 1: Planejamento

Definir/alocar artefatos que serão usados na avaliação

Atributos de qualidade, metas de negócio, cenários, questões a

serem respondidas e métricas

Etapa 2: Coleta de Dados

Gerar configurações de da arquitetura Coletar dados e métricas sobre as configurações

Etapa 3: Análise de Dados e Documentação

Analisar os dados coletados quantitativa e qualitativamente Documentar a avaliação


Estratégia de Avaliação


Planejamento:definição de artefatos

Entradas:

-Modelos da AGM

-Atributos de Qualidade:

- Complexidade

- Extensibilidade

Saídas:

- Metas de Negócio

- Cenários

- Questões Gerenciais e Técnicas

- Métricas (Básicas e de A.Q.)


Definindo as Metas de Negócio

Meta de Negócio

Os jogos produzidos, em sua maioria, devem apresentar baixas taxas de complexidade, assim como altas taxas de extensibilidade.


Definindo as Metas de Negócio

Meta de Negócio (MN.1)Complexidade

Manter o grau de complexidade dos jogos abaixo de 0.7(70%), comparado a complexidade geral da ALP, para, pelo menos, 50% dos produtos produzidos.

Meta de Negócio (MN.2)Extensibilidade

Manter o grau de extensibilidade dos jogos acima de 0.75(75%), comparado a extensibilidade geral da ALP, para, pelo menos, 50% dos produtos produzidos.


Definindo os Cenários (Complexidade)


Definindo os Cenários (Extensibilidade)


Classificando os Cenários


Selecionando Atributos de Qualidade


Definindo as Questões Técnicas e Gerenciais


Definindo as Métricas para os A.Q.


Modelo GQM para a AGM


Gerando as Configurações AGM e Aplicando as Métricas


Realizando Análises de Trade-Off

Considerar as métricas coletadas

Analisar as estatísticas descritivas de

cada métrica

Priorizar atributos de qualidade


Análise da Estatística DescritivaComplexidade

Análise Nro. 1: 15 configurações (50%) possuem valores de

CompPLA menores ou iguais a 0,5895

15 configurações (50%) possuem valores de

CompPLA maiores que 0,5895

Questões:

A MN.1 foi satisfeita?

Devemos priorizar complexidade em vez de

extensibilidade?


Análise da Estatística DescritivaExtensibilidade

Análise Nro. 2: 15 configurações (50%) possuem valores de

ExtensPLA menores ou iguais a 0,7060

15 configurações (50%) possuem valores de

ExtensPLA maiores que 0,7060

Questões:

A MN.2 foi satisfeita?

Devemos priorizar extensibilidade em vez de

complexidade?


Conclusão Nro. 1

Não é possível dizer, com base na análise das

estatísticas descritivas, qual A.Q. priorizar

O que fazer então? Considerar ambos os A.Q.

para o desenvolvimento e evolução da AGM?

Alternativa:

1. Analisar os produtos individualmente

2. Identificar quais produtos são mais interessantes

para a AGM CompPLA < 0,7 e ExtensPLA > 0,75

3. Definir qual A.Q. priorizar


Analisando os Produtos

Os 3 produtos mais interessantes: Configuração 3:

CompPLA = 0,50 ExtensPLa = 0,81

Configuração 9: CompPLA = 0,67 ExtensPLa = 0,80

Configuração 25: CompPLA = 0,62 ExtensPLa = 0,80

ExtensPLA = ~0,80

0,50 <= CompPLA <= 0,67

Priorizar

Complexidade


Considerações sobre a Avaliação

Com a avaliação da Arquitetura da AGM foi possível:

Prever o comportamento de seus produtos

Estimar complexidade e extensibilidade

Identificar quais produtos devem ser desenvolvidos

Mostrar empiricamente que a arquitetura atende às metas de

negócio estabelecidas

Preparar um ambiente para que futuras avaliações possam ser

realizadas/replicadas

É possível ainda com os resultados da avaliação:

gerar versões diferentes da arquitetura da AGM e compará-las

aplicar um modelo de custos e estimativas de LPS, tendo como parâmetros:

A.Q. priorizados [Complexidade] x metas de negócio, potenciais produtos, código

fonte, métricas

Considerações Finais


Considerações Finais Neste mini-curso foram apresentados:

conceitos de LPS e Avaliação de LPS um exemplo de como avaliar uma LPS com base em

arquitetura e métricas

Existem várias abordagens e técnicas para

avaliação de LPS a maioria permite somente análises qualitativas

A aplicação de métricas para A.Q. é importante

para prever o comportamento dos produtos: porém exigem validação teórica e empírica devem ser compartilhadas em um repositório


Considerações Finais Análises de Trade-Off contribuem para:

definir quais A.Q. podem ser considerados como parâmetros para adoção de um modelo de custos de estimativas de LPS

Estimar os produtos mais interessantes para uma LPS Economizar recursos no desenvolvimento e evolução

de LPS

Avaliação de LPS em geral: Atividade complexa Exige vários recursos Se bem planejada, se torna menos complexa a cada

iteração/replicação Se mal planejada, só desperdiça tempo e $$$ Justifica o Retorno de Investimento (ROI) esperado


Referências Barbacci, M. R.; Clements, P.; Lattanze, A.; Northrop, L.; Wood, W. Using

the Architecture Tradeo_ Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionic Systems: a Case Study. Relatório Técnico CMU/SEI-2003-TN-012, Software Engineering Institute (SEI), Pittsburgh, USA, 2003.

Batory, D.; Johnson, C.; MacDonald, B.; Heeder, D. Achieving Extensibility Through Product-Lines and Domain-Specific Languages: a Case Study. ACM Transactions on Software Engineering Methodologies, v. 11, n. 2, p. 191-214, 2002.

Böckle, G.; Clements, P.; McGregor, J. D.; Muthig, D.; Schmid, K. Calculating ROI for Software Product Lines. IEEE Software, v. 21, n. 3, p. 23-31, 2004.

Briand, L.; Emam, K. E.; Morasca, S.; El, K.; Morasca, E. S. Theoretical and Empirical Validation of Software Product Measures. ISERN-95-03, International Software Engineering Research Network, 1995.

Brooks, A.; Daly, J.; Miller, J.; Roper, M.; Wood, M. Replication of Experimental Results in Software Engineering. Relatório Técnico ISERN-96-10, International Software Engineering Research Network, Germany, 1996.


Referências Chastek, G.; Ferguson, R. Toward Measures for Software Architectures.

SEI Technical Note CMU/SEI-2006-TN-013, Software Engineering Institute (SEI), Pittsburgh, USA, 2006.

Chen, L.; Babar, M. A.; Ali, N. Variability Management in Software Product Lines: a Systematic Review. In: Proceedings of the Software Product Line Conference, Pittsburgh, PA, USA: Carnegie Mellon University, 2009, p. 81-90.

Clements, P.; Kazman, R.; Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002b.

Clements, P.; Northrop, L. Software Product Lines: Practices and Patterns. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001.

Corder, G. W.; Foreman, D. I. Nonparametric Statistics for Non-Statisticians: A Step-by-Step Approach. Boston, MA, USA: Wiley, 2009.

Deelstra, S.; Sinnema, M.; Bosch, J. Variability Assessment in Software Product Families. Information and Software Technology, v. 51, n. 1, p. 195-218, 2009.


Referências Dincel, E.; Medvidovic, N.; Hoek, A. v. d. Measuring Product Line

Architectures. In: Proceedings of the International Workshop on Product Family Engineering, London, UK: Springer-Verlag, 2001, p. 346-352.

Dobrica, L.; Niemelä, E. A Survey on Software Architecture Analysis Methods. IEEE Transactions on Software Engineering, v. 28, n. 7, p. 638-653, 2002.

Dolan, T.; Weterings, R.; Wortmann, J. C. Stakeholder-Centric Assessment of Product Family Architecture. In: Proceedings of the International Workshop on Software Architectures for Product Families, London, UK: Springer-Verlag, 2000, p. 225-245.

Eskenazi, E. M.; Fioukov, A. V.; Hammer, D. K.; Obbink, H.; Pronk, B. Analysis and Prediction of Performance for Evolving Architectures. In: Proceedings of the EUROMICRO Conference, Washington, DC, USA: IEEE Computer Society, 2004, p. 22-31.

Etxeberria, L.; Sagardui, G. Product-Line Architecture: New Issues for Evaluation. In: Proceedings of the Software Product Line Conference, Berlin, Germany: Springer-Verlag, 2005, p. 174-185.


Referências Etxeberria, L.; Sagardui, G. Evaluation of Quality Attribute Variability in

Software Product Families. In: Proceedings of the Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, Washington, DC, USA: IEEE Computer Society, 2008a, p. 255-264.

Etxeberria, L.; Sagardui, G. Variability Driven Quality Evaluation in Software Product Lines. In: Proceedings of the Software Product Line Conference, Washington, DC, USA: IEEE Computer Society, 2008b, p. 243-252.

Ferber, S.; Heidl, P.; Lutz, P. Reviewing Product Line Architectures: Experience Report of ATAM in an Automotive Context. In: Proceedings of the International Workshop on Software Product-Family Engineering, London, UK: Springer-Verlag, 2002, p. 364-382.

Figueiredo, F.; Figueiredo, A.; Ramos, A.; Teles, P. Estatística Descritiva e Probabilidades. São Paulo-SP: Escolar, 2007.

Gacek, C.; Anastasopoules, M. Implementing Product Line Variabilities. SIGSOFT Software Engineering Notes, v. 26, n. 3, p. 109-117, 2001.

Gannod, G. C.; Lutz, R. R. An Approach to Architectural Analysis of Product Lines. In: Proceedings of the International Conference on Software Engineering, New York, NY, USA: ACM, 2000, p. 548-557.


Referências Geppert, B.; Weiss, D. M. Goal-Oriented Assessment of Product-Line

Domains. In: Proceedings of the International Symposium on Software Metrics, Washington, DC, USA: IEEE Computer Society, 2003, p. 180.

Gomaa, H. Designing Software Product Lines with UML: from Use Cases to Pattern-based Software Architectures. Boston, MA, USA: Addison-Wesley, 2005.

Gurp, J. V.; Bosch, J.; Svahnberg, M. On the Notion of Variability in Software Product Lines. In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture, Washington, DC, USA: IEEE Computer Society, 2001, p. 45.

Halmans, G.; Pohl, K. Communicating the Variability of a Software-Product Family to Customers. Software and System Modeling, v. 2, n. 1, p. 15-36, 2003.

Harsu, M. A Survey of Product-Line Architectures. Relatório Técnico 23, Institute of Software Systems, Tampere University of Technology, Finland, 2001.

Hoek, A. v. d.; Dincel, E.; Medvidovic, N. Using Service Utilization Metrics to Assess the Structure of Product Line Architectures. In: Proceedings of the International Symposium on Software Metrics, Washington, DC, USA: IEEE Computer Society, 2003, p. 298-308.


Referências Jensen, P. Experiences with Software Product Line Development.

Crosstalk, v. 22, n. 1, p. 11-14, 2003. Kazman, R.; Bass, L. Categorizing Business Goals for Software

Architectures. Relatório Técnico CMU/SEI-2005-TR-021, Software Engineering Institute (SEI), Pittsburgh, USA, 2005.

Kim, K.; Kim, H.; Kim, S.; Chang, G. A Case Study on SW Product Line Architecture Evaluation: Experience in the Consumer Electronics Domain. In: Proceedings of the International Conference on Software Engineering Advances, Washington, DC, USA: IEEE Computer Society, 2008a, p. 192-197.

Kim, T.; Ko, I. Y.; Kang, S. W.; Lee, D. H. Extending ATAM to Assess Product Line Architecture. In: Proceedings of the IEEE International Conference on Computer and Information Technology, USA: ACM Press, 2008b, p. 790-797.

Kitchenham, B.; Pfleeger, S. L.; Fenton, N. Towards a Framework for Software Measurement Validation. IEEE Transactions on Software Engineering, v. 21, n. 12, p. 929-944, 1995.


Referências Lamine, S. B. A. B.; Jilani, L. L.; Ghezala, H. H. B. Cost Estimation for

Product Line Engineering Using COTS Components. In: Proceedings of the Software Product Line Conference, Berlin, Heidelberg: Springer-Verlag, 2005, p. 113-123.

Linden, F. J. v. d.; Bosch, J.; Kamsties, E.; Känsälä, K.; Krzanik, L.; Obbink, J. H. Software Product Family Evaluation. In: Proceedings of the International Workshop on Software Product-Family Engineering, Berlin, Heidelberg: Springer-Verlag, 2004, p. 352-369.

Linden, F. J. v. d.; Schmid, K.; Rommes, E. Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2007.

Lutz, R. R.; Gannod, G. C. Analysis of a Software Product Line Architecture: an Experience Report. Journal of Systems and Software, v. 66, n. 3, p. 253-267, 2003.

Maccari, A. Experiences in Assessing Product Family Software Architecture for Evolution. In: Proceedings of the International Conference on Software Engineering, New York, NY, USA: ACM Press, 2002, p. 585-592.

McCabe, T. J. A Complexity Measure. IEEE Transactions on Software Engineering, v. 2, n. 4, p. 308-320, 1976.


Referências McGregor, J. D. Arcade Game Maker Product Line - Architecture

Evaluation Report. 2005. McGregor, J. D.; Muthig, D.; Yoshimura, K.; Jensen, P. Successful

Software Product Line Practices. IEEE Software, v. 27, n. 3, p. 16-21, 2010.

Montagud, S.; Abrahão, S. Gathering Current Knowledge About Quality Evaluation in Software Product Lines. In: Proceedings of the Software Product Line Conference, Pittsburgh, PA, USA: Carnegie Mellon University, 2009, p. 91-0100.

Niemelä, E.; Matinlassi, M.; Taulavuori, A. Practical Evaluation of Software Product Family Architectures. In: Proceedings of the Software Product Line Conference, Berlin, Heidelberg: Springer-Verlag, 2004, p. 130-145.

Nobrega, J.; Almeida, E.; Meira, S. InCoME: Integrated Cost Model for Product Line Engineering. In: Proceedings of the EUROMICRO Conference on Software Engineering and Advanced Applications, Washington, DC, USA: IEEE Computer Society, 2008, p. 27-34.


Referências Oliveira Junior, E. A.; Gimenes, I. M. S.; Huzita, E. H. M.; Maldonado, J. C.

A Variability Management Process for Software Product Lines. In: Proceedings of the Conference of the Centre for Advanced Studies on Collaborative Research, Toronto, ON, Canada: IBM Press, 2005, p. 225-241.

Oliveira Junior, E. A.; Gimenes, I. M. S.; Maldonado, J. C. A Metric Suite to Support Software Product Line Architecture Evaluation. In: Proceedings of the Conferencia Latinoamericana de Informática, Santa Fé, Argentina, 2008, p. 489-498.

Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S. Uma Revisão Sistemática sobre Avaliação de Linha de Produto de Software. Relatório Técnico No. 310, Instituto de Ciências Matemáticas e de Computação (ICMC) - Universidade de São Paulo (USP), São Carlos, SP, Brasil, 2007.

Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S. Uma Revisão Sistemática sobre Avaliação de Linha de Produto de Software: Iteração Jan/2008 a Jul/2010. Relatório Técnico No. 355, Instituto de Ciências Matemáticas e de Computação (ICMC) - Universidade de São Paulo (USP), São Carlos, SP, Brasil, 2010.


Referências Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “Empirical

Validation of Complexity and Extensibility Metrics for Software Product Line Architectures,” in 2010 Fourth Brazilian Symposium on Software Components, Architectures, and Reuse. Salvador-BA, Brasil: IEEE Computer Society, 2010, pp. 31–40.

Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “A Meta-Process to Support Trade-Off Analysis in Software Product Line Architecture” in Software Engineering & Knowledge Engineering Conference. Miami-FL, USA: IEEE Computer Society, 2010, (to appear)

Oliveira Junior, E. A.; Maldonado, J. C.; Gimenes, I. M. S., “Systematic Management of Variability in UML-based Software Product Lines,” Journal of Universal Computer Science (J.UCS), vol. 16, no. 17, pp. 2374–2393, 2010.

Olumofin, F. A Holistic Method for Assessing Software Product Line Architectures. Saarbrucken, Germany, Germany: VDM Verlag, 2007.

Olumofin, F. G.; Misic, V. B. Extending the ATAM Architecture Evaluation to Product Line Architectures. In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture, Washington, DC, USA: IEEE Computer Society, 2005, p. 45-56.


Referências Pohl, K.; Böckle, G.; Linden, F. J. v. d. Software Product Line Engineering:

Foundations, Principles, and Techniques. Secaucus, NJ, USA: Springer-Verlag, 2005.

Rahman, A. Metrics for the Structural Assessment of Product Line Architecture. Dissertação de Mestrado, School of Engineering - Blekinge Institute of Technology, Sweden, 2004.

Schmid, K. An Assessment Approach to Analyzing Benefits and Risks of Product Lines. In: Proceedings of the International Computer Software and Applications Conference on Invigorating Software Development, Washington, DC, USA: IEEE Computer Society, 2001, p. 525-530.

Schmid, K.; Verlage, M. The Economic Impact of Product Line Adoption and Evolution. IEEE Software, v. 19, n. 4, p. 50-57, 2002.

Schneidewind, N. F. Methodology for Validating Software Metrics. IEEE Transactions on Software Engineering, v. 18, n. 5, p. 410-422, 1992.

SEI A Framework for Software Product Line Practice. online, 2010a. Disponível em http://www.sei.cmu.edu/productlines/frame_report/index.html

SEI Arcade Game Maker Pedagogical Product Line. online, 2010b. Disponível em http://www.sei.cmu.edu/productlines/ppl


Referências SEI Hall of Fame. online, 2010c. Disponível em

http://www.sei.cmu.edu/productlines/plp_hof.html Taylor, R. N.; Medvidovic, N.; Dashofy, E. M. Software Architecture:

Foundations, Theory, and Practice. USA: John Wiley & Sons, 2009. Zhang, H.; Jarzabek, S.; Yang, B. Quality Prediction and Assessment for

Product Lines. In: Proceedings of the International Conference on Advanced Information Systems Engineering, Berlin, Heidelberg: Springer-Verlag, 2003, p. 681-695.

linhas de produto de software

Documents