Uma Proposta de Estratégia para a Implantação da Gerência de Configuração de Software em Empresas de Médio Porte

Jorge Marcos Fernandes - Universidade Federal do Rio de Janeiro (UFRJ)

jorggefernandes@gmail.com

1. Introdução

Nos últimos anos a tecnologia avançou significativamente e, em paralelo, os projetos de desenvolvimento de software aumentaram constantemente de tamanho e complexidade. Proporcionalmente a este avanço, o número de problemas enfrentados no desenvolvimento do software também aumentou. Atualmente, os produtos de software são vitais para a sobrevivência das empresas independente do ramo de negócio em que ela atue. O desenvolvimento de software deixou de ser uma atividade de suporte às áreas fins das empresas para ser visto como uma importante área de negócio que precisa ser cuidadosamente analisada e constantemente melhorada.

            De acordo com GALIN [2004], não seguir padrões determinados pela GQS^[1] ou não ter atividades relacionadas à mesma, faz com que o software freqüentemente seja produzido com baixa qualidade, levando-o a ter características, como por exemplo: falhas e indisponibilidades freqüentes, altos custos na detecção e remoção de defeitos.

            Frente às exigências e à competitividade impostas atualmente pelo mercado globalizado, a qualidade dos produtos deixou de ser apenas um diferencial e se tornou um pré-requisito exigido muitas vezes para efetivar vendas de projetos. Embora esta realidade ainda ocorra com mais freqüência nas exportações de software, o mercado interno começa a sofrer mudanças no sentido de convergir para este novo contexto.

            Segundo MACHADO (2001), para muitos engenheiros de software, a qualidade do processo de software é tão importante quanto a qualidade do produto. Assim na década de 90 houve uma grande preocupação com a modelagem e melhorias no processo de software. Abordagens importantes como as normas ISO 9000 e a ISO / IEC 12207, o modelo CMM (Capability Maturity Model) e o SPICE (Software Process Improvement and Capability dEtermination) sugerem que melhorando o processo de software, podemos melhorar a qualidade dos produtos.

            MACHADO (2001) ressalta ainda, que a globalização da economia vem influenciando as empresas produtoras e prestadoras de serviços de software a alcançar o patamar de qualidade e produtividade internacional para enfrentarem uma competitividade cada vez maior.

            PRESSMAN (2006) afirma que diante deste fato, por falta de utilização das normas ou modelos de qualidade de software, as empresas produzem softwares de qualidade contestável.

            A Gerência de Configuração de Software (GCS) é um processo que tem suas atividades relacionadas à Gestão da Qualidade e que está presente em praticamente todos os modelos de qualidade de software. Neste sentido, o maior controle dos produtos de software proporcionado pela GCS contribui para um aumento de qualidade dos projetos de software.

            Cada modelo de qualidade aborda a GCS de uma forma diferente. Uma correta customização do modelo escolhido, mesmo que não se implante todos os requisitos definidos por este, pode representar um diferencial para a empresa. Desta forma, as pequenas e médias empresas, que possuem restrições sérias quanto a recursos financeiros e humanos, também podem ser beneficiadas com a implantação da GCS.

            Muitas pretensas implantações da GCS, de forma errônea, consideram apenas usar uma ferramenta de gestão de configuração, principalmente para controle de versões. Desta forma, a maior parte das abordagens atuais para GCS são focadas apenas no código fonte. Todavia, a compreensão dos sistemas de informação desenvolvidos atualmente tem um complicador, a complexidade envolvida.

            A falta da GCS propicia um total desconhecimento do produto de software a ser desenvolvido. Aliado a isso, a falta da gerência de mudanças, leva a perda de controle na produção de artefatos de software, durante o processo de desenvolvimento ou manutenção de sistemas de informação.

            As organizações enfrentam uma grande dificuldade em adotar conceitos e práticas para a implantação da GCS, já que as atividades envolvidas neste processo são complexas, envolvem a definição de uma abordagem adequada e a seleção de uma ferramenta de apoio ao processo. O impedimento para a implantação da GCS, muitas vezes está relacionado a fatores ligados a investimentos financeiros e humanos, tão escassos nas organizações atualmente. Por outro lado, os modelos de qualidade de software especificam detalhadamente “O QUÊ” deve ser feito, enquanto o mercado muitas vezes, se pergunta “COMO” fazê-lo.

            Mas como implantar a GCS em empresas de pequeno e médio porte adotando uma solução própria, face às restrições de investimentos financeiros que impedem a contratação de consultoria especializada ?

2. Gerência de Configuração de Software

2.1. Definição de GCS

A GCS visa estabelecer e manter a integridade dos artefatos de software, sob sua gerência, ao longo de todo o ciclo de vida do software, através de mecanismos que permitam administrar as diferentes versões, controlar modificações e permitir a realização de auditorias e a elaboração de relatórios sobre o estado da configuração.

            LEON (2000) define a GCS como uma disciplina que identifica a configuração de um sistema em pontos discretos no tempo, com o objetivo de controlar sistematicamente as mudanças dessas configurações e manter a integridade e a rastreabilidade do ciclo de vida do sistema.

            Para PRESSMAN (2006), a GCS é a arte de identificar, organizar e controlar alterações no software que está sendo construído por uma equipe de programadores. È necessário: identificar as mudanças, controlar as mudanças, assegurar que as mudanças estão sendo implementadas e reportadas aos interessados. A GCS ocorre em todo o ciclo de vida de um software, desde seu desenvolvimento inicial até o momento em que sai de operação. No período de manutenção, a GCS também deve ser realizada.

2.2. Item de Configuração de Software (ICS)

Um ICS é um artefato concluído, avaliado e entregue para compor uma determinada versão^[2] da configuração, controlado e integrante de uma determinada baseline do projeto. Além disso, visando um controle destes ICS e artefatos em níveis de abstração, estes podem ser classificados ou categorizados, segundo determinadas características inerentes a ambos, como por exemplo: Especificação do Sistema, Especificação de Requisitos, tabelas, classes e etc.

            Segundo a IEEE (1990), a configuração de software representa o conjunto de características físicas e funcionais de software, conforme estabelecidas em algum documento técnico ou realizadas por um produto desenvolvido em um projeto de software.

            PRESSMAN (2006) ressalta que esta configuração é composta por artefatos e ICS, sendo ambos gerados durante a execução das atividades de desenvolvimento de software, ou que sejam necessários para seu desenvolvimento. Os ICS são artefatos que podem ser identificados (versionados). Desta forma, os ICS, em um dado momento do projeto passaram a ter sua evolução controlada, ou seja, só poderão ser alterados mediante a uma prévia autorização dada por um responsável por controlar a configuração.

            Além disso, como as ferramentas utilizadas para editar ou modelar os ICS podem mudar ao longo do tempo, torna-se necessário identificá-las juntamente com suas respectivas  versões utilizadas. Evita-se, assim, que mudanças nas versões destas ferramentas (ferramentas CASE, editores de diagramas e de textos, compiladores, gerenciadores de banco de dados e etc) possam produzir resultados indesejados ou inesperados, por tanto diferentes da versão original. Desta forma, é igualmente importante colocá-las sob controle da configuração. Um software completo com todos os seus componentes e sua documentação também é um ICS. Desta forma, os ICS podem ser desenvolvidos ou comprados para integração no sistema.

2.3. Biblioteca de Software

Os artefatos e os ICS são armazenados em uma estrutura própria denominada biblioteca de software do projeto IEEE (2004).

            A IEEE (1990) e IEEE (2004) definem uma biblioteca de software como sendo uma coleção controlada de software e documentos a ela relacionadas, que auxilia o desenvolvimento, uso e manutenção do software, sendo também um instrumento utilizado para realizar atividades de distribuição e entrega do software. As técnicas e métodos, referentes às atividades de GCS, geralmente estão centradas no controle dessas bibliotecas.

2.4. Baseline (Linha Base)

PRESSMAN (2006) afirma que a linha base é um marco no desenvolvimento de software caracterizado pela liberação de um ou mais itens de configuração de software e a aprovação desses itens, obtida através de revisão técnica formal. No desenvolvimento de um produto de software podem ser definidas diversas linhas-base e em qualquer nível de detalhes.

            OLIVEIRA (2001), apresenta como exemplo de baseline, as fases do ciclo de vida de desenvolvimento de um software: Análise, Projeto, Codificação (Implementação), Testes, Entrega (Implantação), Operação e Manutenção. Ressalta ainda, que uma baseline tem como objetivo servir de referência para as próximas atividades do desenvolvimento, sendo um conceito lógico composto pelos ICS do projeto. Além disso, a baseline pode ser entregue ao cliente como sendo um resultado do projeto e neste caso é denominada distribuição (release).

            Segundo a IEEE (2005), uma baseline agrega ICS que funcionam corretamente em conjunto e serve como base para a próxima etapa de desenvolvimento.

2.5. Release (Distribuição)

Segundo a IEEE (2005), uma release é uma versão de baseline a ser entregue ao cliente.

3. Estratégia Proposta

Para a proposta, foram utilizadas várias características dos modelos CMMI e CMM, além de aspectos dos processos de GCS existentes no IEEE (1987), IEEE (2005) e IEEE (2004).

            O propósito desta estratégia é auxiliar a adoção das práticas de GCS visando uma transição do estado atual para o proposto pelo processo, evitando-se ao máximo qualquer tipo de trauma.

            A estratégia foi dividida em 4 fases (Iniciação, Planejamento, Implantação e Encerramento). Para cada fase deve-se realizar um conjunto específico de atividades e por fim, elaborar um relatório conclusivo de fase apresentando como foi realizada toda esta fase, relacionando os problemas enfrentados, as opções identificadas e ações adotadas. Este relatório deve ser armazenado no repositório de lições aprendidas.

            As fases possuem entradas e saídas. As entradas representam as informações necessárias à correta execução de cada atividade da fase, enquanto as saídas, representam as informações produzidas pela execução das atividades da fase que servirão de entrada para uma outra atividade. 

            O registro das lições aprendidas é de suma importância por representar o aprendizado e o conhecimento da organização adquirido durante o processo de implantação da GCS. Podem ser registrados, por exemplo, problemas, erros ou imprevistos ocorridos e as respectivas soluções adotadas para resolvê-los, além dos resultados referentes à solução adotada.         

3.1. Fase de Iniciação

Tem por objetivo definir e autorizar a implantação da GCS na organização. 

            As atividades desta fase, são: identificação das necessidades da organização a serem atendidas pela GCS, identificação dos interessados na implantação, identificação dos projetos de software da organização, obtenção de um patrocinador para o projeto e obtenção de apoio organizacional.

            A fase não tem entradas e termina com a conclusão de suas 5 saídas: relação de necessidades da organização, relação de interessados na implantação, relação de projetos de software da organização, patrocinador definido e apoio organizacional formalizado.

3.2. Fase de Planejamento

Tem por objetivo definir os processos e as ações necessárias à implantação da GCS. Estas especificações devem estar descritas no plano de GCS e em seus procedimentos de suporte.

            As atividades desta fase, são: definição dos objetivos e metas da organização, definição da equipe de GCS e suas responsabilidades, identificação da configuração do software, definição do processo de controle de mudanças, criação e organização da base de conhecimento necessária a GCS, definição do processo de auditoria da configuração, seleção da ferramenta de GCS, elaboração de um cronograma de implantação, seleção de um projeto-piloto para a implantação da GCS e elaboração do Plano de GCS.

            A fase tem como entradas as 5 saídas da fase anterior: relação de necessidades da organização, relação de interessados na implantação, relação de projetos de software da organização, patrocinador definido e apoio organizacional formalizado.

            A fase termina com a conclusão de suas 3 saídas: projeto-piloto selecionado, ferramenta de GCS selecionada e o Plano de GCS elaborado.

3.3. Fase de Implantação

Tem por objetivo realizar efetivamente a implantação da GCS, conforme definido no Plano de GCS.

            As atividades desta fase, são: formação da equipe de GCS, treinamento da equipe nos processos e na ferramenta de GCS, criação do ambiente de GCS, colocação da ferramenta de GCS em produção, monitoramento do processo de implantação, registro de lições aprendidas e elaboração do relatório de implantação.

            A fase tem como entradas as 3 saídas da fase anterior: projeto-piloto selecionado, ferramenta de GCS selecionada e o Plano de GCS elaborado.

            A fase termina com a conclusão de suas 3 saídas: registro de lições aprendidas, Plano de GCS alterado (se necessário) e o relatório de implantação elaborado.

3.4. Fase de Encerramento

Tem por objetivo formalizar a aceitação de conclusão da implantação da GCS, bem arquivar todos os documentos referentes à implantação.

            Nesta fase, as informações históricas e as informações sobre as lições aprendidas devem ser transferidas para a base de conhecimento de lições aprendidas objetivando sua utilização em futuras implantações.

            A fase tem como entradas as 3 saídas da fase anterior: registro de lições aprendidas, Plano de GCS alterado (se necessário) e o relatório de implantação elaborado.

            A fase não tem saídas e termina com a conclusão de todas as suas atividades.

            Com base na avaliação dos resultados obtidos, a empresa vai decidir se a implantação da GCS será estendida aos demais projetos de desenvolvimento de software.

4. Conclusão

As empresas brasileiras, em sua grande maioria, ainda ignoram completamente a existência dos processos e ferramentas de GCS. Em contra partida, algumas poucas empresas possuem interesse crescente pela GCS, motivadas pela busca de certificação de qualidade ou por necessidades geradas por competição de mercado, que cada vez mais exigem qualidade. Outras tantas empresas, acreditam que a implantação da GCS ocorre simplesmente pela adoção de ferramentas.

            As dificuldades das empresas em adotar conceitos e práticas para a implantação da GCS, estão muitas vezes relacionadas a fatores ligados a investimentos financeiros e humanos, tão escassos nas organizações atualmente. Em outros casos, estão relacionadas à complexidade envolvida neste processo, que exige a definição de uma abordagem adequada e a seleção de uma ferramenta de apoio ao processo. Via de regra, não se pode ignorar os custos e o acréscimo de formalismo de controle, oriundos deste processo.

            Uma forma de reduzir os custos e a complexidade envolvidos na implantação da GCS é customizar as práticas segundo as necessidades e disponibilidades de recursos e utilizar ferramentas mais acessíveis à realidade da empresa. Desta forma, o ideal é adotar um meio-termo entre muito e nenhum controle. Muito controle pode elevar os custos e a complexidade, além de gerar burocracia. Nenhum ou pouco controle, pode representar a permanência em um estado semelhante ao atual.

            Deve-se ressaltar que, da mesma forma que ocorre nos processos de melhoria da qualidade, a implantação da GCS e sua utilização não é tarefa fácil devendo ser vista como uma mudança de cultura organizacional e não como uma mera ferramenta ou procedimento a ser seguido. Desta forma, a falta ou insuficiência de comprometimento da alta gerência da empresa, pode inviabilizar sua utilização.

            Os benefícios trazidos pela implantação da GCS à qualidade do software produzido vão desde a diminuição do re-trabalho, passando pela facilidade de realizar manutenção do software durante todo o seu ciclo de vida, até a melhoria da produtividade. Neste ponto, mudanças simples podem ser realizadas em softwares complexos sem que haja perda de qualidade ou de funcionalidade. Da mesma forma, mudanças complexas podem ser feitas de forma pontual e gradativa, se tornando simples e ocorrendo sem dificuldades. Isso se traduz em flexibilidade e competitividade para a empresa, no que se refere à produção de software, frente ao mercado.

            Em linhas gerais, os custos e benefícios devem ser analisados, antes de se adotar as práticas da GCS. Deve-se levar em consideração que customizações podem ser realizadas nos processos de GCS e que ferramentas com menor custo podem ser adotadas, visando atender as necessidades e restrições impostas pela organização.

            Por fim, cabe ressaltar que a GCS não é a solução para todos os problemas de desenvolvimento de software, mas se for corretamente planejada, implantada e seguida, terá sua finalidade alcançada: melhorar a qualidade e a integridade do produto de software.

References

GALIN, DANIEL (2004). “Software Quality Assurance: From Theory to Implementation”, Pearson Education Limited.

IEEE (1997). “Guide to Software Configuration Management, ANSI/IEEE Std 1042”.

IEEE (1990), “Standard Glossary of Software Engineering Terminology, ANSI/IEEE Std 610”.

IEEE (2005), “Standard for Software Configuration Management Plans, ANSI/IEEE Std 828”.

IEEE (1990), “Standard Glossary of Software Engineering Terminology, ANSI/IEEE”.

IEEE (2004), “SWEBOK: Guide to the software Engineering Body of Knowledge”. 2004 version. Ed. Los Alamitos, California: IEEE Computer Society.

LEON, Alexis (2000). “A Guide to Software Configuration Management”. Ed. Artech House.

Machado, Cristina Ângela Filipak in WEBER, KIVAL CHAVES, et al (2001). “Qualidade e Produtividade em Software”, São Paulo, Ed. Makron Books.

OLIVEIRA, ANGELINA, A. A. C. P., et al (2001). “Gerência de Configuração de Software, Evolução do Software sob controle”, ITI – Instituto Nacional de Tecnologia da Informação, Laboratório de Avaliação e Melhoria de Processos de Software, Campinas – SP.

PRESSMAN, ROGER S. (2006) “Engenharia de Software, Rio de Janeiro”, 6a ed. McGraw-Hill.