Portfólio Desafio 1

Gerenciamento de Configurações

"Conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas. — Roger Pressman"

A gerência de configuração de software é definida por quatro funções básicas, Identificação, Documentação, Controle e Auditoria. No início do desenvolvimento, a GCS (Gerencia de Configuração de Software) permite à equipe de desenvolvimento identificar as unidades que compõem o sistema de acordo com as funcionalidades que elas deverão desempenhar, e as interfaces entre estas unidades, documentando assim a interação entre elas. O controle contínuo da evolução destas funcionalidades e interfaces permite que a integração entre estas unidades tenha sucesso continuado, com as mudanças devidamente gerenciadas e documentadas. Por fim, a auditoria das funcionalidades identificadas, documentadas e controladas garante a confiabilidade do sistema.

A gerência de mudanças é uma parte geralmente negligenciada da Gerência de configuração. Como ela não tem resultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam por não perceber sua importância. Gerência de mudanças entretanto é uma parte importante da Gerência de configuração, pois é a atividade que permite se saber o motivo de uma configuração ter sido mudada para outra configuração. Esta atividade também pode ser parcialmente automatizada, e diversos sistemas de controle de versão já são integrados com sistemas de gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada mudança efetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos em sistemas de software arquivos que listam as melhorias e mudanças entre duas versões. Estes arquivos são resultado da gerência de mudanças, identificando o que mudou entre uma versão e outra.

Exemplos
mudança da versão 1.0 para 1.1 inclui:
correção do problema 355
correção do problema 356
correção do problema 358
nova funcionalidade de impressão de relatórios
pendências para a versão 1.2:
correção das mudanças 357 e 359.
impressão de relatórios coloridos.


Ocorrem muitos problemas durante o desenvolvimento de software que são causados por falta de controle sobre os arquivos do projeto. O controle de versão rastreia e controla todos os artefatos do projeto (código-fonte, arquivos de configuração, documentação etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores através das seguintes funcionalidades:

Mantém e disponibiliza cada versão já produzida de cada item do projeto
Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existência de diferentes versões ao mesmo tempo (concorrência)
Estabelece uma política de sincronização de mudanças que evita a sobreposição de mudanças
Fornece um histórico completo de alterações sobre cada item do projeto
Controle de versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões de código, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriores e registro do histórico de alterações.

A finalidade do controle de versão é dar um controle maior sobre tudo que você altera no seu projeto de software. Ele permite que você tenha um histórico de tudo o que você mudar no seu projeto. Se você modificou aquela rotina para otimizar uma consulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que era exibida em determinada página html, tudo fica guardado neste histórico. Para que isso? Para o caso de sua alteração causar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudo correto, basta um simples comando e você recupera o estado anterior.

Todos os arquivos e diretórios que compõem o projeto ficam sob a responsabilidade do sistema de controle de versão num local denominado de repositório, lugar onde se guarda, arquiva, coleciona alguma coisa. É o local onde você vai guardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu pendrive. O repositório registra cada alteração realizada em cada arquivo e diretório controlado. À medida que o projeto evolui, o repositório passa a guardar múltiplas versões dos arquivos que compõem o projeto. Essas múltiplas versões são organizadas em revisões. Uma revisão funciona como um clone de todos os arquivos do projeto em um determinado momento do tempo. Os clone antigos são mantidos e podem ser recuperados e analisados a qualquer momento. Para economizar espaço, apenas as diferenças entre as revisões costumam ser armazenadas no repositório. Quando se deseja recuperar determinado arquivo, as diferenças são analisadas e o arquivo é remontado de acordo com a revisão desejada. Mesmo que não haja alteração em um arquivo entre uma revisão e outra, o número da revisão do arquivo acompanha o número da revisão global, de modo a manter sempre um grupo coeso e coerente de arquivos.

Alguns projetos precisam de variações específicas, conforme as necessidades específicas de cada cliente, ou criação de um ramo para experimentações no projeto, sem comprometer a linha principal de desenvolvimento. O sistema de controle de versão oferece funcionalidades que facilitam a coordenação de ramos diferentes de desenvolvimento em um mesmo projeto. As alterações feitas em um ramo muitas vezes precisam ser mescladas em outro ramo. Essa operação é bastante delicada e é facilitada em muito com o sistema de controle de versão, que permite bastante controle e automação no processo. Mesmo em caso de uma fusão malsucedida, o sistema de controle de versão permite voltar ao estado anterior, o que traz bastante segurança aos desenvolvedores.

Como os desenvolvedores trabalham em paralelo e concorrentemente nos mesmos arquivos do projeto, é necessária uma política para ordenar e integrar todas essas alterações, de modo a evitar que um desenvolvedor sobrescreva as alterações de outro desenvolvedor.O controle de versão além de rastrear e controlar alterações, também coordena a edição colaborativa e o compartilhamento de dados entre os vários desenvolvedores de uma equipe.



###############
Na prática:
###############

seguindo o mesmo raciocínio, citado/mencionado no tópico anterior, sobre a ideia do software de doação temos:


3.1.4 Gerenciamento de Configurações


Roger Pressman, faz citação sobre o Gerenciamento de Configuração dizendo: "Conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas."

A gerência de configuração de software é definida por quatro funções básicas, Identificação, Documentação, Controle e Auditoria. No início do desenvolvimento, a GCS (Gerencia de Configuração de Software) permite à equipe de desenvolvimento identificar as unidades que compõem o sistema de acordo com as funcionalidades que elas deverão desempenhar, e as interfaces entre estas unidades, documentando assim a interação entre elas. O controle contínuo da evolução destas funcionalidades e interfaces permite que a integração entre estas unidades tenha sucesso continuado, com as mudanças devidamente gerenciadas e documentadas. Por fim, a auditoria das funcionalidades identificadas, documentadas e controladas garante a confiabilidade do sistema.

A gerência de mudanças é uma parte geralmente negligenciada da Gerência de configuração. Como ela não tem resultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam por não perceber sua importância. Gerência de mudanças entretanto é uma parte importante da Gerência de configuração, pois é a atividade que permite se saber o motivo de uma configuração ter sido mudada para outra configuração. Esta atividade também pode ser parcialmente automatizada, e diversos sistemas de controle de versão já são integrados com sistemas de gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada mudança efetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos em sistemas de software arquivos que listam as melhorias e mudanças entre duas versões. Estes arquivos são resultado da gerência de mudanças, identificando o que mudou entre uma versão e outra.

A Integração Contínua, em suas necessidades, bastaria um controle de construção de software que cuidasse da identificação, empacotamento e preparação de uma baseline para a entrega a um cliente externo ou interno, tornando-a uma release ou uma build respectivamente. A ideia de utilizar uma integração contínua, entretanto, vai um pouco mais além. O objetivo é garantir que as mudanças no projeto são construídas, testadas e relatadas tão logo quanto possível depois de serem introduzidas.

Figura 4 - Gerencia de Configuração
[Apenas Administradores podem visualizar imagens]
Figura 4 - Gerencia de Configuração

E é isso ai pessoal! Iremos partir para o desafio 2. Se vc reunir todos os tópicos anteriores, em um só, vc terá o desafio 1 completo para seu portfólio. Espero ter ajudado e até a próxima.

Bom dia Leonardo, como faço pra ver ou baixar essas imagens que os administradores podem ver?

Estamos necessitando de ajuda no portfólio em grupo e temos só essa semana para entrega.

espero seu contato. meu e-mail... tenkref(arroba)hotmail.com

abraço e obrigado.

Tenkref14 escreveu:Bom dia Leonardo, como faço pra ver ou baixar essas imagens que os administradores podem ver?

Estamos necessitando de ajuda no portfólio em grupo e temos só essa semana para entrega.

espero seu contato. meu e-mail... tenkref(arroba)hotmail.com

abraço e obrigado.

Olá,
Mandei as imagens para seu email.

Parabéns