Relatório do GPES UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Relatório referente à pesquisa preliminar da análise qualitativa sobre as metodologias de desenvolvimento de software baseado em product in line. Realizado do dia 14 de Novembro de 2011 a 28 de Novembro de 2011. Análise qualitativa sobre as metodologias do desenvolvimento de software em product in line. Em relatórios anteriores[17], já foram apresentadas algumas das metodologias voltadas para o desenvolvimento de software em Linha de Produtos. Neste, encontra-se uma análise mais detalha nessas metodologias. Método FODA (Feature-Oriented Domain Analysis) O método FODA é baseado na identificação, análise e documentação das principais funcionalidades dos sistemas; resultando em produtos de domínio genéricos e largamente aplicáveis em um domínio. Esse método se destaca dos demais não somente pela solidez e coerência da sua abordagem, mas também pela vasta documentação disponível e pelos vários casos de estudos apresentados na literatura.[1]. Esse método foi desenvolvido pelo Software Engineering Institute, em 1990. É o método de engenharia de domínio mais conhecido e um dos precursores dos demais. Trata-se de um método de análise de domínio que visa a construção de artefatos genéricos que sejam largamente reutilizáveis dentro do domínio [2]. A adoção de técnicas que favoreçam a reutilização de artefatos de software desde os estágios iniciais do desenvolvimento é um requisito fundamental para construir softwares eficientes, mais baratos e que atendam às necessidades dos clientes no momento adequado [3]. O método FODA, foi aperfeiçoado por um do seus criadores, Kyo C. Kang, na Universidade Pohang (Coreia), dando origem ao FORM, Feature Oriented Reuse Method [1]. Método DSSA (Domain-Specic Software Architecture) Arquitetura de Software de Domínio Específico (Domain-Specic Software Architecture) é uma arquitetura de referência que descreve uma estrutura computacional geral dedicada a um domínio. Pode conter uma biblioteca de componentes com partes reutilizáveis e procedimentos para selecionar e configurar os componentes, de acordo com os requisitos funcionais [4]. Uma DSSA deve ser genérica e aplicável a um domínio específico, descrevendo uma topologia de componentes de software e especificando conexões entre eles e modelos computacionais associados [5]. Essa metodologia deve ser também geral e flexível ao mesmo tempo e concebida com a participação de especialistas do domínio [4]. 1
Os principais produtos de trabalho do processo DSSA incluem os seguintes componentes [6]: modelo de domínio ou modelo de conceitos; requisitos de referência (equivalente ao modelo de características do FODA); arquitetura de referência para uma família de sistemas. Além dos componentes descritos anteriormente, também faz parte de uma DSSA um processo que descreve como a arquitetura pode ser utilizada no desenvolvimento de aplicações e uma infra-estrutura de suporte que define qual infra-estrutura ou ambiente necessário para suportar o processo de desenvolvimento baseado em uma DSSA [7]. Método FeatuRSEB O método FeatuRSEB é um método de Engenharia de Domínio resultante de uma combinação entre os métodos FODA e RSEB (Reuse-Driven Software Engineering Business). O RSEB é um processo sistemático de reutilização orientado a casos de uso. A arquitetura e os subsistemas reutilizáveis são descritos, primeiramente, em termos de casos de uso e então transformados em modelos de objeto que são rastreáveis. A variabilidade no RSEB é capturada se estruturando modelos de objetos e casos de uso, utilizando-se explicitamente pontos de variação e variantes[8]. FeatuRSEB trata-se de um método de engenharia de software orientado a reuso e a objetos, baseado na notação UML. O método FeatuRSEB é centrado no modelo de características e faz a distinção entre características funcionais, arquiteturais e de implementação [9]. Método FAST (Family-Oriented Abstraction, Specification and Translation) O método FAST é um processo de desenvolvimento para produzir software para uma família de produtos, desenvolvido pela Lucent e aplicado a vários domínios e produtos específicos. Este processo pode ser dividido em três subprocessos. Cada subprocesso consiste em diferentes atividades, produz diferentes artefatos e são executados por pessoas atuando em diferentes papéis. Os subprocessos são: qualificação do domínio para identificar famílias de produto economicamente viáveis; engenharia de domínio para investir em facilidades para produzir membros da família de produtos, e; engenharia de aplicação para usar as facilidades para produzir membros da família com eficiência [10]. A análise de características comuns é um aspecto marcante da utilização de FAST. Esta análise serve para identificar o contexto, descrever o domínio, fornecer um conjunto padrão de termos técnicos chave, identificar características comuns e variabilidades, quantificar as variabilidades por meio do fornecimento 2
de parâmetros de variação, identificar e registrar várias informações úteis que aparecem durante a análise [11]. Método PuLSE (Product Line Software Engineering) PuLSE é uma metodologia de construção e utilização de linhas de produto. Prevê a incorporação de elementos de software de arquiteturas já existentes na implementação da LPS [12]. O objetivo principal do método PuLSE é permitir a concepção e desenvolvimento de LPS numa vasta variedade de contextos empresariais. Os métodos de engenharia baseados no domínio cobrem muitos dos aspectos do PuLSE, no entanto sem a facilidade de adaptação e instalação dos produtos específicos [12]. O PuLSE é centrado em três principais elementos: as fases de desenvolvimento, que são fases lógicas do ciclo de vida de uma LPS; os componentes técnicos, que provêm o conhecimento técnico para operacionalizar o desenvolvimento da LPS; e os componentes de apoio, que fornecem diretrizes para apoiar os outros componentes [12]. Método KobrA O método KobrA foi desenvolvido no Fraunhofer Institute for Experimental Software Engineering (IESE) e se apresenta como uma adaptação do método PuLSE, dando ênfase à definição de um processo de desenvolvimento capaz de ser utilizado em organizações cujo grau de maturidade dos seus processos seja reduzido [13]. A essência da metodologia KobrA está na separação estrita e sistemática de assuntos. A manifestação mais visível deste princípio está na separação explícita da definição do produto da definição do processo, ou seja, a descrição do que deve ser feito é separada da descrição de como fazê-lo [14]. A abordagem KobrA é um método que integra os conceitos de linha de produto e desenvolvimento baseado em componentes, sendo uma especialização do PuLSE para o desenvolvimento baseado em componentes. Sua base esta centrada numa abordagem OO, na linguagem de modelação, a saber, a UML. Este método tem como principais desvantagens a sua complexidade em termos de implementação (no contexto de uma PME) e o fato de não serem conhecidas referências da sua implementação com sucesso na indústria [13]. Método GenVoca É uma metodologia baseada nos conceitos de máquina virtual, camadas de componentes (representando uma implementação da máquina virtual) e arquitetura-realm (um conjunto de componentes de mesmo tipo). GenVoca considera também os mecanismos de integração e operação para esses conceitos, os quais incluem equações de tipos, regras de projeto, gramáticas e geradores [15]. GenVoca é uma abordagem para a construção de geradores de software baseada na composição de camadas de abstração orientadas a objeto. Cada 3
camada contém um número de classes e uma camada superior refina a camada inferior, adicionando novas classes ou métodos às classes existentes [16]. A utilização da metodologia GenVoca tem mostrado algumas vantagens, como por exemplo, melhor desempenho da aplicação produzida, aumento de produtividade e redução de erros de desenvolvimento em comparação com técnicas de desenvolvimento convencionais. Entretanto, existem ainda algumas barreiras técnicas e não técnicas para as quais os autores da metodologia intencionam resolver futuramente [15]. Método Scrum O Scrum é um framework para planejamento e acompanhamento de projeto que segue os princípios do Manifesto Ágil. Por ser iterativo e incremental, ele funciona bem em um ambiente de constante mudança. Provê equipes autogerenciáveis e propõe uma forma de trabalho flexível e adaptável, não apenas em relação ao escopo e requisitos de um projeto, mas também quanto à troca de equipes, de ferramentas, de linguagens de programação, etc [18]. Método XP (extreme Programming) O XP é uma metodologia ágil voltada para a Engenharia de Software, dando mais atenção à programação, e não tanto ao gerenciamento, como é o foco do Scrum, motivo pelo qual normalmente são metodologias utilizadas juntas [19]. Foi criado por Kent Beck em 1996 e busca aprimorar um projeto de software utilizando cinco valores essenciais: comunicação, simplicidade, feedback, respeito e coragem. Foram definidas 12 práticas, sendo uma delas o Pair Programming, que consiste em juntar dois desenvolvedores em um único computador, concentrando-se no mesmo código. Isto irá fazer com que a qualidade do software aumente, mas sem impactar na entrega. O principal benefício passa a ser a disseminação do conhecimento entre o time [20]. Método Kanban O Kanban traz consigo a filosofia do JIT (Just In Time), que significa produzir apenas o necessário, no tempo necessário, na quantidade necessária, e no local necessário, com qualidade e envolvimento das pessoas, eliminando assim o desperdício, e garantindo o fluxo contínuo de produção [21]. Para David Anderson, o fato do Kanban possuir limite fixo do trabalho em progresso (WIP, Working In Progress), proporciona um tempo de ciclo previsível e eleva a expectativa da entrega com maior nível de qualidade. Além disso, sendo um sistema puxado, facilmente se verifica onde está o gargalo no fluxo de trabalho. Ainda de acordo com Anderson, Kanban não é um processo de ciclo de vida de gerenciamento de projeto ou de desenvolvimento, mas sim uma abordagem para gerenciar mudanças [20]. 4
Referências [1] KANG, K.C.; KIM, S.; LEE, J.; KIM, K.; SHIN, E.; HUH, M. FORM: A Feature- Oriented Reuse Method with Domain-Specific Reference Architecture. Departamentto de Engenharia e Ciência da Computação, Pohang Universidade de Ciência e Tecnologia, Coréia, 1998. [2] KANG Kyo, COHEN Sholom, HESS James, NOVAK William, PETERSON Spencer. Feature-Oriented Domain Analysis (FODA) feasibility study. CMU/SEI- 90-TR-21 ESD-90-TR-222, 1990. [3] PRIETO-DÍAZ, R. Historical Overview. In: Advances in Software Reuse: Selected Papers from the Second International Workshop on Software Reusability, p.1-16, Lucca, Italia, Março 1993. [4] METTALA, L. E.; GRAHAM, M. H. The domain-specific software architecture program. Relatório Técnico CMU/SEI-92-SR-009, Software Engineering Institute (SEI) Carnegie Mellon University, 1992. [5] SHAW, M.; GARLAN, D. An introduction to software architecture. Relatório Técnico CMU-CS-94-166, Carnegie Mellon University, janeiro, 1992. [6] GUIMARÃES, R. C. Arquitetura de software de domínio específico: um modelo aplicável a sistemas de informação no setor de telefonia móvel celular. Centro Estadual de Educação Tecnológica Paula Souza, São Paulo, Dezembro, 2006. [7] MENDES, A. Arquitetura de software desenvolvimento baseado na arquitetura. Rio de Janeiro, 2002. [8] GRISS, M.L., FAVARO, J., D'ALESSANDRO, M., Proceedings of Fifth International Conference on Softwre Reuse - ICSR5, p. 76-85, Canada, 1998. [9] GRISS Martin L.; FAVARO John; D'ALESSANDRO Massimo. Integrating Feature Modeling with the RSEB. In: IEEE, Sociedade da Computação, 1998. [10] LOBO, Ana E. C.; RUBIRA, Cecília M. F. Um Estudo para Implantação de Linha de Produto de Software baseada em Componentes. Instituto de Computação, Universidade Estadual de Campinas, Maio, 2009. [11] ARDIS, M., WEISS D. Defining Families: The Commonality Analysis, In: Proceedings of the Nineteenth International Conference on Software Engineering, maio, 1997. [12] BAYER, J.; FLEGE, O.; KNAUBER, P.; LAQUA, Roland; MUTHIG, D.; SCHMID, K.; WIDEN, T.; DEBAUD, J. M. PuLSE: A Methodology to Develop Software Product Lines, 1999. [13] ATKINSON, C.; BAYER, J.; MUTHIG, D. Component-Based Product Line Development: The KobrA Approach, 2000. [14] FARIAS, Carina M. Um Método de Teste Funcional para Verificação de Componentes. Campina Grande, Paraiba, 2003. [15] BATORY, D.Product-Line Architectures, Alemanha, outubro, 1998. [16] BATORY, D.; O'MALLEY, S. The Design and Implementation of Hierarchical Software Systems with Reusable Components. 1992. [17] SANTOS, Barbara C.; ALMEIDA, Thissiany B. Metodologias voltadas ao desenvolvimento de software baseado em Linhas de Produto. Grupo de Pesquisa em Engenharia de Software, outubro 2011. 5
[18] SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. Nova Jersey. [19] KNIBERG, H. Scrum e XP direto das Trincheiras. Estocolmo. [20] TAVARES, Giselle; FURTADO, Felipe. Uso de metodologias ágeis em uma organização baseada em linha de produto. In: Engenharia de Software Magazine, edição 38. [21] ANDERSON, D. Kanban. Estados Unidos. 6