Modeling and Using Product Line Variability in Automotive Systems

1. Modeling and Using Product Line Variability in Automotive Systems Steffen Thiel and Andreas Hein, Robert Bosch Corporation

2. Introdução • Sistemas para automóveis • Sistemas para conforto • Auxílio para estacionar • Controle de rotas • Sistemas de segurança • Estabilidade automática • Controle de airbag • Sistemas para aumento de eficiência • Controle do combustível • Envolve soluções de hardware e software • Centenas ou milhares de variabilidades • É indispensável um processo sistemático de gerenciamento de variabilidades

3. Desenvolvimento Tradicional • Entidades unifuncionais • Não considerava a funcionalidade TOTAL do carro • Problemas: • Alto custo de Hardware • Desenvolvimento de software excessivo • Alto custo de manutenção • Hardware dedicado • Restringia a reusabilidade

4. Plataform-based development • Integração das funcões em uma plataforma multifuncional • Substitui componentes mecânicos e eletrônicos (Hardware) por soluções inteligentes de software • Exemplo: plataforma comum para sistemas de Radio • Vantagens do desenvolvimento baseado em plataforma: • Serviços adicionais • Mais flexibilidade • Compartilhamento de Hardware • Solução não atende a redução de custos e time-to-market • O esforço para desenvolver plataforma complexa não é compensado pela economia em Hardware

5. Product Line • O reuso sistemático, garantiria a economia no desenvolvimento baseado em plataformas. • Foi adotado então uma abordagem de Product Line

6. Variabilidade • Desenvolver uma Product Line é diferente de desenvolver produto únicos. • Variabilidade deve ser sempre avaliada • Variabilidade afeta todos os artefatos (de requisitos a código) • Entretanto, geralmente é introduzida no final do projeto ou na implementação (ERRADO)

7. Feature Model

8. Arquitetura

9. Feature Model x Arquitetura

10. Arquitetura do Produto

11. Developing Mobile Browsers in a Product Line Ati Jaaksi, Nokia

12. Introdução • Explica o processo de implantação de uma Product Line na Nokia • Histórico • 1998 – US Nokia desenvolveu o script engine e WML markup handling para o Nokia 7710 • 1999 – WAP Toolkit • 1999 – Nokia Hungria desenvolveu o WAP gateway • 1999 – Nokia Dinamarca desenvolveu outro protocol stack • Era hora de montar uma Product Line

13. Necessidades • Integrar todos os componentes • Browsers em diferentes aparelhos • Licenciar para terceiros

14. Arquitetura

15. Organização e Processo • Entidades Funcionais: • Product management – Coleta, analisa e prioriza requisitos do produto • Product development –Desenvolve produtos • System testing • Customer Support • Advanced Development – Padronização, estudos de arquitetura, protótipos e demonstrações de novas tecnologias

16. Análise dos Requisitos • Documento de requisitos APENAS DO PRODUTO EM QUESTÃO • Não especifica requisitos para o Product Line • Durante os dois primeiros projetos, houve a tentativa de especificar requisitos para o Product Line, mas, é muito difícil. • Clientes discutem sobre produtos, não componentes • Mapeamento em requisitos da PL ocorrem depois, na fase de Projeto. • Roadmaps para características esperadas do produto para o FUTURO ! • Product Board avalia os roadmaps, sincronizando todos os produtos (domain analysis sobre todos os produtos que foram desenvolvidos)

17. Desenvolvimento • 4 times: • Core (Browser e Protocol) • Plataforms • Toolkit • Testing • Product Managers definiam os requisitos do Produto, times de engenharia analisavam e extraiam as funcionalidades genéricas • Raramente foi desenvolvido componentes da PL independente de um Produto • Projeto e implementação em ciclos • Vários releases e builds diários para testes (verificar se a alteração não iria “quebrar” outro produto)

18. Benefícios • Aumento da eficiência • Diminuição dos custos • Aumento de qualidade • Acumulou entendimento do domínio • Identificação de novos requisitos mais cedo • Motivação dos funcionários • 1999 e 2000 – 3 % turnover (época onde houve uma grande oferta) • Aumentou a credibilidade (centro de excelência em XML, XHTML, scripting)

19. Custos e Riscos • Recursos extras em processos, desenvolvimento de ferramentas e gerenciamento • Para minimizar, evite criar assets que não serão reusados • Criação de core assets atrasou a entrega dos primeiros produtos • Primeiro criar produtos e só depois extrair os componentes deles (reengenharia) • Dificuldade para criar uma Arquitetura • Deve atender todos os produtos e não ser otimizado para um produto específico

20. Custos e Riscos • Mudança em um componente pode afetar outros produtos • Investimento em Gerência de Configuração, Gerenciamento de Requisitos, sincronização de projetos • Conflitos entre times • Incentivos baseado em produtividade (desestimulando o suporte a outros times) • Conflitos entre Clientes • Querem concentração total em seus produtos • Testes mais complexos • 25% das pessoas estão em times de teste • 30% do tempo é para testes

21. Conclusão • Benefícios superaram os custos • Desafio: Melhorar a reengenharia • Deve ser identificado um domínio comum (entre os clientes) • Os processos e estrutura organizacional deve suportar PL • Esforço pago em longo prazo • Investimento racional, construção de alguns produtos antes de fazer PL • Gerência deve ter compromisso de apoio de longo prazo