GERENCIAMENTO DE CONFIGURAÇÕES EM DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE

Transcrição

1 GERENCIAMENTO DE CONFIGURAÇÕES EM DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE Henrique Dalavale Fabretti[Voluntário] 1, Alexandre L Erario [orientador] 2 1 COENC, Coordenação de Engenharia de Computação 2 COADS, Coordenação de Análise e Desenvolvimento de Sistemas Campus Cornélio Procópio Universidade Tecnológica Federal do Paraná - UTFPR Avenida Alberto Carazzai, Cornélio Procópio Henrique.fabretti@gmail.com, alerario@utfpr.edu.br Resumo - Este artigo apresenta um estudo sobre o gerenciamento de configurações em ambientes de Desenvolvimento Distribuído de Software. Este identifica que o GC em ambientes de DDS tem sua complexidade expandida em função da distância entre as equipes de desenvolvimento. Além disso, os sistemas de controle de versões precisam de funcionalidades adicionais relacionadas à capacidade de gerenciar múltiplos servidores de versões e a sincronização entre estes. Palavras-chave: Gerenciamento de Configuração; Desenvolvimento Distribuído de Software. Abstract - This paper presents a study on the configuration management environments in Distributed Software Development. This identifies that the CM in DDS environments has expanded its complexity depending on the distance between the development teams. In addition, version control systems need additional features related to the ability to manage multiple servers and synchronization between these versions. Keywords: Configuration Management; Distributed Software Development. INTRODUÇÃO Gerenciamento de Configuração. Gerenciamento de Configuração (GC) segundo [11] é o conjunto de desenvolvimento e aplicação de padrões e procedimentos para controlar um produto que está em desenvolvimento. O GC é necessário, pois todo produto, durante seu projeto, está sujeito à alterações (mudanças, correções ou adaptações), e a cada vez que este produto é incrementado, é necessário manter um controle do que é alterado ou incluído. CG na prática define como registrar e processar as mudanças, como relacioná-las aos componentes do sistema e métodos para identificar diferentes versões do software. O ponto de partida para o desenvolvimento do plano deve ser um conjunto de padrões de configuração, que devem ser adaptados para se atender aos requisitos e às restrições de cada projeto especifico. Deve ser organizado em um número de seções que: Define o que será gerenciado e o esquema para identificar as entidades; Estabelece quem é responsável pelos procedimentos de GC e submissão de itens controlados para a equipe de GC; Define os padrões de GC que todos os membros devem adotar para o controle de mudanças e gerenciamento de versões; Especifica as ferramentas que se deve usar para o GC e os

2 processos para uso destas; Descreve a estrutura do banco de dados de configuração usada onde serão armazenadas as informações de configurações. Gerentes de versões idealizam procedimentos para assegurar que as versões de um sistema possam ser recuperadas quando solicitadas e não sejam alteradas acidentalmente pela equipe de desenvolvimento. Para um produto (nosso caso, DDS), os gerentes de versões trabalham com a equipe de marketing (caso for um software privado). Uma versão de um sistema é uma instância de um sistema que difere, de alguma maneira, de outras instâncias. Versões de um sistema podem ter funcionalidades distintas, desempenhos aprimorados ou defeitos de software reparados. Algumas versões podem ser funcionalmente equivalentes, mas projetadas para diferentes configurações de hardware e software. Versões com somente pequenas diferenças são algumas vezes chamadas de variantes. Um release do sistema é uma versão distribuída aos clientes. Cada release deve incorporar novas funcionalidades ou ser planejado para uma plataforma diferente de hardware. Para criar uma versão específica de um sistema, é preciso especificar as versões dos componentes de sistema que devem ser incluídas nele. Há três técnicas básicas usadas para identificação da versão de componente: Numeração de versões, onde componente recebe um número explicito e único da versão. Isso é o mais comumente usado; Identificação baseada em atributos, onde cada componente tem um nome e um grupo de atributos associados para cada versão. Os componentes são identificados pela especificação de seus nomes e valores de atributos; Identificação orientada a mudanças, onde cada componente é nomeado, e também associado com uma ou mais solicitações de mudanças. Considera-se que cada versão de componente foi criada em resposta a uma ou mais solicitações de mudanças. A versão de componente é identificada pelo conjunto de solicitações de mudanças que se aplicam ao componente. Um número de versão é adicionado ao componente ou ao nome do sistema. Se a primeira versão for chamada de 1.0, as versões subsequentes serão 1.1, 1.2 e assim por diante. Em algum estágio, um novo release é criado (versão 2.0), e o processo inicia-se novamente da versão 2.1. Isso ocorre linearmente, baseado no conceito de que as versões do sistema são criadas em sequência. Um problema fundamental com os esquemas explícitos de nomeação de versões é que eles não refletem os diversos atributos que podem ser usados para identificar as versões. Exemplos desses atributos de identificação são: Cliente; Linguagem de desenvolvimento; Status de desenvolvimento; Plataforma de hardware; Data de criação. Se cada versão é identificada por um único conjunto de atributos, é fácil adicionar novas versões derivadas de algumas das versões existentes. Elas são identificadas usando um conjunto único de valores. Exemplo: CFinanceiro (I.Cliente = Luiz Antonio, II. linguagem = Java, III. Status = Final, IV. plataforma = Windows Seven, V. data = Dez2011) Para recuperar uma versão, é preciso conhecer seus atributos associados e usar um sistema de gerenciamento de mudanças separado para descobrir os relacionamentos entre versões e alterações. A identificação orientada a mudanças é usada para identificar versões de sistema em vez de componentes. Cada mudança de sistema que tenha sido implementada tem um conjunto de mudanças associadas que descreve as mudanças solicitadas realizadas em diferentes componentes do sistema. Um release de um sistema é uma versão do sistema distribuído para os clientes, onde os gerentes de releases de sistemas são responsáveis por decidir quando um sistema pode ser liberado para os clientes, gerenciar o processo de criação do release e de meios de distribuição

3 e documentar o release para assegurar que ele pode ser recriado exatamente como foi distribuído, se for necessário. A preparação e distribuição de um release de sistema é um processo dispendioso, particularmente para produtos de software voltados para um grande mercado. Se os releases forem muito frequentes, os clientes poderão deixar de atualizar os antigos releases. Se os releases não forem frequentes, poderá haver perda de participação no mercado, à medida que os clientes migram para sistemas alternativos. A criação de releases é um processo de criação de arquivos e documentos que inclui todos os componentes do release do sistema. O código executável de programas e todos os arquivos de dados associados devem ser coletados e identificados. As descrições de configuração podem ter que ser escritas para hardwares diferentes e para instruções e sistemas operacionais preparados para clientes que necessitem configurar os próprios sistemas. Finalmente, quando todas as informações estiverem disponíveis, o diretório do release é manipulado para distribuição. Desenvolvimento Distribuído de Software. Numa era globalizada, onde organizações com filiais em diversos países buscam incansavelmente o lucro, que é resultante de baixos custos e tempo de produção, a ideia de se produzir software a um nível global tornou-se plausível, senão necessária. Segundo [3], não existem dúvidas para qualquer profissional que trabalha na área de engenharia de software que tanto o desenvolvimento de software tradicional quanto o distribuído possuem diversas dificuldades. As principais características que os diferenciam são: dispersão geográfica (distância física); dispersão temporal (diferenças de fuso-horário); e diferenças culturais (idioma, tradições, costumes, normas e comportamento). Na prática o desenvolvimento distribuído de software (DDS) ocorre quando grupos cooperam e/ou colaboram para desenvolver partes ou um todo de um software. A principal motivação do DDS, entre outras, conforme citado por [5], é a redução de tempo e custo de produção de software, que são compatíveis com a nossa realidade atual (era globalizada). Porém, existem algumas variáveis que podem comprometer a interação e consequentemente o tempo de respostas entre os nós (os grupos que trabalham juntos), que são justamente as citadas por [3]. Muitas vezes o DDS acontece mesmo sem que os grupos envolvidos conheçam as suas características, mas em prática o executam. Existem casos que o DDS é empregado para que poucos tenham acesso à todo o software (evitando fraudes), ou seja, vários grupos desenvolvem parte do software, então cada um só tem acesso àquilo que desenvolveu. [8] em sua pesquisa concluiu que o DDS se caracteriza pelos seguintes critérios: Distancia física dos autores; Distribuição da equipe de desenvolvimento; Terceirização do desenvolvimento; Diferenças culturais; Tamanho do projeto; A distribuição geográfica, que engloba a distancia física dos autores e a distribuição da equipe de desenvolvimento, ocorre de duas formas: Offshore, ou seja, em um país diferente da matriz da empresa contratante e do cliente. Segundo [5], o objetivo da prática de offshore é aumentar a produtividade, reduzir custos e tornar a distribuição do software mais compatível com características locais; Onshore, onde estão localizados no mesmo país a matriz da empresa e o cliente. Podem ocorrer duas situações de desenvolvimento: onsite e offsite. Na primeira situação o cliente e desenvolvedor estão fisicamente no mesmo espaço. Na segunda, não. A terceirização (normalmente citada como outsourcing) não se caracteriza especificamente como um critério de DDS. Várias empresas utilizam o conceito de outsorcing para representar uma estratégia de negócios onde uma unidade (subsidiária) da empresa localizada em outro país ou estado torna-se responsável pela atividade envolvendo o processo

4 de desenvolvimento de software. Nesse caso, o outsourcing não envolve uma terceirização tradicional, pois a unidade responsável é da própria empresa. As diferenças culturais em um ambiente de DDS surgem das diferenças culturais entre os membros das equipes e entre os locais fisicamente distantes. Entre essas diferenças podemos exemplificar o idioma e diferenças de fuso horário. O crescimento das ferramentas de CSCW (Computer Supported Cooperative Work) e da própria internet também favorece e ressalta a ideia do GSD (Global Software Development), como disseram [9] Dentre essas ferramentas podemos citar softwares de gerenciamento de versões, videoconferências (para reuniões entre os nós), e mais recentemente plataformas capazes de oferecer um ambiente de desenvolvimento de software. METODOLOGIA A metodologia utilizada a principio foi a Pesquisa Exploratória, que consiste em realizar um estudo superficial do tema a ser explorado, a fim de haver um primeiro contato com o material. Na pesquisa exploratória, caso o problema proposto não apresente aspectos que permitam a visualização dos procedimentos a serem adotados, é necessário que o pesquisador inicie um processo de sondagem, com vistas a aprimorar ideias, descobrir intuições e, mais tarde, construir hipóteses. Sendo assim, realizamos posteriormente uma pesquisa com maior compreensão e precisão. Estudamos o tema Gerenciamento de Configurações, para aperfeiçoamento de conhecimento nessa área da Engenharia de Software [11], e posteriormente sobre como encaixá-la nos ambientes de Desenvolvimento Distribuído de Software [1], [2], [4], [5], [10] e [12]. Para trabalhos futuros, utilizaremos o método de pesquisa survey, que pode ser descrita como a obtenção de dados ou informações sobre características, ações ou opiniões de determinado grupo de pessoas, indicado como representante de uma população-alvo, por meio de um instrumento de pesquisa, normalmente um questionário, tendo como estratégia de aplicação a entrevista pessoal, o envio pelo correio e outras. Na escolha da estratégia de aplicação deve-se atentar para o custo, o tempo, e também para a forma que venha a garantir uma taxa de resposta aceitável para o estudo. O ambiente de trabalho onde será realizada a pesquisa survey é a de alunos de disciplinas distintas de um mesmo curso, caracterizado como nível 1 por [6], a fim de identificar os processos de gestão de configuração utilizado pelos alunos. O questionário será composto em partes pelas questões a seguir: Qual o processo de gestão de configuração utilizado; Quais as atividades desse processo de gestão de configuração; Quais artefatos foram gerados; Qual foi a necessidade para se gerar mais de um artefato. RESULTADOS E DISCUSSÃO Gerenciamento de Configuração em Desenvolvimento Distribuído de Software. O GC ajuda a gerenciar as mudanças e os bens (artefatos) nas fronteiras geográficas de forma segura no ambiente de DDS. Muitos dos sistemas de controle de versões atuais, tais como o Subversion, Git, CVS e Mercurial se baseiam na primeira versão do software, e utilizam com pouca ênfase a ferramenta CASE (ferramentas que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes), sendo a maioria preocupados com questões de implementação e teste, o que ocasiona uma pouca importância com a natureza dessas implementações, que geralmente é o código fonte. Muitas ferramentas sejam de controle de versão ou de controle de mudança, que fornecem funcionalidades do GC estão disponíveis no mercado, mas estas não dão suporte

5 direto para um versionamento explícito, ou seja, um versionamento totalmente detalhado e perfeccionista, principalmente quando diz respeito ao controle de versão de projetos com um alto nível de complexidade, que ocorre na maioria dos casos de DDS. GC é uma das melhores práticas para enfrentar os desafios globais sobre os processos de desenvolvimento de software e organizações, devido a pouca interação e comunicação direta em um ambiente de DDS. Infelizmente, muitos sistemas de controle de versão atuais estão focados em documentos textuais, que limitam o detalhamento explicito da versão, visto que artefatos de software também incluem vários documentos com uma estrutura hierárquica e estão envolvidos em diversas relações com outros artefatos, e tais informações não são bem tratadas pelas ferramentas disponíveis atualmente. A Philips fez uma experiência de 10 anos com DDS, um trabalho derivado de 200 projetos. Ela encontrou alguns problemas no requisito Gerenciamento de Configurações, entre eles estão a falta de tempo para criar uma infraestrutura de GC, não havia gerentes de configurações competentes disponíveis e os procedimentos do gerenciamento de mudanças não estavam definidos, concluíram [4]. A experiência mostra que não é suficiente o tempo de preparação necessário para criar esta infraestrutura, resultando em tempo e esforços perdidos nos primeiros estágios do projeto. A elaboração e o controle dos sistemas complexos de GC necessários para o DDS exigem gerentes de configuração altamente competentes que trabalham em conjunto com os arquitetos e os integradores de forma intensiva. O nível exigido dos gerentes de configuração parece ser um recurso escasso e não está disponível em 50% dos casos, conforme [4]. Em seu trabalho, [1], dissertou que o tamanho e a complexidade dos projetos de software têm aumentado drasticamente ao passar dos anos. Ainda segundo [1], para realizar um controle de versão, as organizações geralmente obtêm um snapshot dos arquivos mestres e armazenam-no em um site principal, e através desse site repassam o arquivo para outros locais geograficamente distantes. Se forem feitas alterações em um local remoto, as versões modificadas devem ser cuidadosamente integradas de volta para os arquivos mestre no site principal. O processo é em grande parte manual e sujeito a erros, especialmente se vários sites estão fazendo mudanças para os arquivos de mesma origem. Com diversos sites sendo responsáveis por diferentes tarefas de desenvolvimento num arquivo de origem igual, pode ser difícil saber a versão mais atual da cópia mestre. Várias abordagens para coordenar o desenvolvimento distribuído de software em relação ao controle de versão são conhecidas. Uma abordagem simples envolve o fornecimento de usuários em todos locais com acesso a um repositório centralizado e compartilhado (incluindo bases de dados e armazenamento de dados de versão) através de uma rede WAN (Wide area network), que nada mais é do que uma rede de longa distância. Esta abordagem tem problemas de utilização significativas, entre elas incluem-se a vulnerabilidade a problemas de rede, devido à necessidade de acesso frequente ao repositório central, a velocidade de desempenho inaceitável devido à frequentes acessos ao repositório central com uma largura de banda WAN relativamente baixa, e problemas de escala para sistemas que possuem um grande número de utilizadores que requerem o acesso remoto a um repositório central, uma vez que a carga sobre o servidor central aumenta com o número de utilizadores na rede. Um sistema de GC que não está bem preparado tende a causar problemas como enormes transferências de dados entre os sites, que por sua vez provoca longos períodos de espera e, assim, a irritação entre os desenvolvedores, por exemplo.

6 CONCLUSÕES A gestão de configuração em ambientes de desenvolvimento distribuído de software é uma ferramenta essencial para a execução eficaz do projeto. É fato que tal área contribui nos projetos de sistemas, estando este incluso em modelos de maturidade de desenvolvimento de software. Em ambientes de desenvolvimento distribuído, a gestão de configurações torna-se mais complexa. Esta complexidade está relacionada fortemente a distribuição das equipes de desenvolvimento. Um mesmo processo de CM precisa ser especificado e difundido para todas as unidades de produção. Ainda, no caso de controle de versões, uma estrutura precisa ser definida. O modelo de controle de versões centralizado pode atender o DDS, entretanto corre-se o risco de indisponibilidades da rede. Seja qual for o motivo de indisponibilidades ataques, problemas no link, sobrecarga no servidor pode comprometer o andamento do projeto, estagnando todos os sites de produção. Um ambiente distribuído de controle de versões pode minimizar este problema, mas politicas de sincronização precisam ser definidas e implantadas. A execução de um projeto distribuído não necessariamente é linear. Vários componentes interdependentes podem, por meio de interfaces, serem implementados e integrados. O modelo ideal de controle de versões em um ambiente de DDS deve ter a capacidade de gerenciar, além das características convencionais de um repositório de versões como branch, merge deve ser capaz de gerenciar segmentos do projeto em cada site de produção e sincronizar tais segmentos de maneira a manter a consistência do projeto de software. REFERÊNCIAS [1] ALLEN, L. W.; FERNANDEZ, G. L.; KANE, K. P.. Version Control System For Geographically Distributed Software Development. United States Patent, P. 18. [2] BRUEGGE, B. al. Supporting Distributed Software Development with fine-grained Artefact Management. In: INTERNATIONAL CONFERENCE ON GLOBAL SOFTWARE ENGINEERING, , 2006, Florianópolis, São Paulo. Proceedings.Garching B. München: IEEE, p [3] CARMEL, E.; AGARWAL, R.. Tactical Approaches for Alleviating Distance in Global Software Development. IEE Software, v. 18, n.2. março/abril p [4] KOMMEREN, R.; PARVIAINEN, P.. Philips experiences in global distributed software development. Eindhoven: Empir Software Eng, P. 14 [5] L'ERARIO, A.. M3DS: um modelo de dinâmica de desenvolvimento distribuído de software f. Tese (Doutorado) - Usp, São Paulo, [6] L ERARIO, A.; FERREIRA, M. O; FABRETTI, H. D..et al. Um framework para o ensino de desenvolvimento distribuído de software em cursos de graduação. In: COBENGE - Congresso Brasileiro de Educação em Engenharia. Belém PA, [7] PRESSMAN, R. S. Engenharia de Software. 5a edição, Editora McGraw-Hill, 2002 [8] PRIKLADNICKI, R.. Desenvolvimento Distribuído de Software e Processos de Desenvolvimento de Software f. Trabalho Individual II, FACIN PPGCC, PUCRS, Porto Alegre, Ago [9] SA, J.; MASLOVA, E.. A unified Process Support Framework for Global Software Development. In: INTERNATIONAL COMPUTER SOFTWARE AND

7 APPLICATIONS CONFERENCE, 26, Oxford. Proceedings Oxford: IEEE, 2002.p.1-2. [10] SILVA, C. A..DiSEN-SCV: gerenciador de versões de artefatos para um ambiente de desenvolvimento distribuído de software. Tese de Mestrado, UEM, Maringá, [11] SOMMERVILLE, I. (Ed.). Gerenciamento: Gerenciamento de Configurações. In: SOMMERVILLE, I.. Engenharia de Software.8. ed. São Paulo: Pearson Addison - Wesley, p [12] STEINMACHER, I.; WIESE, I. C.; POZZA, R. ; HUZITA, E. H. M. ; AMORIM, E. F. ; PASCUTTI, M. C. D.. Uma Proposta de Arquitetura para Ambientes de Desenvolvimento Distribuído de Software. XI Congreso Argentino de Ciencias de La Computacion (CACIC), 2005, Entre Ríos. XI Congreso Argentino de Ciencias de La Computacion (CACIC), 2005.