Peter Feiler [FEILER, 1991] examinou alguns sistemas comerciais que possuíam funcionalidades da gerência de configuração e os classificou em quatro modelos: O Modelo
Checkout/Checkin, o Modelo Composição, o Modelo Transação Longa e o Modelo Conjunto de Mudança. Essa classificação é baseada na observação de alguns padrões de suporte da biblioteca central que contém os objetos (repositório), e que estão sob o controle de gerência de configuração. Atualmente os sistemas de GCS estão essencialmente baseados em um desses modelos [ZELLER, 1996]. A seguir são apresentados os dois modelos mais comuns de Feiler – Checkout/Checkin e de Composição.
Checkout/Checkin
O modelo Checkout/checkin é antigo e muito comum, sendo implementado até hoje por ferramentas tradicionais como SCCS [ROCHKIND, 1975] e a Revision Controle System (RCS) [TICHY, 1985].
Esse modelo oferece gerência de versão para componentes individuais (arquivos, módulos de sistema). Seu apoio a GCS é exemplificado pelos sistemas SCCS e RCS. Tais sistemas de GCS consistem de duas ferramentas relativamente independentes: o repositório e a construção (Figura 3.6). A ferramenta repositório armazena versões de arquivos e provê mecanismos para controlar a criação de novas versões. A ferramenta construção, dada uma descrição dos componentes que compõem um produto, ela automatiza a geração de componentes derivados, tais como código-objeto e executáveis link-editados, através do uso de ferramentas para os componentes-fontes e componentes-objetos, respectivamente.
Figura 3.6. Modelo operacional Checkout/checkin [FEILER, 1991].
Nesse modelo o usuário trabalha com um repositório e com o sistema de arquivo. Os arquivos são revestidos de versão e armazenados no repositório. A criação de versões novas é controlada pela ferramenta repositório. Os arquivos não são diretamente acessados no repositório. Os usuários têm de recuperar (Checkout) uma versão de um arquivo dentro do seu diretório de trabalho, a fim de acessar seu conteúdo. Esses arquivos podem ser recuperados para acesso de leitura, por exemplo, para o caso do usuário examinar um documento de projeto. Pode ser acessado também por um compilador ou linker e ainda com permissão de acesso para escrita. Nesse caso mecanismos de controle de concorrência do repositório coordenam recuperações múltiplas para modificação. Arquivos modificados podem ser armazenados de volta (Checkin) para o repositório, resultando em uma versão nova do arquivo.
A capacidade do modelo Checkout/checkin focaliza a manutenção do histórico de arquivos individuais e o controle das modificações concorrentes.
O modelo Checkout/checkin fornece as seguintes primitivas conceituais de atualização de versão de arquivos: evolução do histórico de versão seqüencial (referida como revisões); criação de ramos de versões, isto é, seqüências de versões que têm como ponto inicial uma versão particular de um ramo, mas que evoluem independentemente (referidas como variantes); e intercalação (merge) de duas versões de ramos diferentes dentro de uma nova versão em um dos ramos. O resultado é um histórico de versão para arquivos que tem uma estrutura em forma de grafo. Essa estrutura é chamada de grafo de versões.
Esse modelo possibilita também a recuperação concorrente de arquivos do repositório, com uso de mecanismos de proteção contra modificação (lock) e intercalação de variantes. Modelo Composição
O modelo Composição é um resultado natural do modelo Checkout/checkin. Ele também conta com as noções de repositório e área de trabalho, e com o controle de concorrência por meio da proteção de acesso aos componentes. Seu enfoque é a construção de configuração de sistemas através de seleção de versões alternativas (Figura 3.7).
Figura 3.7. Estrutura do modelo composição.
Uma configuração nessa abordagem consiste de um modelo de sistemas e regras de seleção de versão. Um modelo de sistema lista todos os componentes que o formam. As regras de seleção de versão indicam qual a versão de um componente deve ser selecionada para formar uma configuração. O modo de operação nesse modelo pode ser resumido da seguinte maneira: Os desenvolvedores definem quais os componentes fazem parte de um sistema e, num segundo momento, selecionam uma versão apropriada de cada componente. Esse modo de operação para lidar com versões é ilustrado na Figura 3.8.
Figura 3.8. Seleção de um componente da versão.
O Modelo Composição auxilia a GCS mantendo históricos das versões de sistemas e componentes. Colabora ainda permitindo a seleção de versões de componentes que resultem em uma configuração consistente. Uma configuração é considerada consistente se a versão selecionada de um componente for igualmente consistente com a versão selecionada de outros componentes (integração).
Esse modelo apóia também o desenvolvimento cooperativo. Para isso emprega operações de retirada (checkout) e devolução (checkin), proteção contra modificação (lock) e compartilhamento de módulos de programa.
3.11 Considerações finais
Este capítulo apresentou uma visão geral sobre gerência de configuração de software (GCS) incluindo o papel importante que ela desempenha para a engenharia de software. A GCS provê coordenação e estabilidade ao desenvolvimento, permitindo aumento da produtividade no trabalho cooperativo e proporcionando melhor visibilidade e controle da evolução do produto.
Embora amadurecidas, as ferramentas e ambientes de GCS disponíveis comercialmente assistem o desenvolvimento de software provendo apenas o controle de versão e raramente o controle de mudanças. Ainda são deficientes em disciplinar o processo de desenvolvimento, ou seja, conduzir a execução de atividades, a criação e uso de objetos de software em conformidade com as exigências de cada fase do ciclo de vida. Além disso, as ferramentas estão limitadas a relatar o estado de componentes isoladamente, desprezando o contexto em que a evolução ocorreu.
Por outro lado, a tendência na utilização de modelos de avaliação e melhoria da qualidade de software vem colaborando para a evolução do processo de GCS independente da ferramenta utilizada. Portanto, a Gerência de Configuração de Software não deve ser vista isoladamente dos outros problemas e soluções do domínio da engenharia de software, sob pena de causar o efeito inverso ao pretendido pelos programas de melhoria da qualidade de software.
GCS é uma etapa chave para qualquer projeto de software. O grau de controle da gerência de configuração dependerá do tamanho do projeto e dos recursos disponíveis. Deve- se procurar um meio termo entre muito controle e controle insuficiente. Controlar demais poderá gerar demasiada burocracia para o projeto. Controle insuficiente poderá fazer com que o projeto torne-se caótico e nunca seja completado.
O plano de GCS deve ser flexível o suficiente para permitir modificações durante todo o ciclo de vida do projeto. A GCS requer esforço e recursos, mas os resultados compensam o investimento, por exemplo, reduzindo o retrabalho de forma a diminuir a necessidade de reimplantar código que tenha sido perdido quando mais de uma pessoa desenvolveu concorrentemente um mesmo programa. Ajuda também a rastrear e identificar as mudanças ocorridas durante o desenvolvimento.
Nesse contexto, a implementação da gerência de configuração de software de forma planejada, utilizando padrões estabelecidos, é fundamental para alcançar seus objetivos. Sendo considerada chave para a área de engenharia de software, é provável que quando corretamente planejada e implementada contribua efetivamente para o aumento da qualidade do software.
Neste capítulo são feitas considerações a respeito do ambiente que originou o estudo de caso. É apresentada a estratégia global de implementação do programa de melhoria. Também são descritos os detalhes e resultados da fase de diagnóstico da organização. São também mostrados os resultados da utilização de um método científico para melhoria de processo de software. Por fim, é apresentado o mapa de melhoria obtido a partir da estratégia formulada.
4.1 Introdução
A proposta de melhoria da qualidade de software no TST foi guiada por três diretrizes – compatibilidade organizacional, adaptabilidade ambiental e sustentabilidade. Ou seja, as ações desenvolvidas deveriam ter afinidade com o negócio da organização, serem compatíveis com as suas metas estratégicas e terem capacidade de sustentação ao longo do tempo.
Em qualquer programa de melhoria da qualidade de software é importante conhecer previamente o ambiente a ser melhorado, para que se possa identificar o caminho que conduza mais facilmente ao alcance dos objetivos. Ou seja, os objetivos de um programa de melhoria devem estar perfeitamente alinhados com as metas de negócio da organização, mormente se a atividade fim dela não for a produção de software.
Nessa perspectiva, a proposta de melhoria foi formulada considerando a natureza da organização, sua estrutura administrativa e o perfil técnico de seus funcionários. Também foram consideradas questões relativas à cultura organizacional, anseios da gerência, bem como os benefícios palpáveis que poderiam ser alcançados dentro da realidade vivida pela organização.