Centro de Estudos e Sistemas Avançados do Recife Software Product Lines: Organizational Alternatives Jan Bosch University of Groningen (Netherlends) Luciana

Centro de Estudos e Sistemas Avançados do Recife

Software Product Lines: Organizational AlternativesJan BoschUniversity of Groningen (Netherlends)

Luciana Valadares

[email protected]


Introdução

• Desenvolvimento de software baseado em PL:– A literatura existente tende a focar na tecnologia e nos processos – Geralmente a estrutura organizacional não é discutida

• 4 modelos organizacionais– Situações que mais se aplicam– Vantagens e desvantagens

• Fatores que influenciam a escolha do modelo mais apropriado

• Categoriza as abordagens organizacionais para PL– Através de 3 dimensões


Modelo 1 - Development Departament• Descrição

– Não impõe estrutura organizacional permanente– Pessoas alocadas dinamicamente– Trabalho organizado em projetos– 2 categorias de projetos:

• ED: desenvolve um asset novo ou uma nova versão• EA: desenvolve um sistema novo ou uma nova versão

– Assets e sistemas são desenvolvidos e mantidos por uma única organização

• Aplicabilidade– Organizações pequenas, até 30 membros– Empresas de consultoria


Modelo 1 - Development Departament• Vantagens

– Simplicidade e facilidade de comunicação• A PL pode ser desenvolvida e evoluída de forma eficiente, com pouco overhead

administrativo– É possível adotar PL sem mudar a organização existente

• Simplifica o processo de adoção• Assumindo que existe uma atitude positiva no departamento em relação a reuso

• Desvantagens– Não escalável

• Reorganização e criação de unidades especializadas– As pessoas se interessam mais por um dos domínios

• Dependendo da cultura, a atividade de status mais baixo não é realizada adequadamente• É possível ter componentes altamente flexíveis e genéricos com sistemas que não atendem

aos requisitos– Ou vice-versa


Modelo 2 - Business Units• Descrição

– Cada unidade é responsável por desenvolver e evoluir um ou mais produtos da PL– Assets

• Compartilhados pelas unidades• Desenvolvimento inicial através de projetos de ED• Evolução distribuída

– unidade estende, testa e disponibiliza para as outras

• 3 níveis de maturidade– Em relação à evolução dos assets – Dependendo:

• No e tamanho das unidades • Razão funcionalidades compartilhadas x específicas dos sistemas


Modelo 2 - Business Units• I) Unconstrained Model

– Qualquer unidade pode estender um componente e disponibilizar – Problemas:

• Componentes com funcionalidade system-specific• Erosão ou degradação do componente

– Mais difícil e menos cost-effective usar o componente do que criar uma versão da funcionalidade no sistema

• Projetos de reengenharia de componentes– Quando falha: PL existe só na teoria– Invalida vantagens – Mantém desvantagens


Modelo 2 - Business Units• II) Asset Responsibles

– Quando os problemas anteriores ocorrem com frequência– Responsável:

• Evolução precisa de sua concordância• Interesse da organização e não de uma unidade específica• Implementação continua sendo feita pelas unidades• Verificação antes de ser disponibilizado

– Na prática, continua difícil controlar as evoluções• Requisitos de TTM são priorizados pela alta gerência• Verificação não trivial

– Erosão dos componentes• Mais suave


Modelo 2 - Business Units• III) Mixed Responsibility

– A responsabilidade de evoluir o asset é atribuída a uma unidade específica– As outras unidades precisam requisitar a ela quando precisam de mudanças– Vantagem

• Controle da evolução– Desvantagem

• Atraso, a unidade que necessita não for a que faz• Unidade tem que dividir esforço entre evolução do componente e desenvolver

próxima versão do produto– CR’s de outras unidade vão ser preteridas– Unidade responsável pode evoluir de acordo com seus propósitos e não o

da organização– Conflito entre as unidades, até a abortagem da PL

Não!!Não!!


Modelo 2 - Business Units• Conflitos

– A forma como a PL começa a existir é um fator importante para o sucesso ou falha– Se já existiam as unidades independentes

• Decisão gerencial: conflitos são maiores - desistir da liberdade é difícil• PL evolui de baixo para cima, por cooperação entre staffs: ambiente mais

favorável– Embora os conflitos ainda existam– Cooperação opcional x obrigatória

– Unidades surgem do crescimento da empresa• Expansão do conjunto de sistemas• As pessoas já trabalhavam juntas e nos mesmos assets• Cooperação permanece, principalmente se tiver apoio da gerência

– Devem ser resolvidos pela gerência• Cedo e de forma pró-ativa• Risco grande para o sucesso da PL


Modelo 2 - Business Units• Aplicabilidade

– Staff: entre 30 e 100– Abaixo de 30: overhead de comunicação alto– Acima de 100: unidades de ED são necessárias para diminuir comunicação

• N-n -> 1-n

• Vantagens– Compartilhamento eficiente dos assets (em termos de acesso)– Mais escalável

• Desvantagens– Não existe incentivo para focar nos assets

• Erosão da arquitetura e dos componentes• Evolução confiável e no prazo depende da cultura


Modelo 3 – Domain Engineering Unit

• Descrição– Separação entre o desenvolvimento e evolução dos assets x sistemas

• Unidades de ED e de EA– Duas abordagens:

• 1 unidade de ED: único ponto de contato para as unidades de EA• várias unidades de ED: uma unidade é responsável pela arquitetura e as outras lidam

com componentes (ou conjunto de componentes relacionados)– Nível de especialização é maior– Unidades de EA precisam interagir com várias unidades de ED

• Aplicabilidade– Staff acima de 100

• Overhead de comunicação causa a necessidade de uma unidade (ou várias) especializada em ED


Modelo 3 – Domain Engineering Unit

• Vantagens– Remove a necessidade de comunicação n-n 1-n– A evolução dos componentes é feita de modo que os requisitos de todos os sistemas são satisfeitos– Conflitos podem ser resolvidos de forma mais objetiva e mais compromise-oriented– Mais escalável do que os outros

• Desvantagens– Dificuldade de gerenciar o fluxo dos requisitos entre as unidades de ED

• Balanceamento entre os requisitos conflitantes e a subsequente implementação dos requisitos selecionados para a próxima versão dos assets

• Atraso na implementação de novas features e consequentemente no TTM do produto!• Para sanar, permite que unidades de EA criem temporariamente suas próprias versões


Modelo 4 – Hierarchical Domain Engineering Units• Descrição

– Geralmente por questões técnicas, um nível adicional é introduzido à PL• Esse nível contém uma ou mais PL’s especializadas , que dependendo do tamanho e da

complexidade podem ser gerenciadas usando o modelo de Business Units ou Domain Eng. Units

– No caso de uma PL especializada requerer um unidade de ED, tem-se o modelo hierárquico de ED• O único adequado a grandes organizações, com uma família extensa de produtos

• Aplicabilidade– Quando a quantidade e a variabilidade de sistemas é muito grande– Staff: centenas de pessoas– Grandes organizações com sistemas de vida-longa, já que os investimentos são muito altos– É o modelo mais complexo


Modelo 4 – Hierarchical Domain Engineering Units• Vantagens

– Habilidade de englobar PL’s complexas e organizar quantidade grande de engenheiros

• Desvantagens– Overhead grande e dificuldade de reações ágeis para requisitos de mudança de

marketing• Trade-off entre permitir que unidades de EA ajam independentemente

(versões temporárias de componentes) versus ajustar as commonalities entre os produtos e exigir que as unidades de EA usem versões compartilhadas


Fatores de Influência

• Além do tamanho da PL e do staff

• 1) Distribuição Geográfica– A despeito das soluções tecnológicas, ainda influencia– É mais difícil manter canais de comunicação– Pode fazer uma empresa selecionar um modelo Domain Engineering Unit para focar na comunicação entre a

unidade de ED e cada unidade de EA

• 2) Maturidade da Gerência de Projeto– PL requer um nível alto de maturidade– Exemplo da Axis: para incorporar um nova funcionalidade num componente, requer comunicação com as outras

unidades:• No início, durante e no final• Verificar que nenhuma unidade está incluindo a mesma funcionalidade• Se está sendo incluída de forma genérica e de forma que traga os maiores benefícios possíveis para as outras• Se a nova versão provê compatibilidade com os sistemas desenvolvidos por outras unidades


Fatores de Influência

• 3) Cultura Organizacional– Atitude de cada engenheiro em relação às suas atribuições e padrões de valores dos grupos informais– Cultura de heróis (valoriza alcances individuais), pode ser um grande inibidor

• Reuso depende de uma cultura de time, que suporte inter-dependência, confiança e compromisso• Exemplo de uma empresa em que a iniciativa de PL foi cancelada

– Unidades tinham que sacrificar seus arquitetos líderes, atrasando projetos planejados para desenvolver os assets

– Gerentes egoístas x cultura implantada de unidades muito independentes

• 4) Tipos de sistemas– Sistemas com requisitos que mudam drástica e frequentemente são difíceis de adotar um modelo

hierárquico– Empresas de consultoria não podem ter o mesmo investimento em reuso do que empresas product-

based• Risco maior de que projetos futuros não sejam do mesmo domínio


Dimensões Organizacionais

• Têm papel importante na seleção do modelo adequado

• Quando combinadas, formam um espaço de alternativas

• 1) Assets da PL– A forma como os assets são definidos depende do tipo dos produtos e de como a organização

emprega a abordagem de PL– 4 níveis

• Arquitetura: organizações com pouca integração entre as unidades• Plataforma: funcioanlidades compartilhadas por todos os produtos• Componentes: muitos componentes compartilhados por 2 ou mais produtos• Product-specifics: maior nível de integração. Usado no futuro para outros produtos, facilita

futuras integrações


Dimensões Organizacionais

• 2) Níveis de responsabilidade– Shared

• Compartilhada entre as unidades organizacionais– Responsible

• Limitada, para verificação e não implementação– Engineered

• Um time é responsável pelo desenvolvimento de um asset• Responde às CR’s da melhor forma para a organização

• 3) Unidades organizacionais– Project

• Staff atribuído a projetos dinamicamente– Product

• Staff atribuído a um produto• Aumenta eficiência, diminui compartilhamento

– Shared components• Componentes são atribuídos a unidades provedoras

– Architecture centric• A arquitetura e o staff controlam o desenvolvimento


Alternativas Organizacionais

• As 3 dimensões definem um espaço que pode ser usado para categorizar abordagens organizacionais

• Gráfico– Development Departament e Business Units são linhas– Domain Eng. Unit e Hierarchical Domain Eng. Unit são planos

• Existem alternativas para eles– Existem várias outras alternativas

• Quando for adotar uma PL, o importante é entender as alternativas disponíveis e avaliá-las

– Ao invés de apenas adotar modelos padrões


Applying Product Line Concepts in Small and Medium-Sized CompaniesP. Knauber, D. Muthing, K. Schmid, T. WidenFraunhofer Institute for Experimental Software Engineering

Luciana Valadares

[email protected]


Introdução

• Pulse– Método para PL– Customizado para diferentes tipos de organizações

• Abordagens de ED de sucesso são quase sempre de empresas grandes

• Em 97, o IESE iniciou um projeto para transferir conceitos de PL para pequenas e médias empresas (SME’s)


O Projeto

• Software Variant-Building Project– 2,5 anos– Aplicando e validando vários métodos– Cada empresa: pelo menos 18 homem/mês– IESE: 7 homem/mês por empresa

• Coach no processo– 6 empresas: 2 a 11 desenvolvedores

• Abordagem Inicial– Processo de Análise de Commonalities da Lucent– Encontros semanais com parceiros, com grupos de experts para discussão

• Tarefas feitas entre os projetos– Treinamento limitado

• 1 dia de introdução• “training while doing”

• As lições aprendidas influenciaram no desenvolvimento do Pulse


Pulse

• Premissa básica– Métodos existentes não podem ser aplicados diretamente a novos contextos

• Provê processos customizados que integram aspectos de métodos existentes, mas são configurados (tailored) para se adequar a cada situação específica

• 3 elementos principais– Fases de desenvolvimento: estágios lógicos da PL

• Inicialização de Pulse• Construção da Infra-estrutura de PL• Uso da infra-estrutura de PL• Evolução da infra-estrutura de PL

– Componentes técnicos: provê o know-how técnico para realizar as atividade requeridas em cada fase

– Componentes de suporte: direciona pré-customizações de Pulse e aspectos organizacionais, possibilitando avaliar a qualidade de uma aplicação de Pulse num ambiente específico


Pulse

• Construção da infra-estrutura de PL– Usa 3 componentes técnicos– Pulse-ECO: para definição de escopo

• Visão clara de quais produtos serão desenvolvidos• Descreve quais funcionalidades deverão ser genéricas e quais deverão ser

tratadas nos sistemas específicos – Pulse-CDA: para modelagem da PL

• Ajuda a documentar os requisitos e possibilita a instanciação do modelo para projetos individuais

– Pulse-DSSA: para definição da arquitetura• Arquitetura é o núcleo de uma PL• São mais complexas• Desenvolvimento incremental


Lições Aprendidas

• 1) Transferência de Tecnologia– Fator essencial: influência de pessoas-chave

• Convencer sobre o valor da tecnologia a ser usada• Projeto pode falhar

– Ausência de processo de desenvolvimento• Não se pode introduzir novas tecnologias formalmente (uso de exemplos)• Difícil mudar um procedimento ou introduzir novas tarefas

– A oportunidade do projeto de transferência é usada para introduzir um processo mais formal

• A definição do processo é ignorada, devido às pressões


Lições Aprendidas

• 2) Introduzindo Engenharia de PL– Pequenas empresas: cooperação com os clientes

• Vantagens de marketing– Sabem mais cedo das necessidades– São capazes de reagir de forma mais flexível a essas necessidades

• Desvantagem em relação a PL– Requisitos básicos: clara visão do futuro das aplicações e alguma

estabilidade de domínio• Mudanças de comportamento

– Poucos benefícios em ser flexível – Melhor direcionar as necessidade para serem suportadas pela PL


Lições Aprendidas• 3) Definição de Escopo

– SME’s: sem visão precisa dos produtos futuros– Difícil aplicar ECO em 1a instância– Depois que a organização aceitou

• Ajudou a formatar a visão da empresa e encontrar oportunidades– Poucos recursos

• Não vão devotar tempo para um projeto desse – Útil a abordagem requerer pouco esforço das empresas – Uso de ferramentas simples, inserir dados em off-line

• 4) Modelagem da PL– Gerentes precisam forçar os desenvolvedores

• Trabalhos só nos encontros• Encontros maiores e menos frequentes

– Empresas sem processo• Foi preciso introduzir os dois• Muita orientação sobre a nova forma de trabalho

– Encontros de grupos• Bom para compartilhar e checar conhecimento• Focado, com poucas pessoas, para revisão


Lições Aprendidas– Abordagem de treinamento

• Eficiente, com muitos exemplos de como fazer– O IESE documentar os modelos

• Nào foi bom, não tinham expertise– Processo de Análise de Commonalities

• Necessidade de modelos diferentes– Começar com padrões, mas olhar para outros

– Suporte de ferramenta• Importante• Muitas informações e dependências, ajuda a controlar


Lições Aprendidas• 5) Definição da Arquitetura

– Falta de documentação– Arquitetos da arquitetura de referência eram os mesmos da dos sistemas

• Tendem a resistir às mudanças– Evitar retrabalho– Admitir existência de soluções melhores


Conlusões• Para transferir com sucesso conceitos de PL para SME’s

– Abordagem product-oriented– Mostrar resultados logo– Processo otimizado, empresa não tem como suportar overhead extra– Mudanças na forma de trabalho

• Abordagem: Proceso de Análise de Commmonalities Pulse• Forma de trabalho: menos encontros e mais longos


Considerações Finais

• Dificuldade de adotar uma abordagem de PL

• Não existe “receita de bolo”– Avaliar uma abordagem adequada– Negócio da empresa– Tamanho do time e das aplicações– Realidades sócio-culturais


FIM

Luciana Valadares

[email protected]


Modelo 1 - Development Departament• Exemplo

– Securitas Larm (Suécia)– PL (hardware e software) de sistemas de alarme de fogo– Staff: 25 pessoas– Há alguns anos era organizada em unidades de negócio

• Cada uma responsável por venda, marketing, instalação e desenvolvimento do produto

• Equipes pequenas de desenvolvimento– Reorganização num único departamento

• Para obter desenvolvimento mais eficiente


Modelo 2 - Business Units• Exemplo

– Axis Communications (Suécia)– 3 unidades de produtos (scanner-server, storage-server, camera-server)– Compartilham uma arquitetura e um conjunto de mais de 10 frameworks OO– Iniciou com Unconstrained Model e depois passou para Asset Responsibles– Quando é necessária a criação (ou reprojeto) de um grande asset ou conjunto de

assets, usa projeto de ED• “Disfarçados” como projetos de EA protótipos de sistemas• Vantagem: integração do novo com os existentes é verificada automaticamente

Documents

Centro de Estudos e Sistemas Avançados do Recife Software Product Lines: Organizational Alternatives Jan Bosch University of Groningen (Netherlends) Luciana