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

Apresentação em tema: "Centro de Estudos e Sistemas Avançados do Recife Software Product Lines: Organizational Alternatives Jan Bosch University of Groningen (Netherlends) Luciana."— Transcrição da apresentação:

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

2 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

3 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

4 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

5 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

6 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

7 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

8 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!!

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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)

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

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

33 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

34 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