Sumário
INTRODUÇÃO
Objetivos Gerais
Objetivos Específicos
CAPÍTULO I – Gerência de Configuração
1 – Conceitos Fundamentais
1.1 – Gerenciamento de Mudanças
1.2 – Gerenciamento de Versões
1.2.1 – Codelines
1.2.2 – Baselines
1.2.3 – Controlando Versões
1.3 – Construção de sistemas
1.4 – Gerenciamento de releases
CAPÍTULO II – Proposta de Gerência de Configuração
1 – Estruturação do ambiente
2 – Ambiente atual de desenvolvimento
3 – Tratamento de incidentes
3 – Proposta de gerência de configuração
CAPÍTULO III – Conclusão
CAPÍTULO IV – Referencias
INTRODUÇÃO
O desenvolvimento de softwares envolve várias etapas fundamentais para criação de um produto final com qualidade e dentro dos requisitos esperados pelo cliente.
Durante esse processo construtivo, o software sofre várias modificações em seu escopo inicial, podendo gerar várias releases, e dependendo da profundidade das alterações nos artefatos, uma nova versão do produto poderá ser disponibilizada ao cliente.
Dentro desse cenário de várias alterações, a gerência de configuração surge como uma ferramenta que possibilita manter a integridade do software de acordo com suas especificações durante seu desenvolvimento e ciclo de vida do software.
A complexidade envolvida no controle de dessas alterações, traduz a necessidade de ter um apoio sistematizado de ferramentas de colaboração de equipes e controle de versão.
A ausência desse tipo de ferramenta para projetos de software, não torna o produto final ineficiente, contudo agrega mais valor, confiança, segurança, qualidade e facilidade colaborativa entre os envolvidos no projeto.
Objetivos Gerais
Melhorar a capacidade da equipe de desenvolvimento de software e seus processos de controle de versões e releases durante e depois da entrega do produto final.
Objetivos Específicos
CAPÍTULO I – Gerência de Configuração
1 – Conceitos Fundamentais
A gestão de configuração de software é um conjunto de atividades que foram desenvolvidas para gerenciar alterações de todo o ciclo de vida de um software (Pressman, 2011).
As origens dessas alterações são variadas, bem como as próprias alterações. De acordo com Pressman (2011, p.515) há quatro fontes fundamentais de alterações:
Essas alterações podem surgir durante qualquer fase do projeto, mesmo que o produto já esteja em produção, a necessidade de novas modificações e atualizações é corriqueira. Diante desse cenário as metodologias de desenvolvimento de software devem estar prontas para lidar com essa realidade no mercado.
A mudança é inevitável em todos os grandes projetos de software. Os requisitos do sistema mudam ao mesmo tempo em que o negócio que adquiriu o sistema responde a pressões externas e mudam as prioridades de gerenciamento. Com a disponibilidade de novas tecnologias, emergem novos projetos e possibilidades de implementação (Sommerville, 2011).
O gerenciamento de configurações de um produto de sistema de software envolve quatro atividades afins (tabela 1):
Tabela 1 – Atividades de Gerenciamento de Configuração
Fonte: Sommerville (2011, p.476)
1.1 – Gerenciamento de Mudanças
O processo de mudança em muitos projetos é constante e determinam o sucesso ou fracasso do produto final esperado. As necessidades e requisitos organizacionais se alteram durante a vida útil de um sistema, bugs precisam ser reparados e os sistemas necessitam se adaptar às mudanças em seu ambiente (Sommerville, 2011).
Essa capacidade de absolver várias mudanças nos seus artefatos durante a fase de levantamento de requisitos, desenvolvimento e produção obriga as organizações a apoiarem o mecanismo de controle e proteção do produto do software. Esse processo é necessário devido o custos elevados que essa mudança pode gerar e qual seu impacto nos componentes associados direta ou indiretamente.
Pensando na importância desse controle Sommerville (2011, p.479) propõem um modelo básico de formulário de solicitação de mudança (tabela 2):
Tabela 2 – Formulário básico de solicitação de mudança Formulário de Solicitação de Mudanças
Fonte: Sommerville (2011, p.479)
1.2 – Gerenciamento de Versões
O gerenciamento de versões (VM, do inglês version management) é o processo de acompanhamento de diferentes versões de componentes de software ou itens de configuração e os sistemas em que esses componentes são usados (Sommerville, 2011).
Adotando um modelo de gestão de versões as organizações garantem que as mudanças realizadas nos artefatos para vários desenvolvedores não sofra interferência uma das outras, sendo tratadas como codelines e baseline.
1.2.1 – Codelines
É uma sequência de versões de código-fonte com versões posteriores na sequência derivadas de versões anteriores. Normalmente, as codelines são aplicadas para componentes de sistemas, havendo, assim, diferentes versões de cada componente.
1.2.2 – Baselines
Uma baseline é uma definição de um sistema específico. A baseline, portanto, especifica a versão de cada componente incluída no sistema, mais uma especificação das bibliotecas usadas, arquivos de configuração etc.
As baselines podem ser especificadas usando-se uma linguagem de que lhe permite definir quais componentes estão incluídos em uma versão de um determinado sistema. É possível especificar explicitamente a versão de um componente específico (X.1.2, por exemplo) ou, simplesmente, especificar o identificador de componente (X). Se você usar o identificador, isso significa que a versão mais recente do componente deve ser usada na baseline.
1.2.3 – Controlando Versões
Esses mecanismos de identificação apoiam a gerência de configuração durante todas as áreas de desenvolvimento do software e liberação para usuário final, pois muitas das vezes é preciso recriar uma versão específica de um sistema completo.
Para auxiliar nessa tarefa é importante que as áreas apoiem em ferramentas capazes de identificar, armazenar e controlar o acesso a diferentes versões de componentes.
Normalmente as ferramentas de gerenciamento de versões fornecem uma variedade de recursos, vide (tabela 3):
Tabela 3 – 5 recursos básicos de ferramenta de controle de versões
Fonte: Sommerville (2011, p.482)
1.3 – Construção de sistemas
A construção de sistemas é o processo da criação de um sistema completo, executável por meio da construção e ligação dos componentes de sistema, bibliotecas externas, arquivos de configuração etc. As ferramentas de construção de sistemas e as ferramentas de gerenciamento de versões devem se comunicar na medida em que o processo de construção envolve a realização de check-out de versões de componentes do repositório pelo sistema de gerenciamento de versões (Sommerville, 2011).
A complexidade envolvida na construção de sistemas e o relacionamento com os componentes geram potencialmente erros e falhas no seu desenvolvimento. Para construção segura e dentro de padrões de qualidade esperados devem-se observar três diferentes aspectos de sistemas disponíveis:
1. Sistema de desenvolvimento: Abranger ferramentas como compiladores, editores de códigos-fontes, revisores de erros etc. Usando essas ferramentas os desenvolvedores devem realizar o check-out que estão trabalhando em um repositório privado sem interferência da produção, observando o cumprimento das diretrizes de controle de versões.
2. Servidor de construção: Utilizado para criação de versões definitivas do produto, integrado com o controle de versões, onde cada desenvolvedor realiza o check-in no sistema de gerenciamento de versões antes dos sistemas serem construídos.
3. Ambiente alvo: É a plataforma que o software será executado, podendo o produto ser do mesmo tipo do ambiente de desenvolvimento ou produção. Em ambos os casos os testes devem ser realizados em ambientes diferentes para evitar incompatibilidade da versão.
Quanto mais informações reunidas sobre o software e seu ambiente operacional, menores serão as possibilidades de problemas com as versões disponibilizadas aos usuários finais. Para auxiliar nesse processo as ferramentas automatizadas de construção proporciona maior agilidade na entrega final do produto.
Analisando as ferramentas de construção, algumas características básicas são fundamentais:
Essa visão permite controlar as inúmeras versões geradas pelos desenvolvedores no projeto e aderências às políticas de qualidade esperadas no desenvolvimento de software.
Os métodos ágeis têm uma visão que a construção de sistema frequentes devem ser feitas com testes automatizados, conhecidos como testes fumaça, capazes de descobrir os problemas de software. Essa constante atualização e gestão de versões abre caminho para integração continua dos componentes e capacidade para resolução dos problemas causados pelas interações entre diferentes desenvolvedores sejam detectados e reparados o mais rápido possível.
1.4 – Gerenciamento de releases
Um release de sistema é uma versão de um sistema de software distribuída aos clientes. Para softwares de mercado de massa, é normalmente possível identificar dois tipos de releases, chamados releases principais, que fornecem nova e significativa funcionalidade, e releases menores, que reparam bugs e corrigem problemas de clientes que foram relatados (Sommerville, 2011).
Dessa forma o gerenciamento de releases é um processo complexo, e requer uma documentação de controle para garantir que ela possa ser recriada no futuro em decorrência de problemas. É muito comum em grandes sistemas haver várias ou inúmeras releases sendo usadas ao mesmo tempo pelos usuários, e a gerencia de configuração tem o papel de identificar qual release cada cliente está utilizando.
Para documentar um release, devem-se gravar as versões específicas dos componentes de código-fonte que foram usadas para criar o código executável. Manter cópias dos arquivos de código-fonte executáveis correspondentes e todos os dados e arquivos de configuração. Gravar as versões do sistema operacional, bibliotecas, compiladores e outras ferramentas usadas para construir o software. Estas podem ser necessárias para construir exatamente o mesmo sistema em uma data posterior. Isso pode significar que você precisa armazenar cópias de plataforma de software e as ferramentas usadas para criar o sistema no sistema de gerenciamento de versões junto com o código-fonte do sistema-alvo (Sommerville, 2011).
Esse processo é fundamental para garantir a segurança e qualidade do produto do software e sobre tudo a confiança e disponibilidade do software para o usuário quando necessário. A adoção desse processo muitas vezes requer um investimento técnico, logístico, marketing e operacional para alcançar uma fatia do mercado.
Muitas barreiras podem surgir durante o planejamento e lançamento de uma nova release aos consumidores, Sommerville (2011, p.489) destaca 5 fatores que influenciam o planejamento de release de sistema:
Todos esses cuidados são fundamentais no lançamento de novas releases e ajudam na transparência da organização, bem como na qualidade final do produto do software. Contudo em inúmeras vezes os usuários não querem instalar uma nova release do produto, pois estão felizes com o sistema existente, fazendo com que as empresas detentoras dos softwares mantenha disponível a release em seu repositório de segurança e também para o cliente.
CAPÍTULO II – Proposta de Gerência de Configuração
1 – Estruturação do ambiente
Para iniciar o processo de gerência de configuração na empresa é necessária uma estabilização do parque tecnológico (computadores, servidores, softwares etc.), permitindo identificar os possíveis impedimentos iniciais na implantação do processo.
Dentro da proposta é fundamental identificar as competências dos colaboradores envolvidos diretamente no ciclo de desenvolvimento de software na organização, para criar um ambiente capaz de suportar mudanças profundas nas rotinas a serem implantadas na empresa, (foto 1):
Fonte: Elaborado pelo autor
Diante dessa avaliação básica poderemos reverter inicialmente erros e falhas na capacidade de infraestrutura da empresa e melhorar as competências nas ferramentas necessárias ao desenvolvimento de software.
2 – Ambiente atual de desenvolvimento
A empresa tem dois ambientes, um de desenvolvimento e outro de produção, não há um controle de versionamento do código fonte e nem ambiente específico de testes antes da implantação em produção, (figura 2):
Figura 2 – Ambiente atual de desenvolvimento
Fonte: Elaborado pelo autor
3 – Tratamento de incidentes
Os incidentes são direcionados diretamente á equipe de desenvolvimento, que fará os ajustes na última versão estável do sistema, sem nenhuma preocupação no controle de versões, padrões de qualidade e segurança esperados nessa alteração requerida.
Após realizados os ajustes necessários a nova versão é testada pelos próprios desenvolvedores, que na sequencia disponibiliza para área de produção. Havendo o surgimento de falhas ou erros apontados pelos usuários o software volta para equipe de desenvolvimento até solução do problema, (figura 3):
O modelo utilizado pela empresa não é satisfatório, pois os incidentes são direcionados diretamente aos desenvolvedores, que não são os especialistas indicados para realizar uma análise preliminar no questionamento de possíveis anomalias com os requisitos.
3 – Proposta de gerência de configuração
A proposta inicial é implantar uma área responsável pela elicitação dos requisitos e possíveis testes preliminares antes de se reconhecer o incidente como um problema. Também há a necessidade de um versionamento do código fonte a ser alterado de forma que se mantenha um histórico das alterações pelas quais o software passou e a possibilidade de se recuperar uma versão anterior caso seja necessário.
Deve-se criar um ambiente para homologação onde as alterações realizadas possam ser testadas sem interferência dos outros ambientes e um servidor de construção, onde se replicam todas as configurações e características encontradas em produção (figura 4):
Seguindo o processo proposto a empresa melhora significativamente seu processo de desenvolvimento de software agregando características fundamentais de gerenciamento de configuração, incorporando maior segurança, controle, qualidade e estabilidade no ciclo de desenvolvimento de software.
Diante das quatro atividades de gerenciamento de configuração, (gerenciamento de mudanças, versões, construção do sistema e releases) a proposta proporciona direcionamento da equipe de desenvolvimento, seja utilizando as metodologias tradicionais ou ágeis.
CAPÍTULO III – Conclusão
A gerência de configuração em muitos projetos de softwares é esquecida por falta de um processo detalhado e equilibrado dos fluxos de tarefas e caminhos que se deve percorrer até a entrega do produto.
Com adoção do modelo proposto a organização é capaz de cumprir com as quatro atividades de gerência de configuração descritas por Sommerville nesse estudo. Além de mapear e reestruturar a infraestrutura de hardware e software caso seja necessário, antes mesmo de iniciar uma mudança profunda nos processos de desenvolvimento de software.
Outro ponto de destaque desse estudo é capacidade da empresa em enxergar as competências dos indivíduos diretamente envolvidos no projeto, criando um ambiente altamente competitivo, pela aplicação de treinamentos e restruturação caso seja necessário do quadro efetivo de colaboradores.
Tendo ambientes diferentes de desenvolvimento, teste e construção os desenvolvedores e usuários terão maior produtividades na execução das tarefas, e menor incidência de erros e falhas no funcionamento esperado do software, histórico de versões, releases e garantia de não interferência dos ambientes durante e depois o lançamento do produto final.
CAPÍTULO IV – Referências
Sommerville, Ian. Engenharia de Software 9. ed. – São Paulo, SP: Pearson Prentice Hall, 2011.
Pressman, Roger. Engenharia de Software: Uma abordagem professional 7. ed. – Porto Alegre, RS: AMGH, 2011.
Artigo Redigido pelos Alunos da Pós-Graduação do Curso de “Engenharia de Software” da UNINOVE
Trabalho de Conclusão do Módulo de Gerência da Configuração apresentado à Universidade Nove de Julho como parte dos requisitos para obtenção do Título de Especialista em Engenharia de Software.
Gerente de Projetos SR., atua há mais de 20 anos na área de TI no seguimento do Governo do Estado de São Paulo. Desenvolveu atividades de desenvolvimento de Software para empresas brasileiras e multinacionais, tendo participando no Brasil e no exterior em projetos de TI de diversos segmentos como Educacional, Financeiro, Saúde, Tributário e Terceiro Setor. Professor de Pós-Graduação na UNINOVE nos cursos de Qualidade, Gerencia de Configuração, Requisitos, Gerenciamento de Projetos e Processo de Desenvolvimento Ágil Formado na PUC de Campinas, Pós-Graduação em Administração Hospitalar (Univ.São Camilo), Gerenciamento de Projetos (UNICAMP), Projetos Estruturados (USP), Ciência, Tecnologia e Inovação (USP). MBA em Gestão de TI na FIAP e Programa de Desenvolvimento Gerencial com foco em liderança estratégica - FIA, atualmente aluno de MESTRADO da UNINOVE na área de Gestão do Conhecimento. Formado em COACH para SBC - Sociedade Brasileira de Coaching e Master COACH pelo escola RICCOACHING.
You must be logged in to post a comment.
10:02:06 am
Muito bom o artigo, só um adendo: falando em métodos ágeis, a integração contínua, e entrega contínua, auxilia muito no processo de gestão da configuração do software, fora a aferição da qualidade do código.