Software Product Lines Organizational Alternatives Jan Bosch University

Software Product Lines: Organizational Alternatives Jan Bosch University of Groningen (Netherlends) Luciana Valadares luciana. valadares@cesar. org. br Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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!! Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

Applying Product Line Concepts in Small and Medium-Sized Companies P. Knauber, D. Muthing, K. Schmid, T. Widen Fraunhofer Institute for Experimental Software Engineering Luciana Valadares luciana. valadares@cesar. org. br Centro de Estudos e Sistemas Avançados do Recife

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) Centro de Estudos e Sistemas Avançados do Recife

O Projeto • Software Variant-Building Project – – – • Abordagem Inicial – – – • 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 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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

Lições Aprendidas • 3) Definição de Escopo – – • SME’s: sem visão precisa dos produtos futuros Difícil aplicar ECO em 1 a 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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

FIM Luciana Valadares luciana. valadares@cesar. org. br Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife

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 Centro de Estudos e Sistemas Avançados do Recife