Jos Lucivan Batista Freires

Gerncia de configurao de software, gerncia de configurao ou ainda gesto

de configurao de software uma rea da engenharia de software responsvel
por fornecer o apoio para o desenvolvimento de software.
Suas principais atribuies so o controle de verso, o controle de mudana e a
auditoria das configuraes.
Gerncia de configurao de software o conjunto de atividades projetadas para
controlar as mudanas pela identificao dos produtos do trabalho que sero
alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo
para o gerenciamento de diferentes verses destes produtos, controlando as
mudanas impostas, e auditando e relatando as mudanas realizadas.
 A histria da gerncia de configurao de software surge em meados da dcada de
1970, quando os microprocessadores se tornaram populares e o software deixou de ser
considerado parte integrante do hardware para se tornar um produto independente.
Nesta poca, os sistemas se tornaram cada vez maiores e sofisticados, ficando claro que
seriam necessrias metodologias prprias, diferentes das usadas no desenvolvimento
de hardware, para controlar o desenvolvimento desses sistemas.
O Departamento de Defesa (DoD) dos EUA foi um dos pioneiros nessa rea, criando o
padro DoD-STD-2167 que abordava o desenvolvimento de software. A abordagem do
DoD para controlar isto consistia da adoo de uma linguagem padronizada - Ada e
de prticas padro para desenvolvimento de software e gerncia de configurao.
Outras organizaes estavam por sua vez adotando prticas e mtodos de gerncia de
configurao de software, algumas das quais envolvidas tambm com o
desenvolvimento de sistemas para o DoD e outros rgos do governo Americano. Isto
levou o prprio DoD a adotar algumas prticas comerciais e eventualmente uni-las com
seus padres, gerando assim o padro IEEE/IEA 12207. Um outro padro a respeito o
IEEE 828-1983.
 O desenvolvedor A modifica o componente compartilhado
Mais tarde, o desenvolvedor B realiza algumas alteraes no mesmo
Ao tentar compilar o componente, erros so apontados pelo compilador, mas
nenhum deles ocorre na parte que B alterou
O desenvolvedor B no tem a menor ideia sobre a causa do problema
 Cada desenvolvedor trabalha em uma cpia local do componente
 Definir o ambiente de desenvolvimento
Definir polticas para controle de verses, garantindo a consistncia dos artefatos
produzidos
Definir procedimentos para solicitaes de mudanas
Administrar o ambiente e auditar mudanas
Facilitar a integrao das partes do sistema
 Menores Custos de Manuteno
Maior rapidez na identificao e correo de problemas
Ganho de produtividade e eficincia no desenvolvimento;
Diminuio do retrabalho, dos erros e reduo de defeitos;
Aumento da disciplina no processo de desenvolvimento;
Aumento da memria organizacional;
Acesso s informaes qualitativas e quantitativas referentes ao processo de
desenvolvimento, como por exemplo, medida de esforo para efetuar uma
alterao e frequncia de modificaes por componente;
Possibilidade de estabelecer uma trilha de auditoria indicando por que, quando e
por quem um artefato foi alterado;
Auxlio gerncia de projetos;
Garantia de ambiente estvel no qual o produto deve ser desenvolvido.
 Um dos testes mais aplicados em softwares, o teste da caixa preta tem com foco a
anlise das entradas e sadas de dados dentro de um programa ou sistema. Ou
seja, ele foca-se na parte externa do software, j que quem ir test-lo no tem
acesso aos cdigos internos nem sabe sobre a operao interna do software. A
interface avaliada, bem como suas funcionalidades. Alis, esse teste conhecido
tambm como teste funcional.
um dos testes mais simples de serem feitos, se levarmos em considerao a
complexidade de grande parte dos outros. Ele ir focar-se no uso que um usurio
pode fazer de um software, onde ir clicar, o que digitar em campos que precisam
ser preenchidos, como ele navega pelo site etc. importante avaliar se os
resultados que o programa gera esto de acordo com as especificaes ou com o
que era esperado. Nesse tipo de teste quanto mais informaes de entrada, melhor
as chances de se verificar as possveis falhas que possam ocorrer.
 Existem distintas formas de se aplicar o teste da caixa-preta, contudo
interessante ao avaliador tentar se comportar como um usurio, simulando
especialmente os erros que ele poderia cometer durante o uso do software. Os
erros dos usurios so necessrios para ver como o sistema se comporta em
relao a eles, se alerta sobre eles ou deixa passar, o que ocasionaria um erro do
programa. Exemplo: num determinado formulrio de pesquisa, existem padres
para que o usurio preencha os campos, especialmente os de senha e as
informaes pessoais. Limites de caracteres (mnimo e mximo) e usos de
smbolos, maisculas e espaos podem ser requisitos para uma senha, alm dos
nmeros e das letras em minsculo. Caso o usurio no siga as especificaes e
coloque uma senha s numrica, abaixo do mnimo de caracteres, o sistema deve
alert-lo ou no processar a informao. Ou seja, teremos o erro do usurio e o
sistema funcionando corretamente. Porm, caso o sistema aceite a senha
inadequada, ento o erro do sistema e precisa ser consertado.
 Ao contrrio do teste da caixa preta, o teste da caixa branca visa avaliar a estrutura
de um software, motivo pelo qual tambm conhecido como teste estrutural. Aqui
so analisados os componentes internos de um programa para encontrar possveis
falhas que venham a prejudic-lo durante o seu uso, especialmente pelo usurio
final. Avalia-se a operao interna, os cdigos-fontes do software.
Para que o teste da caixa branca seja feito necessrio maior conhecimento
tcnico, j que iro ser avaliados cdigos e a estrutura do programa. Na hora de
montar o teste, importante avaliar a criticidade do programa a ser testado, bem
como sua complexidade e estrutura para avaliar qual o tipo de critrio que ser
usado como mtrica. Tambm importante ter ideia de qual o nvel de qualidade
e confiana que o software precisa atingir, pois quanto maior esses nveis, mais
rigorosas as mtricas devero ser.
 Pode-se avaliar com o teste o fluxo de dados dentro do software, alm da condio,
dos ciclos e dos caminhos lgicos. Abaixo voc confere melhor um pouco deles:
Teste de fluxo de dados possui vrias categorias, tais como: bloco bsico, usos
predicativos, usos computacionais entre outros.
Teste de ciclo essa tcnica possui quatro tipos, tais como: ciclos concatenados,
desestruturados, aninhados e simples.
Teste do caminho bsico/lgico aqui verifica-se a complexidade lgica do
software, utilizando isso para encontrar os caminhos bsicos dele;
Teste de estrutura de controle pode complementar o do caminho bsico;
 Um teste de unidade aquele que testa uma nica unidade do sistema. Ele a testa
de maneira isolada, geralmente simulando as provveis dependncias que aquela
unidade tem. Em sistemas orientados a objetos, comum que a unidade seja uma
classe. Ou seja, quando queremos escrever testes de unidade para a classe Pedido,
essa bateria de testes testar o funcionamento da classe Pedido, isolada, sem
interaes com outras classes.
 Um teste de integrao aquele que testa a integrao entre duas partes do seu
sistema. Os testes que voc escreve para a sua classe PedidoDao, por exemplo,
onde seu teste vai at o banco de dados, um teste de integrao. Afinal, voc est
testando a integrao do seu sistema com o sistema externo, que o banco de
dados. Testes que garantem que suas classes comunicam-se bem com servios
web, escrevem arquivos texto, ou mesmo mandam mensagens via socket so
considerados testes de integrao.
 Um teste de sistema garante que o sistema funciona como um todo. Este nvel de
teste est interessado se o sistema funciona como um todo, com todas as unidades
trabalhando juntas. Ele comumente chamado de teste de caixa preta, j que o
sistema testado com tudo ligado: banco de dados, servios web, batch jobs, e
etc. Os testes de aceitao, famosos com a onda gil, so, no fim, testes de
sistema. Testes de aceitao so aqueles onde as equipes geis dizem se uma
determinada funcionalidade est aceita ou no.
 Independente do nvel do teste, todos eles tem vantagens e desvantagens. Um
teste de unidade, por exemplo, bastante fcil de ser e roda muito fcil; mas no
um teste que simula bem o mundo real. Por outro lado, um teste de sistema faz uma
simulao bastante real, mas muito mais difcil de ser escrito, d mais trabalho de
manuteno e leva mais tempo para executar.
 https://pt.wikipedia.org/wiki/Ger%C3%AAncia_de_configura%C3%A7%C3%A3o_de
_software
https://www.devmedia.com.br/gerencia-de-configuracao-de-software/9145
https://www.devmedia.com.br/gerencia-de-configuracao-e-mudancas/31327
http://www2.ic.uff.br/~andrea/teaching/201602/gpms/GPMS-Aula10-
GerenciaConfiguracaoMudancas.pdf
https://ads.ifba.edu.br/dl1094
http://testesdesoftware.com/teste-caixa-preta/
http://testesdesoftware.com/teste-de-caixa-branca/
http://www.inf.ufpr.br/andrey/ci221/apresentacaoTesteEstrutural.pdf
https://www.devmedia.com.br/teste-de-integracao-na-pratica/31877
http://blog.caelum.com.br/unidade-integracao-ou-sistema-qual-teste-fazer/