Centro de Estudos e Sistemas Avançados do Recife Software Product Lines: Organizational...
Transcript of Centro de Estudos e Sistemas Avançados do Recife Software Product Lines: Organizational...
Centro de Estudos e Sistemas Avançados do Recife
Software Product Lines: Organizational AlternativesJan BoschUniversity of Groningen (Netherlends)
Luciana Valadares
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!!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
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
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 CompaniesP. Knauber, D. Muthing, K. Schmid, T. WidenFraunhofer Institute for Experimental Software Engineering
Luciana Valadares
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– 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
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 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
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
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