Uma Ferramenta de Apoio A Auditoria de C PDF

UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS
UNIDADE ACADÊMICA DE GRADUAÇÃO

CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ANDREWS AZEVEDO JUCHEM
UMA FERRAMENTA DE APOIO À AUDITORIA DE CONFIGURAÇÃO DE

SOFTWARE
SÃO LEOPOLDO
2013
ANDREWS AZEVEDO JUCHEM
UMA FERRAMENTA DE APOIO À AUDITORIA DE CONFIGURAÇÃO DE

SOFTWARE
Trabalho de Conclusão de Curso

apresentado como requisito parcial para a
obtenção do título de Tecnólogo, pelo
Curso de Análise e Desenvolvimento de
Sistemas da Universidade do Vale do Rio
dos Sinos - UNISINOS
Orientador: Prof. MS. Pablo Dall’Oglio
SÃO LEOPOLDO
2013
1
UMA FERRAMENTA DE APOIO À AUDITORIA DA CONFIGURAÇÃO DE

SOFTWARE
Andrews Azevedo Juchem

Orientador: Prof. MS. Pablo Dall’Oglio
Resumo: A quantidade de informações geradas nos dias atuais acabam tornando

inevitável o uso de sistemas de computador. Esses sistemas estão cada vez mais
complexos e acabam tornando seu desenvolvimento mais difícil. Além disso, os
usuários estão cada vez mais exigentes, tornando necessárias novas mudanças e
evoluções. Diante disso, alguma forma de gerenciamento para que o
desenvolvimento não fique caótico se torna necessário. A Gerência da Configuração
disponibiliza um conjunto de atividades que apoia e permite a absorção controlada
das mudanças, mantendo a estabilidade na evolução do projeto. No entanto, é
preciso algo que valide se as atividades foram executadas de forma correta. Neste
caso, Auditoria de Configuração busca validar se as atividades da Gerência da
Configuração foram executadas corretamente. Com o objetivo de melhorar o
processo de auditoria de configuração, este trabalho propõe uma ferramenta para
apoiar o gerenciamento de auditorias físicas de configuração.
Palavras-chave: Auditoria de Configuração. Engenharia de Software. Gerência da

Configuração.
1 INTRODUÇÃO
Nos dias atuais, sistemas de software estão presentes em todos os lugares,

sendo utilizados de maneira direta ou de maneira embarcada em algum dispositivo
eletroeletrônico. O software é utilizado para ajudar para apoiar diversas áreas, como
operações da indústria manufatureira, das escolas e universidades, do setor de
assistência à saúde, das financeiras, do governo, dentre outras. Muitas pessoas
utilizam software de diferentes tipos para fins de entretenimento e de educação. A
especificação, o desenvolvimento, o gerenciamento, e a evolução desses sistemas
de software constituem a disciplina da Engenharia de Software. (SOMMERVILLE,
2011)
Entregar um software, com boa qualidade, sem defeitos e em tempo hábil,
acaba se tornando uma tarefa muitas vezes difícil, quando não existem processos
bem definidos. Para minimizar essas questões e garantir sobrevivência no mundo
2
competitivo, as empresas necessitam de alguma solução que as ajude a evitar esse

cenário criado pela falta de processos bem definidos. Segundo Pressman (2009),
um caminho encontrado para que a indústria de software melhorasse seus serviços
foi à criação da Engenharia de Software. (PRESSMAN 2009)
Durante o processo de desenvolvimento de um software, é produzida uma
grande quantidade de itens de configuração que podem ser alterados durante o
processo. Para que não haja inconsistência nos itens de configuração importantes
para o projeto, a criação e as alterações desses itens devem ser acompanhadas e
controladas. A Gerência da Configuração é uma disciplina da Engenharia de
Software que permite que esse controle seja realizado. (ROCHA, 2001)
Segundo Pressman (2009), a Gerência da Configuração é uma área da
engenharia de software, que apoia o desenvolvimento de software. O principal
objetivo é manter e garantir a integridade dos produtos de trabalho, através do
controle de versão, controle de mudanças, integração continua e auditorias da
configuração. (PRESSMAN, 2009)
Como referência para a Engenharia de Software existe o Software
Engineering Body of Knowledge, conhecido pela sigla SWEBOK, mantido pela IEEE.
O objetivo do SWEBOK é estabelecer um conjunto apropriado de critérios e normas
para a prática profissional da Engenharia de Software. (SWEBOK, 2004)
Dentre as áreas de conhecimento do SWEBOK, existe a Gerência da
Configuração (CM), que tem como a finalidade controlar sistematicamente as
alterações na configuração de um projeto, mantendo a integridade e rastreabilidade
da configuração ao longo do ciclo de vida do sistema. (SWEBOK, 2004)
Para o CMMI, que é um modelo de processo de software, a Gerência da
Configuração é uma área de processo de suporte, pois seu objetivo é estabelecer e
manter a integridade dos produtos de trabalhos gerados pelas áreas de processo de
gerenciamento de projetos e engenharia. (CMMI-DEV, 2010)
Um dos objetivos específicos da Gerência da Configuração (CM) do CMMI é o
Estabelecimento de Integridade das Baselines (SG 3 - Establish Integrity), onde
através das auditorias de configuração, é possível monitorar as baselines
estabelecidas e evitar que elas sejam violadas e tornem-se inconsistentes com o
planejamento feito para o projeto. (CMMI-DEV, 2010)
Existem basicamente dois tipos de auditorias de configuração, são elas: (1)
Auditoria Funcional, assegura que a baseline cumpre o que foi especificado. (2)
3
Auditoria Física, assegura que a baseline esteja completa, com todos os itens de
configuração especificados, e consistente conforme o plano de Gerência da
Configuração. (MURTA, 2004)
Segundo o SWEBOK (2004), uma auditoria pode exigir um grande número de
indivíduos para executar uma variedade de tarefas ao longo de um período
relativamente curto de tempo. Ferramentas que apoiam o planeamento e a
condução de uma auditoria pode facilitar o processo. (SWEBOK, 2004)
1.1 Motivação e Justificativa
As auditorias de configuração são tradicionalmente conduzidas no

estabelecimento de uma baseline, e armazenadas no formato de planilha eletrônica,
onde cada item é descrito e avaliado pelo Gerente de Configuração. A auditoria de
configuração produz métricas importantes para a atividade de gerenciamento de
software.
Entretanto, a execução das auditorias dessa forma acaba consumindo um
tempo considerável (devido à execução ser manual), além de dificultar na
quantificação das métricas. A simples criação de um sistema eletrônico de registro
de avaliações, já traria vantagens para um ambiente de desenvolvimento de
software, uma vez que permitiria o acompanhamento das métricas definidas a cada
baseline do produto, e também a comparação de métricas entre diferentes linhas de
produtos.
Uma das dificuldades ao executar uma auditoria é a descentralização das
informações, onde o auditor acaba perdendo muito tempo para coletar as
informações necessárias para as auditorias, que muitas vezes estão perdidas em
diferentes sistemas sem a garantia que estejam consistentes. Portanto, a criação de
um ambiente de configuração centralizado para a realização de inspeções de
configuração poderia facilitar a integração de outras ferramentas. Um bom exemplo
para essa integração seria ferramentas de controle de mudanças e logs de
ferramentas de controle de versões que seriam sincronizados para popular este
ambiente.
Realizar a gestão de auditorias envolve planejá-las,
executá-las e acompanhar as não conformidades encontradas. Algumas atividades
da auditoria de configuração envolvem ações que podem ser automatizadas por
4
meio de agentes de software, eliminando dessa forma, a necessidade de efetuar

uma auditoria de forma manual. A automatização dessa atividade permitiria um
acompanhamento mais frequente e ágil do projeto, permitindo que se percebam
desvios o mais rápido possível.
Uma ferramenta que automatizasse a auditoria física poderia, por exemplo,
verificar questões como o padrão de nomenclatura de arquivos, a existência deles,
se está preenchido ou vazio, o local que foi armazenado, a data em que foi
atualizado versus etapa do projeto, etc. As auditorias físicas geralmente consomem
um tempo considerável para serem executadas, além de serem tarefas repetitivas,
que aumentam a chance de erro se executadas manualmente.
Em contra partida, questões como auditorias funcionais geralmente
necessitam de apoio humano para que sejam executadas, como por exemplo, para
verificar questões como a qualidade das informações contidas nos documentos.
Devido a isso, automatizar esse tipo de auditorias (auditorias funcionais) pode ser
algo mais complexo. Neste caso, a ferramenta proposta nesse trabalho irá focar nas
auditorias físicas.
Também é importante salientar que a atividade de auditoria de configuração
ocorre em diferentes etapas do projeto. Uma dessas etapas geralmente é antes da
liberação para o cliente, e diante da grande demanda e falta de tempo dos projetos,
acabam muitas vezes não sendo executadas. Portanto, existem muitos fatores que
apontam que a criação de uma ferramenta para apoiar e automatizar esta função iria
trazer muitos benefícios para a área de gerência da configuração.
1.2 Objetivos
1.2.1 Objetivo Geral
Melhorar a atividade de avaliação em auditoria de configuração através da

criação de uma ferramenta de apoio e automatização.
5
1.2.2 Objetivos Específicos
a) Definir uma arquitetura para gerenciar a auditoria física de

configuração;
b) Implementação de uma ferramenta para gerenciamento de auditoria
física, com base nessa arquitetura;
c) Aplicar uma avaliação qualitativa da ferramenta desenvolvida.
2 REFERENCIAL TEÓRICO
Para analisar a implementação e resultados da Ferramenta de Apoio à

Avaliação de Auditoria de Configuração, desenvolvida neste trabalho, alguns temas
foram estudados e serão apresentados nos itens a seguir.
2.1 Qualidade de Software
Conforme Guerra (2009), a qualidade de software constitui uma área cuja

demanda está crescendo significativamente, pois os usuários exigem cada vez mais
eficiência, eficácia, dentre outras características de qualidade importantes para um
produto tão especial como o software. (GUERRA, 2009)
Visando buscar a Qualidade de Software, Pressman (2009) afirma que um

caminho encontrado para que a indústria de software melhorasse seus serviços foi a
criação da Engenharia de Software.
2.2 Engenharia de Software
O conceito “Engenharia de Software“ foi cunhado em 1969 por Fritz Bauer em

uma conferência patrocinada por um comitê de Ciências da Organização do Tratado
do Atlântico do Norte (Otan). (HIRAMA, 2012)
Hirama (2012, p. 7) destaca que de acordo com vários relatos, Fritz Bauer
teria dito: “A Engenharia de Software é o estabelecimento e uso de sólidos princípios
de engenharia a fim de obter um software que seja confiável e que funcione de
forma econômica e eficiente em maquinas reais.”
6
Para o Institute of Eletrical and Eletronic Engineering a Engenharia de

Software é uma disciplina de engenharia que envolve todos os aspectos de
desenvolvimento e manutenção de um produto de software. (IEEE Std 828-1990,
1990)
2.2.1 SWEBOK
Com o propósito de criar um consenso sobre as áreas de conhecimento da

Engenharia de Software e seu escopo, o guia Software Engineering Body of
Knowledge (SWEBOK) é uma iniciativa do IEEE (Institute of Electrical and
Electronics Engineers) Computer Society. (SWEBOK, 2004)
2.3 Processos de Software
Um processo de software é um conjunto de atividades e resultados

associados que levam à produção de um produto de software. (SOMMERVILLE,
2011)
Segundo Pressman (2009), o processo de software é importante porque

fornece estabilidade, controle e organização para uma atividade que pode, se
deixada sem controle, se tornar-se bastante caótica. (PRESSMAN, 2009)
Melhorar processos de software não é algo fácil. Sommerville (2011) afirma

que os processos de software são complexos e como todos os processos
intelectuais, dependem de julgamento humano. Por causa da necessidade de utilizar
o julgamento e a criatividade, muitas tentativas de automatizar processos de
software tem tido sucesso limitado. (SOMMERVILLE, 2011)
2.4 Modelos de Processo de Software
Os modelos de processo de software buscam apoiar a produção do software

criando uma estrutura de processo. Segundo Sommerville (2011), um modelo de
processo de software é uma descrição simplificada de um processo de software, que
é apresentada a partir de uma perspectiva especifica. Os modelos, pela sua
natureza, são simplificações; e, assim, um modelo de processo de software é uma
abstração do processo real que está sendo descrito. (SOMMERVILLE, 2011)
7
Pressman (2009) destaca que a aplicação inteligente de qualquer modelo de

processo de software deve reconhecer que a adaptação (ao problema, ao projeto, à
equipe e a cultura organizacional) é essencial para o sucesso. (PRESSMAN, 2009)
2.5 CMMI
Desenvolvido pelo SEI (Software Engineering Institute), o CMMI (Capability

Maturity Model Integration) é um conjunto de melhores práticas que ajudam as
organizações a melhorar seus processos. (CMMI-DEV, 2010)
O CMMI foi baseado nas melhores práticas para desenvolvimento e

manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto
em engenharia de software.
2.5.1 Áreas de Processo
As Áreas de Processo são um cluster de práticas relacionadas em uma área

que, quando implementada coletivamente, satisfaz um conjunto de objetivos
considerados importantes para se melhorar naquela área. (CMMI-DEV, 2010)
2.5.2 Objetivos Genéricos
Os objetivos genéricos são chamados “genéricos” porque a mesma

declaração de objetivo se aplica à múltiplas áreas de processo. Descreve
características que devem estar presentes para institucionalizar processos que
implementam uma área de processo. É um componente requerido do modelo e
também utilizado em assessments para ajudar a determinar se uma área de
processo é satisfeita. (CMMI-DEV, 2010)
2.5.3 Objetivos e Práticas Específicas
Cada área de processo é definida por um conjunto de objetivos e práticas.

Esses objetivos e práticas que aparecem apenas uma vez em sua respectiva área
de processo. Provê um resumo de alto-nível sobre os objetivos específicos e
praticas especificas. São componentes informativos. (CMMI-DEV, 2010)
8
2.5.4 Níveis do CMMI
O CMMI suporta dois caminhos de melhoria usando níveis. Um deles permite

que as organizações melhorem processos correspondentes às áreas de processo
(PA’s) que ela selecionou. O outro caminho permite que a organização melhore um
conjunto de processos relacionados ao endereçar sucessivamente conjuntos de
áreas de processo. (CMMI-DEV, 2010)
O CMMI-DEV (2010) associa estes dois caminhos com os dois tipos de

níveis, que são os níveis de capacidade e os níveis de maturidade. Os níveis de
capacidade são representados pelos números de 0 a 3: (0) Incompleto; (1)
Executado; (2) Gerenciado; (3) Definido. Já os níveis de maturidade são
representados pelos números de 1 a 5: (1) Inicial; (2) Gerenciado; (3) Definido; (4)
Quantitativamente Gerenciado; (5) Em Otimização.
Esses níveis correspondem a duas formas de melhoria de processo,

chamadas de representações:
a) Contínua: Possibilita à organização utilizar a ordem de melhoria que

melhor atende os objetivos de negócio da empresa;
b) Por estágios: Disponibiliza uma sequência pré-determinada para

melhoria baseada em estágios que não deve ser desconsiderada, pois
cada estágio serve de base para o próximo.
O uso da representação contínua permite que você atinja níveis de

capacidade. O uso da representação por estágios permite que você atinja níveis de
maturidade. Para atingir um determinado nível, a organização deve satisfazer todos
os objetivos da área de processo, ou conjunto de áreas de processo que se quer
melhorar, não importa se é um nível de capacidade ou maturidade. (CMMI-DEV,
2010)
9
2.6 Gerência da Configuração
Gerência da Configuração (CM) é uma disciplina formal da engenharia de

software, assim como parte da gestão global do sistema de configuração. Fornece
os métodos e ferramentas para identificar e controlar o software em todo o seu
desenvolvimento e utilização. Atividades de CM incluem a identificação e
estabelecimento de linhas de base, a revisão, aprovação e controle de mudanças, o
monitoramento e notificação de tais mudanças; auditorias e revisões do produto de
software em evolução; e o controle de documentação de interface e fornecedor do
projeto CM. (IEEE Std 828-1990, 1990)
Segundo Pressman (2009), a CM pode ser vista como uma atividade de

garantia da qualidade de software, que é aplicada ao longo de todo o processo de
software. (PRESSMAN, 2009)
2.6.1 Atividades da Gerência da Configuração
Segundo o SWEBOK (2004), as atividades da CM são: Gerenciamento do

Processo de CM, Identificação da Configuração de Software, Controle da
Configuração de Software, Relato da Situação da Configuração, Auditoria de
Configuração de Software, e Gerenciamento de Liberação e Entrega de Software.
(SWEBOK, 2004)
2.6.2 Gerência da Configuração conforme o CMMI
O CMMI trata a gerência da configuração como uma área de processo de

suporte que pertence ao nível 2 de maturidade (CMMI-DEV, 2010), pois seu objetivo
é estabelecer e manter a integridade dos produtos de trabalhos gerados pelas áreas
de processo de gerenciamento de projetos e engenharia. (OLIVEIRA, 2007)
No apêndice A é possível visualizar a relação das atividades da Gerência da

Configuração, definidas pelo SWEBOK (2004), com as práticas especificas definidas
pelo CMMI-DEV (2010).
10
2.7 Auditoria De Configuração De Software
Uma variedade de situações podem causar problemas durante o processo da

CM. (KEYES, 2004) A identificação, controle de versão e controle de mudanças
ajudam o desenvolvimento de software a manter a ordem, o que de outro modo seria
uma situação caótica. (PRESSMAN, 2009) No entanto, a auditoria de configuração
deve assegurar que o processo foi implementado corretamente.
A auditoria de configuração de software é uma atividade realizada de forma

independente, que avalia a conformidade de produtos e processos de software com
os regulamentos aplicáveis, normas, diretrizes, planos e procedimentos. (SWEBOK,
2004)
2.7.1 Auditoria Funcional
A finalidade da Auditoria Funcional (FCA) de software é garantir que o item de

software auditado é consistente com as suas especificações. A saída das atividades
de verificação e validação de software é um insumo chave para essa auditoria.
(SWEBOK, 2004) Esse tipo de auditoria possui aspectos que necessitam de apoio
humano para serem realizadas como, por exemplo, a análise da qualidade das
informações de algum documento. Conforme Sanches (2003), a FCA preocupa-se
com aspectos internos dos arquivos, compreendendo uma verificação técnica formal
nos itens de configuração. Essa verificação é uma atividade de controle de
qualidade que tenta descobrir omissões ou erros na configuração, que degradam os
padrões de construção do software. (SANCHES, 2003)
Um exemplo de checklist de auditoria funcional de configuração pode ser
visualizado no Apêndice B.
2.7.2 Auditoria Física
O propósito da Auditoria Física (PCA) software é assegurar que a concepção

e documentação de referência estejam consistentes com o produto de software, tal
como está construído. (SWEBOK, 2004)
11
A PCA é tipicamente realizada, quer em conjunto com a FCA ou logo após o

FCA (uma vez que os problemas identificados durante a FCA são resolvidos). A PCA
é essencialmente uma revisão do software de configuração de dados do estado da
configuração para assegurar que os produtos de software e sua documentação de
entrega estão devidamente na baseline e devidamente construídos, para então
serem liberados para os testes betas ou de produção, dependendo de onde o ciclo
de vida da PCA é conduzido. (WESTFALL, 2004)
Nesse tipo de auditoria são avaliadas questões como, por exemplo: verificar
se o repositório encontra-se na estrutura de diretórios pré-definida; verificar se os
arquivos no repositório seguem o padrão de nomenclatura especificado; confirmar
se os artefatos planejados estão presentes na baseline; etc.
Um exemplo de checklist de auditoria física de configuração pode ser
visualizado no Apêndice C.
3 TRABALHOS RELACIONADOS
Neste capitulo serão apresentados alguns trabalhos relacionados que foram

encontrados durante o levantamento bibliográfico.
3.1 Modelo de Avaliação do Processo de Gerência da Configuração de

Software
Neste trabalho, Cia (2006) apresenta processos básicos para atingir os

objetivos da Gerência da Configuração e propõe um roteiro para a avaliação e
melhoria dos mesmos. São apresentadas descrições de alguns Modelos de Melhoria
de Processos, onde é enfatizada a importância da Gerência da Configuração em
cada um deles. Um dos modelos apresentados é o CMMI, que também é abordado
no presente trabalho. A autora apresentada os principais processos para
implementar a Gerência da Configuração, dentre eles, pode-se destacar a Auditoria
da Configuração. Após a abordagem da base teórica, é proposto um roteiro para a
avaliação da Gerência da Configuração. Durante o decorrer da dissertação, é
salientada a importância da Auditoria da Configuração.
12
No último capítulo da dissertação é realizada uma avaliação de três

ferramentas que apoiam a Gerência da Configuração. Abaixo é apresentado as
ferramentas avaliadas por Cia (2006):
a) Rational ClearCase: É uma ferramenta que realiza apenas o controle

de versão, embora seja denominada uma ferramenta de Gerência da
Configuração. O Rational ClearCase também pode ser utilizado junto
com o Rational ClearGuest, que efetua o Controle de Mudanças.
Conforme Cia (2006), é uma das ferramentas mais utilizadas pelas
grandes organizações, pois se trata de uma ferramenta robusta, capaz
de suportar centenas de usuários e projetos;
b) Borland StarTeam: Essa ferramenta realiza o controle de mudanças e
controle de versão. Essa ferramenta possui o intuito de atender
necessidades de diversos tipos de equipes, adaptando-se de acordo
com seu tamanho, distribuição geografia ou estilo de trabalho;
c) CVS – Current Version System: É uma ferramenta que efetua o
controle de versão, possui diversas funcionalidades e algumas
limitações em relação as demais. A grande vantagem do CVS é o fato
de ser uma ferramenta livre que pode ser adquirida gratuitamente.
No Apêndice D é possível visualizar um quadro que usa como base as três

planilhas de avaliação, apresentas por Cia (2006), em relação as três ferramentas de
Gerência da Configuração. Como essa avaliação de Cia(2006) analisa as
ferramentas e não os processos, alguns itens não são aplicáveis para análise.
Dentre os itens não aplicáveis (não tratados pelas ferramentas), percebe-se que
nenhuma das ferramentas atente a atividade de auditoria de configuração, até
mesmo as ferramentas que são mais robustas e possuem uma forte predominância
no mercado. (CIA, 2006)
3.2 Ferramenta de Apoio à Gerência da Configuração de Software
Furlaneto (2006) propõe uma ferramenta de apoio à Gerência da

Configuração que se baseia nas diretrizes previstas na área de Gerência da
13
Configuração do modelo MPS.BR. O autor apresenta a ferramenta criada,

apontando suas principais características e seus diferencias em relação à alguns
trabalhos relacionados. Furtanelo (2006) destaca que antes da construção dessa
ferramenta, foi definido um processo de gestão de configuração com base nos
resultados esperados pelo modelo MPS.BR. Com base nesse processo, foi criado a
ferramenta, a qual possui diversas funcionalidades que visam atender esse
processo.
A ferramenta permite um cadastro de auditorias de forma simples, o qual

pode ser visualizado no Apêndice E. No entanto, essa ferramenta não possui
nenhuma forma de automatização, quantificação de métricas ou gestão de
auditorias, apenas um simples cadastro. Também não é disponibilizada nenhuma
forma de diferenciar as auditorias físicas das funcionais. Além disso, a ferramenta
também disponibiliza o Relatório de Auditorias, que também pode ser visualizado no
Apêndice E.
De forma geral, a ferramenta criada por Furlaneto (2006) possui boas

funcionalidades e alguns diferenciais em relação às ferramentas já existentes no
mercado. O pronto forte dessa ferramenta é a sua adaptação ao modelo MPS.BR,
que permite que as organizações consigam atingir com mais facilidade os objetivos
proposto pelo modelo. No entanto, existem pontos que poderiam ser melhorados
como, por exemplo, as atividades relacionadas com Auditoria da Configuração.
3.3 Knowledge-Enhanced Change Audit for Configuration Management
Bo Yang (2010) propõe basicamente a sincronização do Sistema de

Gerenciamento de Mudanças com um banco de dados do conhecimento, a qual
poderá ser utilizada para apoiar diversas necessidades, sendo uma delas a Auditoria
da Configuração. Segundo Yang (2010), mesmo se todas as informações estiverem
concentradas em um único local, os profissionais de gestão de TI podem se
confundir com detalhes triviais, abrindo assim uma margem de erro. (YANG, 2010)
A forma mais eficaz encontrada por Yang (2010) para fornecer informações
consistentes para o Gerenciamento da Configuração era a sincronização com a
ferramenta de Controle de Mudanças. Nesta solução, Yang (2010) descreve que o
sistema de mudanças possui um banco de dados (CMDB) onde são armazenados
14
os itens de configuração atuais da mudança, que posteriormente serão autorizados.

Depois de autorizados, é realizada a sincronização com a base do conhecimento, a
qual será a base utilizada para a Auditoria da Configuração. Nas suas considerações
finais, Yang (2010) afirma que a sincronização do Gerenciamento de Mudanças para
apoiar a realização de Auditorias de Configuração é eficaz e proporciona uma
melhora significativa nas mudanças e na qualidade do gerenciamento de
configuração.
4 MÉTODO DE PESQUISA
Wainer (2007 p. 1) destaca que “pesquisa em Ciência da Computação

envolve na maioria dos casos a construção de um programa, de um modelo, de um
algoritmo ou de um sistema novo”. Em acordo com essa afirmação de Wainer
(2007), neste trabalho foi construído um protótipo de ferramenta para apoiar as
auditorias físicas de configuração. No entanto, Wainer (2007 p. 2) acredita que cada
vez mais os programas criados serão avaliados de forma mais rigorosa, neste caso,
onde a simples criação do programa/sistema não é suficiente, é preciso avaliar de
forma metodológica o programa/sistema criado. (Wainer, 2007)
Para a construção desse protótipo, foi necessário analisar a atividade de

auditoria de configuração (focando em auditorias físicas) em busca das
necessidades e pontos que podem ser melhorados com o apoio de uma ferramenta.
Dessa forma, este trabalho se caracteriza com o objetivo de Pesquisa Exploratória,
que conforme Gil (2010, p. 43):
Esse tipo de pesquisa tem como objetivo proporcionar maior familiaridade

com o problema com vistas a torná-lo explícito ou a construir hipóteses.
Envolve levantamento bibliográfico; entrevistas com pessoas que tiveram
experiências práticas com o problema pesquisado; análise de exemplos que
estimulem a compreensão. Assume, em geral, as formas de Pesquisas
Bibliográficas e Estudos de Caso.
De acordo com Fonseca (2002), “a pesquisa possibilita uma aproximação e

um entendimento da realidade a investigar, como um processo permanentemente
inacabado”. Fonseca (2002) ainda destaca que essa pesquisa “se processa através
de aproximações sucessivas da realidade, fornecendo subsídios para uma
intervenção no real”. Neste caso, este trabalho acabou se tornando um experimento,
15
pois foi necessária a construção de um protótipo para permitir a exploração da

pesquisa.
Segundo Wainer (2007 p. 19), “experimentos são atividades caracterizadas

pela manipulação de algumas variáveis, e a observação de outras, em situações
artificiais ou semi-artificiais”. Wainer (2007) ainda destaca que geralmente pesquisas
na área de Ciência da Computação estão relacionadas com experimentos que
envolvem seres humanos, e vários deles. (WAINER, 2007)
De acordo com Fonseca (2002, p. 38):
A pesquisa experimental seleciona grupos de assuntos coincidentes,

submete-os a tratamentos diferentes, verificando as variáveis estranhas e
checando se as diferenças observadas nas respostas são estatisticamente
significantes. [...] Os efeitos observados são relacionados com as variações
nos estímulos, pois o propósito da pesquisa experimental é apreender as
relações de causa e efeito ao eliminar explicações conflitantes das
descobertas realizadas.
É importante salientar que o experimento (ferramenta proposta neste

trabalho), não será usado como gerador de dados, mas sim utilizado uma
abordagem de pesquisa qualitativa para avaliar o próprio uso desta ferramenta, e
sua capacidade de apoiar as auditorias físicas de configuração.
Neste caso, segundo Goldenberg (1997 p. 34), “a pesquisa qualitativa não se

preocupa com representatividade numérica, mas, sim, com o aprofundamento da
compreensão de um grupo social, de uma organização, etc”. Portanto, esse trabalho
manteve o foco em realizar a pesquisa com poucos participantes, mas que
possuíam um grande nível de experiência e conhecimento relacionado a qualidade e
engenharia de software. De acordo com isso, Gerhardt e Silveira (2009 p. 32)
afirmam que:
Os pesquisadores que utilizam os métodos qualitativos buscam explicar o

porquê das coisas, exprimindo o que convém ser feito, mas não quantificam
os valores e as trocas simbólicas nem se submetem à prova de fatos, pois
os dados analisados são não-métricos (suscitados e de interação) e se
valem de diferentes abordagens.
16
Além disso, para que a ferramenta proposta esteja em aderência com os

procedimentos e a teoria que compõem a Auditoria da Configuração, foi necessária
a realização de uma pesquisa bibliográfica, que segundo Fonseca (2002 p. 32):
A pesquisa bibliográfica é feita a partir do levantamento de referências

teóricas já analisadas, e publicadas por meios escritos e eletrônicos, como
livros, artigos científicos, páginas de web sites. Qualquer trabalho científico
inicia-se com uma pesquisa bibliográfica, que permite ao pesquisador
conhecer o que já se estudou sobre o assunto. Existem, porém pesquisas
científicas que se baseiam unicamente na pesquisa bibliográfica,
procurando referências teóricas publicadas com o objetivo de recolher
informações ou conhecimentos prévios sobre o problema a respeito do qual
se procura a resposta.
Segundo Gerhardt e Silveira (2009 p. 36), “a pesquisa experimental pode ser

desenvolvida em laboratório (onde o meio ambiente criado é artificial) ou no campo
(onde são criadas as condições de manipulação dos sujeitos nas próprias
organizações, comunidades ou grupos)”.
No caso deste trabalho, foi utilizado um ambiente de laboratório, que

conforme Marconi e Lakatos (2003 p. 190), “a pesquisa de laboratório é um
procedimento de investigação mais difícil, porém mais exato. Ela descreve e analisa
o que será ou ocorrerá em situações controladas. Exige instrumental específico,
preciso, e ambientes adequados”.
Para Santos (1999 p. 31), um ambiente de laboratório se caracteriza como:
espaço e momento de uma pesquisa caracterizada por duas situações: a

interferência artificial na produção do fato/fenômeno ou a artificializarão de
sua leitura, geralmente melhorando as capacidades humanas naturais de
percepção. Com efeito, os fatos/fenômenos que acontecem na realidade, no
campo, muitas vezes escapam ao padrão desejável de observação. Por
isso são reproduzidos de forma artificial e controlados, e permitem assim
captação adequada para descrição e análise. Outras vezes, os mecanismos
naturais de observação se mostram insuficientes, seja em alcance, seja em
acuidade. Daí a necessidade de artificializar o ambiente ou os mecanismos
de percepção, para que o fato/fenômeno seja produzido/percebido
adequadamente.
Segundo Wainer (2007 p. 15), questionários são “uma forma rápida e simples
para avaliar as opiniões, objetivos, anseios, preferências, crenças, etc. de pessoas.
Mas por ser uma forma simples, se mal concebida, pode levar a um viés
considerável”. Neste caso, para coleta de dados foi construído um questionário,
onde participantes puderam avaliar protótipo. É importante salientar que esse
17
questionário foi avaliado por três especialistas em qualidade e engenharia de

software, visando ter a melhor qualidade dos resultados.
Os participantes da pesquisa, através do questionário citado acima, avaliaram

pontos como, por exemplo: funcionalidades, facilidade de uso e maturidade da
ferramenta para ser utilizada em um ambiente real. Através disso, foi possível
compor as conclusões deste trabalho, que serão descritas com mais detalhes nos
próximos capítulos.
5 PROTÓTIPO
Este capítulo irá descrever as informações referentes a ferramenta que foi

construída neste trabalho. Também serão apresentadas suas principais
características e seus limites.
5.1 Visão Geral
A proposta deste trabalho foi implementar uma ferramenta para apoiar a

atividade de auditoria de configuração, que é uma das atividades da disciplina de
Gerência da Configuração. Essa ferramenta irá efetuar toda a gestão de auditorias
físicas de configuração, que inclui planejá-las, executá-las e acompanhar as suas
não conformidades encontradas. Além disso, essa ferramenta irá ajudar a atingir um
dos objetivos específicos da Gerência da Configuração do CMMI, que visa garantir a
integridade das baselines (SG 3 - Establish Integrity) através da realização de
auditorias.
Como já citado anteriormente, existem dois tipos de auditoria de configuração,

a auditoria física e a auditoria funcional. A ferramenta irá automatizar algumas
tarefas de auditoria física. Porém, tarefas de auditoria funcional se limitam pela
intervenção humana, impedindo que as mesmas sejam automatizadas. Neste caso,
para manter o registro dessas auditorias funcionais, o sistema permite o cadastro de
auditorias de forma manual. Para isso, a ferramenta provê diversas funcionalidades,
dentre as quais se destacam: Cadastro de projetos, cadastro de baselines, cadastro
de estrutura de diretórios e padrões de nomenclaturas de artefatos, alguns relatórios
e gráficos sobre inspeções, dentre outros. Além disso, é permitida a criação de
auditorias automáticas, que irá cadastrar automaticamente os resultados das
18
auditorias e suas métricas. Esses exemplos citados foram apenas uma visão geral
da ferramenta. A lista completa de requisitos e suas descrições são apresentadas
nos próximos itens deste capítulo.
Na figura 1 pode ser visualizado um dos painéis de gráficos disponíveis na

ferramenta proposta. Nessa figura, a ferramenta gera um gráfico de barras para
cada verificação (item de checklist). Esses gráficos variam por projeto e apresentam
os resultados por cada baseline do projeto. Neste caso, os gráficos da figura 1 estão
apresentando a quantificação das métricas (métricas que indicam a qualidade das
baselines), que foram examinadas através das auditorias (automáticas e manuais).
Importante destacar que foram criados gráficos para as seguintes verificações: (1)
Nomenclatura de Artefatos, (2) Estrutura de Diretórios, (3) Localização dos Artefatos
e (4) Número de Mudança no SVN.
Figura 1 – Protótipo (Gráfico de Barras do Projeto)
Fonte: Elaborado pelo autor.

19
Embora exista apenas gráficos para quatro verificações, a ferramenta permite

que novas verificações sejam cadastradas, para isso existe o Cadastro de
Verificações. No entanto, caso novas verificações sejam cadastradas, as mesmas
não irão possuir gráficos, a menos que sejam desenvolvidos. Como já citado
anteriormente, a ferramenta possui por padrão quatro verificações pré-cadastradas
(são as mesmas apresentadas nos gráficos).
Cada projeto pode possuir uma ou mais baselines. Na Figura 2 pode ser
visualizada a tela de cadastro de baselines de um projeto. Nessa figura, existem três
baselines cadastradas para o projeto, que são as baselines para planejamento,
escopo e testes.
Figura 2 – Protótipo (Cadastro de Baselines)
Cada baseline irá possuir uma estrutura de diretórios, que são cadastradas no
projeto, e vinculadas nas baselines. Os diretórios variam por baseline, pois
dependendo da etapa que o projeto estiver, a baseline pode não conter todos os
diretórios e arquivos. Um exemplo disso seria a baseline de escopo, onde nessa
etapa geralmente não existem os arquivos de código fonte, apenas os documentos
referentes ao escopo. Na figura 3 pode ser visualizado o cadastro de diretórios da
20
baseline. Essa estrutura de diretórios é provida do Plano de Gerência da

Configuração, e são utilizadas nas validações das auditorias. Também é importante
lembrar que dentro dessa estrutura de diretórios, é possível vincular os seus
respectivos artefatos (que são cadastrados na ferramenta com seu respectivo
padrão de nomenclatura).
Figura 3 – Protótipo (Cadastro de Diretórios da Baseline)

21
Dentro de cada baseline poderá ser criado uma ou mais auditorias, sendo
manuais ou automáticas. Na figura 4 pode ser visualizado o cadastro de auditorias
de uma baseline.
Figura 4 – Protótipo (Cadastro de Auditorias da Baseline)
Uma característica importante dessa ferramenta é a possibilidade que o

usuário terá de criar agentes de software, que serão executados para realizar ações
quando uma auditoria é cadastrada. Essa automatização de auditorias tem como
objetivo permitir o acompanhamento mais frequente e ágil do projeto. Neste caso,
um exemplo de benefício seria a inspeção do padrão de nomenclatura dos objetos
durante o ciclo do projeto e não apenas no final, como normalmente é realizado.
Na figura 5 é possível visualizar a tela de cadastro de agentes. Esses agentes

são chamados toda vez que uma auditoria automática é criada (a ferramenta permite
o cadastro de auditorias automáticas, onde os resultados são criados pelo próprio
sistema, ou então, auditorias manuais, onde o usuário cadastra os resultados). Além
disso, os agentes podem ser vinculados a uma verificação, quando a mesma é
cadastrada (cada agente será responsável por gerar os resultados dessas
verificações a quais foram vinculados).
Dessa forma, a ferramenta se torna flexível permitindo a modularização de

novo agentes, os quais podem ser desenvolvidos e acoplados na ferramenta, sem
22
que a mesma seja modificada. Foi denominado o nome “agente” pelo fato de ser
uma classe independente a qual não depende totalmente da aplicação para ser
executada.
Figura 5 – Protótipo (Cadastro de Agentes)

23
5.2 Escopo
Entender as necessidades de um problema é algo bastante complexo quando

um software é desenvolvido. Segundo Pressman (2009), a Engenharia de Requisitos
fornece um mecanismo para identificar e ajudar os engenheiros de software a
entender e encontrar a melhor solução para resolver um problema. (PRESSMAN,
2009) Através disso, buscando o melhor entendimento e compreensão das
funcionalidades da ferramenta proposta, serão descritos a seguir os requisitos
funcionais e não funcionais.
5.2.1 Requisitos Funcionais
a) RF001 - Permitir estabelecer e gerenciar os usuários do sistema;

b) RF002 - Permitir estabelecer projetos;
c) RF003 - Permitir estabelecer baselines;
d) RF004 - Permitir estabelecer diretórios;
e) RF005 - Permitir o estabelecer artefatos vinculados a uma baseline e um
diretório;
f) RF006 - Permitir estabelecer padrões de estrutura para diretórios;
g) RF007 - Permitir estabelecer padrões de nomenclatura para artefatos;
h) RF008 - Permitir estabelecer auditorias manuais;
i) RF009 - Permitir estabelecer auditorias automáticas;
j) RF010 - Permitir estabelecer métricas;
k) RF011 - Permitir cadastrar inconformidades resultantes de auditorias;
l) RF012 - Permitir o cadastro de métricas resultantes de auditorias;
m) RF013 - Permitir a geração de relatórios e gráficos de auditorias.
5.2.1 Requisitos Não Funcionais
a) RNF001 - Utilizar arquitetura MVC;

b) RNF002 - Utilizar plataforma WEB;
c) RNF003 - Utilizar linguagem de programação PHP;
d) RNF004 - Utilizar banco de dados MySQL;
e) RNF005 - Utilizar servidor Web Apache;
24
f) RNF006 - Utilizar framework Adianti Framework para PHP.
A descrição dos requisitos funcionais e não funcionais apresentados acima

podem ser consultados no Apêndice F.
5.3 Modelo de Classes
Na figura 6 é possível visualizar o diagrama de classes do protótipo.
Figura 6 – Diagrama de Classes
No Apêndice G é possível visualizar o detalhamento das classes

apresentadas no diagrama da figura 6.
25
5.4 Modelo ER
Segundo Pressman (2009, p. 349), “usando o diagrama entidade-

relacionamento como notação fundamental, a modelagem de dados concentra-se na
definição de objetos de dados (objetos que não encapsulam processamento) e na
maneira pela qual eles se relacionam entre si”. Na figura 6 é possível visualizar o
diagrama ER. O detalhamento desse diagrama pode ser visualizado no Apêndice H.
Figura 7 – Diagrama ER

26
5.5 Casos de Uso
Segundo Booch, Rumbaugh e Jacobson (2005), um caso de uso envolve a

interação entre os atores e o sistema. Um ator representa um conjunto coerente de
papéis que os usuários de casos de uso desempenham quando interagem com
esses casos de uso. E os agentes podem ser humanos, ou podem ser sistemas
automatizados. (BOOCH, RUMBAUGH e JACOBSON, 2005) Neste caso, buscando
o melhor entendimento dos requisitos, foi criado um diagrama de caso de uso que é
ilustrado na figura 8.
Figura 8 – Diagrama de Casos de Uso
O detalhamento dos casos de uso pode ser visualizado no Apêndice I.

27
5.6 Visão Geral da Arquitetura
O padrão MVC se divide em três camadas (Model, View e Control), buscando

melhorar o gerenciamento de sistemas complexos. Conforme Dall’Oglio (2012 p. 13),
o “MVC é um padrão de projeto de software que consiste na separação da aplicação
em camadas lógicas”. Dessa forma, com o intuito de utilizar as melhores práticas do
mercado, a ferramenta foi construída utilizando o padrão MVC, que irá facilitar na
estruturação do projeto e futuras atualizações.
5.6.1 Tecnologia Utilizada
Para maior acessibilidade, foi utilizado como linguagem de programação o

PHP. O PHP é uma linguagem de scripting de uso geral amplamente utilizada que é
especialmente interessante para desenvolvimento Web e pode ser incorporado em
HTML. (PHP, 2013)
Para facilitar a utilização do padrão MVC junto com o PHP foi utilizado do
Adianti Framework para PHP, que provê um conjunto de classes baseadas no MVC,
o qual facilita a utilização do padrão. (DALL’OGLIO, 2012) Além disso, conforme
Dall’Oglio (2012 p. 11), “todo o Adianti Framework é baseado em padrões de projeto.
Ao todo, ele utiliza em sua implementação mais de 20 padrões de projeto”.
Como banco de dados, será utilizado o MySQL pelo fato de ser um bando de
dados simples, com foco em aplicações Web e facilmente adaptável ao PHP.
Segundo a Oracle (2013), o MySQL é banco de dados de código aberto mais
popular do mundo, que permite a entrega de aplicações de banco de dados com alto
desempenho, de forma confiável. (ORACLE, 2013)
Será utilizado o MAMP para facilitar a preparação do ambiente de

desenvolvimento. O MAMP é um conjunto de programas pré-configurados que
simula um servidor local em questão de segundos no sistema operacional Mac OS.
Os principais programas instalados pelo MAMP são: Apache, MySQL e PHP.
(MAMP, 2013)
28
6 AVALIAÇÃO DO PROTÓTIPO
Este capítulo irá apresentar como foi realizada a pesquisa de avaliação do

protótipo, desenvolvido neste trabalho, e seus respectivos resultados perante a
pesquisa.
6.1 Visão Geral da Avaliação
Conforme a metodologia proposta, o protótipo desenvolvido neste trabalho foi

submetido a uma pesquisa qualitativa, onde participaram cinco avaliadores. Como já
citado na metodologia deste trabalho, a avaliação qualitativa não se preocupa com a
representação numérica, mas sim com a compreensão das respostas.
Um dos pontos que influenciou na escolha de uma pesquisa qualitativa ao
invés de quantitativa foi à dificuldade de encontrar pessoas com conhecimento em
Gerência da Configuração e Engenharia/Qualidade de Software. Neste caso, o
objetivo dessa avaliação foi focar em poucos participantes, os quais possuem um
maior nível de conhecimento na área. Dessa forma, a pesquisa manteve a qualidade
mesmo com poucos participantes.
Para colocar em prática essa pesquisa, foi criado um questionário, que pode
ser visualizado no Apêndice J. Esse questionário é composto por treze perguntas,
sendo que três perguntas avaliam o perfil do participante, e as demais, a ferramenta
proposta. O questionário foi avaliado por três especialistas em qualidade/engenharia
de software, visando a melhor qualidade dos resultados obtidos na pesquisa.
Considerando o fato que a pesquisa é qualitativa, a maioria das perguntas é
descritiva (perguntas abertas), assim o participante pode expressar a suas opiniões
com maior facilidade. Além disso, é importante destacar que os poucos participantes
da pesquisa se caracterizam por um alto nível de conhecimento na área,
aumentando as chances da pesquisa receber respostas de valor.
Para poder responder a pesquisa, foi necessário que o participante
conhecesse a ferramenta, já que a avaliação está relacionada às funcionalidades da
mesma. Neste caso, foi disponibilizada uma página na internet, onde é possível
acessar três itens: a própria ferramenta que será avaliada, um vídeo que apresenta
as funcionalidades da mesma, e o questionário da avaliação. Essa página pode ser
visualizada na figura 9.
29
Figura 9 – Página do Trabalho na Internet
Importante salientar que foi possível a apresentação presencial do protótipo

para três participantes, descartando a necessidade de assistir o vídeo. Para os
demais participantes, foi necessária a visualização do vídeo para fazer a avaliação.
30
6.2 Considerações
No quadro 1 é possível visualizar os cinco participantes da pesquisa:
Quadro 1 – Participantes da Pesquisa
Tempo de
Área de Atuação Faixa de Idade
Experiência
Gerente de Projetos 24 à 28 anos 4 a 6 anos
Especialista em Qualidade/Engenharia de Software e

24 à 28 anos 4 a 6 anos
Líder de Grupo
Especialista em Qualidade/Engenharia de Software,

32 à 36 anos Mais de 6 anos
Consultor e Professor em Computação Aplicada
Especialista em Qualidade/Engenharia de Software e

36 à 40 anos Mais de 6 anos
Líder de Grupo
Professor e Pesquisador em Computação Aplicada 28 à 32 anos Mais de 6 anos
Em relação aos participantes, foi possível identificar que todos os eles

possuem 24 anos ou mais. Dentre eles, cada um possui um perfil diferenciado onde
se podem identificar três tipos diferentes: alguns são profissionais que apenas estão
ligados ao mercado de TI (trabalham em empresas da área de software); alguns são
profissionais que estão ligados ao mercado de TI (trabalham em empresas da área
de software) e são professores, e outros que são professores, mas não estão
vinculados ao mercado de TI. Dessa forma, foi possível obter respostas com três
pontos de vista diferentes.
Todos os participantes acham que a ferramenta pode agregar valor ao dia a
dia. Foi salientada que principalmente para profissionais que trabalham com
Gerência da Configuração, a ferramenta é uma forma de manter a "saúde e bem
estar" dos artefatos.
Os participantes também acham que a ferramenta melhoraria muito a
agilidade em auditar os sistemas, o que é um ponto positivo, pois essa é a principal
finalidade da ferramenta. Um dos participantes cita que na empresa onde trabalha
são auditados dezenas de sistemas anualmente, e é muito custoso identificar se o
31
sistema está seguindo o padrão de pastas e arquivos, além de ter que verificar
documentos obrigatórios manualmente. Essa ferramenta é potencial para auxiliar
nisso.
A ferramenta também foi considerada flexível em relação a possibilidade de
customização para cada organização, uma vez que é permitido fazer o cadastro de
itens de configuração, produtos de trabalho, padrões, baselines, entre outros. Um
ponto citado em várias respostas foi a possibilidade de quantificação de forma
automática das métricas críticas quando são executadas as auditorias, onde através
da realização da auditoria pela ferramenta já é possível gerar, automaticamente,
uma série de indicadores para a gestão da qualidade. Com o processo
automatizado, os relatórios poderiam facilmente ser utilizados periodicamente para
avaliação da qualidade do desenvolvimento e maturidade da equipe. Dessa forma,
seriam fornecidas informações relevantes de forma simples e ágil para tomada de
decisão e avaliação da equipe.
Em síntese, todos acharam que a ferramenta possui navegação intuitiva,
simples e de fácil compreensão, após o entendimento de seus elementos. Em
relação a interface também acharam objetiva e clara, onde a mesma possui padrões
bem definidos, facilitando o entendimento do usuário após a compreensão de seus
padrões. Os termos e vocabulários utilizados na ferramenta também foram
considerados adequados na maioria das respostas.
6.3 Resultado da Avaliação
Dois de cinco participantes acham que a ferramenta atende a necessidade de

uma auditoria física de configuração, enquanto três acham que a ferramenta atende
parcialmente. Em relação à ferramenta atender a necessidade de automatizar as
auditorias físicas e auxiliar no fornecimento de métricas, três acham que a
ferramenta atende, e dois acham que a ferramenta atende parcialmente.
Todos os participantes da pesquisa acham que o software está maduro para
ser utilizado em um ambiente real. No entanto, quase todos destacam a
necessidade de realizar alguns testes, utilizando uma versão beta, passível de
falhas. Dessa forma, será possível identificar potenciais evoluções da ferramenta
com seu uso efetivo. Essas evoluções poderiam ser coletadas através da execução
da ferramenta em alguns projetos reais para obter feedbacks.
32
6.4 Melhorias Sugeridas
Muitas melhorias foram sugeridas para que a ferramenta evoluísse mais

ainda. Um dos pontos comentados foi à possibilidade de gerar visualizações com os
dados coletados com as métricas, bem como o histórico das auditorias. Assim, as
informações coletadas poderão ser utilizadas para avaliar quais são os principais
problemas detectados em auditorias, quais os artefatos não seguem o padrão,
cruzando dados inclusive de diferentes projetos. Neste caso, alguns pontos citados
acima já são tratados pela ferramenta, como a possibilidade de gerar relatórios e
gráficos com as informações coletadas nas auditorias, que são armazenadas no
banco de dados, para futuras consultas. No entanto, poderiam ser criados novos
relatórios e gráficos. Um exemplo seria a criação de relatórios para cruzar as
informações de projetos diferentes, como foi citado acima.
Outra questão a ser melhorada em relação aos relatórios e gráficos seria seus
títulos e descrições, deixando os mesmos mais intuitivos em relação ao que será
apresentado. Dessa forma, ficaria explícito ao usuário que essas funcionalidades
têm o objetivo de indicar a qualidade das baselines, de forma amigável e de fácil
análise.
Além disso, uma funcionalidade sugeria foi a criação de um padrão de
estrutura de diretórios por organização. A ferramenta disponibiliza essa
funcionalidade por projeto. Neste caso, seria útil ser criado um novo cadastro de
padrão de diretórios por organização (se aplicaria a todos os projetos) ao invés de
por projeto, assim o usuário poderia optar em utilizar por projeto, por organização ou
então mesclar os dois. Essa melhoria iria reduzir a necessidade de ser cadastrado
todo um padrão de estrutura para cada projeto, visto que muitas vezes os projetos
possuem uma parte da estrutura de diretórios iguais a todos os outros, e outra parte
customizada conforme a necessidade do projeto. O mesmo vale para as baselines
padrão que a organização pode possuir em seus projetos, por exemplo, Baseline de
Planejamento, Baseline de Escopo, Baseline de Testes, Baseline de Entrega 1, etc.
Em relação a interface, foi indicado que algumas melhorias estéticas e
funcionais que poderiam ser feitas, como destaque maior para os botões de ação,
segmentação e agrupamento das informações correlacionadas em diferentes
elementos visuais (box, fields, etc).
33
7 CONCLUSÃO
Todos os objetivos estabelecidos na metodologia foram cumpridos. Os

estudos bibliográficos foram realizados, a arquitetura da ferramenta foi projetada, a
mesma foi desenvolvida, e por fim, a pesquisa que avaliou as funcionalidades dessa
ferramenta foi submetida. No Apêndice L pode ser visualizado o cronograma
completo do trabalho.
Através da pesquisa realizada, foi possível identificar que a exploração do
tema deste trabalho apresentou resultados relevantes para a atividade de auditoria
de gerência da configuração, além de abrir caminho para novos estudos
relacionados ao mesmo.
Conclui-se que a auditoria da configuração é uma tarefa muito importante
para manter a integridades das baselines. Essa atividade muitas vezes acaba sendo
impactada devido ao curto prazo dos projetos, que nos dias atuais, é um fator muito
comum nas empresas de software. Dessa forma, a ferramenta desenvolvida foi
considerada, nos resultados da pesquisa, um grande potencial para apoiar o
gerenciamento das auditorias físicas e automatizar suas possíveis atividades.
Como continuidade deste trabalho, busca-se a publicação em meios
científicos, com o objetivo de aprimorar o diálogo entre os interessados e
compartilhar os resultados obtidos com a comunidade acadêmica.
34
A TOOL TO SUPPORT SOFTWARE CONFIGURATION AUDITS
Abstract: The amount of information generated nowadays makes unavoidable the

use of computer systems. In turn, these systems are getting more complex every day
making their development more difficult. In addition, users are becoming more critics
creating the needed of changes and evolutions. Therefore, it required some form of
management so that an evolution does not become chaotic. The Configuration
Management provides a range of activities that supports and enables the controlled
absorption of changes while maintaining stability in the evolution of the project.
However, something is needed to validate if these activities were carried out
correctly. In this case, Configuration Audit seeks to validate whether the
Configuration Management activities have been implemented correctly or not. Aiming
to improve the configuration audits, this paper will propose a tool to support the
management of physical configuration audits.
Keywords: Software Configuration Audits. Software Engineering. Software

Configuration Management.
35
REFERÊNCIAS
ASSEMBLA. Processo de Software - Plano de Gerência de Configuração. Disponível

em:
<https://www.assembla.com/spaces/procsw/wiki/Plano_de_Gerência_de_Configuração_
-_PROCSW>. Acesso em: 31 de março de 2013.
CIA, Thaís Miranda. Modelo de avaliação do processo de gerência da configuração

de software. São Carlos: USP, 2006.
CMMI-DEV. CMMI for development, Version 1.3. Carnegie Mellon University: Software
Engineering Institute, 2010.
DALL’OGLIO, Pablo. Adianti Framework para PHP. Lajeado: Edição do autor, 2012.
ENGHOLM JR., Hélio. Engenharia de Software na Prática. São Paulo: Novatec

Editora, 2011.
GERHARDT, Tatiana Engel; SILVEIRA, Denise Tolfo. Métodos de Pesquisa. 1ª Edição.

Porto Alegre: UFRGS, 2009.
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 5ª Edição. São Paulo:
Atlas, 2010.
GOLDENBERG, M. A arte de pesquisar. Rio de Janeiro: Record, 1997.
GUERRA, Ana Cervigni; COLOMBO, Regina Maria Thienne. Tecnologia da

Informação: Qualidade de Produto de Software. Brasília: PBQP Software, 2009.
FIGUEIREDO, Sávio; SANTOS, Gleison; ROCHA, Ana Regina. Gerência de

Configuração em Ambientes de Desenvolvimento de Software Orientados a
Organização. Rio de Janeiro: COPPE/UFRJ, 2004.
FURLANETO, Rodrigo. Ferramenta de Apoio a Gerência de Configuração de

Software. Blumenau: Universidade Regional de Blumenau, 2006.
FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza: UEC, 2002.
HIRAMA, Kechi. Engenharia de Software: Qualidade e Produtividade com

Tecnologia. Elsevier, 2012.
IEEE Std 828-1990. IEEE Standard Glossary of Software Engineering Terminology.

IEEE, 1990.
IEEE. SWEBOK - Overview. IEEE Computer Society. Disponível em:

<http://www.computer.org/portal/web/swebok/overview>. Acesso em: 29 de janeiro de
2013.
ISO/IEC. ISO/IEC TR 19759:2005. Disponível em:

<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=338
97> Acesso em: 29 de janeiro de 2013.
36
KEYES, Jessica. Software Configuration Management. Boca Raton: Auerbach, 2004.
MAMP. MAMP Web Site. Disponível em: <http://www.mamp.info/en/mamp/index.html>.

Acesso em: 12 de maio de 2013.
MURTA, Leonardo Gresta Paulino. ODYSSEY-SCM: Uma Abordagem De Gerência

De Configuração De Software Para O Desenvolvimento Baseado Em
Componentes. Rio de Janeiro: Universidade Federal do Rio de Janeiro, 2004.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Fundamentos de Metodologia

Científica. 5ª Edição. São Paulo: Editora Atlas, 2003.
PRESSMAN, Roger S. Software Engineering: A practitioner’s approach. 7ª Edição,

McGrawHill, 2009.
PHP. PHP Web Site. The PHP Group. Disponível em: <httm://www.php.net/>. Acesso
em: 12 de maio de 2013.
ROCHA, Ana Regina Cavalcanti da; MALDONADO José Carlos; WEBER, Kival Chaves.
Qualidade de Software: Teoria e Prática. University of Texas. Prentice Hall, 2001.
SANCHES, Rosely. Gerenciamento da Configuração de Software. São Paulo: USP,

2003. Disponível em: <http://www.inf.ufpr.br/silvia/ES/config/configR.pdf>. Acesso em:
25 de março de 2013.
SEI (Software Engineering Institute). CMMI Overview. Disponível em:

<http://www.sei.cmu.edu/cmmi/>. Acesso em: 20 de dezembro de 2012.
SOMMERVILLE, Ian. Software Engineering. 9ª Edição. Addison Wesley, 2010.
SWEBOK. Guide to the Software Engineering Body of Knowledge (SWEBOK). IEEE

Computer Society. Los Alamitos: IEEE, 2004.
OLIVEIRA, Karine Coelho de Amorim. Um processo de Gerência de Configuração

baseado no nível 2 do CMMI estagiado para Fábricas de Software Orientadas a
Produto. Pernambuco: Universidade Federal de Pernambuco, 2007.
ORACLE. Oracle Web Site – MySQL Overview. Oracle Corporation. Disponível em:
<http://www.oracle.com/us/products/mysql/overview/index.html>. Acesso em: 12 de maio
de 2013.
WAINER, Jacques. Métodos de pesquisa quantitativa e qualitativa para a Ciência

da Computação. Campinas: Unicamp, 2007.
WESTFALL, Linda. Software Configuration Management Audits. The Westfall Team,

2006.
YANG, Bo. Knowledge-Enhanced Change Audit for Configuration Management.

Beijing: IBM Research - China, 2010.
37
APÊNDICE A – GERÊNCIA DA CONFIGURAÇÃO NO CMMI
Quadro 2 – Atividades da CM x Práticas Especificas do CMMI
Identificação de
Gerenciamento
Gerenciamento
de Liberação e
Configuração
Configuração
Configuração
Configuração
Auditoria de
Controle de
Atividades da CM x Práticas Especificas
Relato da
Entrega
de CM
SP 1.1 - Identificar Itens de Configuração X
SP 1.2 - Estabelecer um Sistema de CM X X X X X X
SP 1.3 - Criar ou Entregar Baselines X
SP 2.1 - Registrar Pedidos de Mudanças X
SP 2.2 - Controlar Itens de Configuração X
SP 3.1 - Estabelecer Registros de CM X X X
SP 3.2 - Realizar Auditorias de Conf. X
Fonte: Figueiredo, Santos, Rocha (2004).

38
APÊNDICE B – CHECKLIST DE AUDITORIA FUNCIONAL
Quadro 3 – Checklist de Auditoria Funcional
ID Identificação S/N/NA Desvios Responsável
<Preencher
Os itens de configuração alcançaram seus <Detalhar
com o
1 requisitos de funcionalidade especificados <S/N/NA> o desvio
responsável
em sua documentação? ocorrido>
pelo desvio.>
<Preencher
Foram identificadas e registradas quaisquer <Detalhar
com o
2 discrepâncias em relação aos requisitos de <S/N/NA> o desvio
responsável
funcionalidades dos itens de configuração? ocorrido>
pelo desvio.>
Há evidências de que todos os requisitos <Preencher

<Detalhar
do sistema/software podem ser rastreados com o
3 <S/N/NA> o desvio
para código-fonte, testes, procedimentos e responsável
ocorrido>
resultado dos testes? pelo desvio.>
As bibliotecas utilizadas no
<Preencher
desenvolvimento do programa de software <Detalhar
com o
4 foram previstos no Plano de Gerência de <S/N/NA> o desvio
responsável
Configuração ou em algum documento de ocorrido>
pelo desvio.>
arquitetura?
<Preencher
A construção do sistema está em <Detalhar
com o
5 conformidade com o padrão de arquitetura <S/N/NA> o desvio
responsável
adotado? ocorrido>
pelo desvio.>
<Preencher
Os testes realizados asseguram a <Detalhar
com o
6 implementação da funcionalidade dos itens <S/N/NA> o desvio
responsável
de configuração? ocorrido>
pelo desvio.>
<Preencher
<Detalhar
As mudanças nos requisitos foram com o
7 <S/N/NA> o desvio
contempladas nos itens de configuração? responsável
ocorrido>
pelo desvio.>
<Preencher
<Detalhar
Os itens de configuração de documentação com o
8 <S/N/NA> o desvio
estão de acordo com seus templates? responsável
ocorrido>
pelo desvio.>
<Preencher
Foram identificadas e registradas quaisquer <Detalhar
com o
9 discrepâncias em relação aos templates <S/N/NA> o desvio
responsável
dos itens de configuração? ocorrido>
pelo desvio.>
39
Se um teste de stress foi realizado, os <Preencher

<Detalhar
resultados foram suficientes para assegurar com o
10 <S/N/NA> o desvio
que o desempenho do item de configuração responsável
ocorrido>
é compatível com a especificação? pelo desvio.>
Os itens de configuração presentes no

programa de software, mais
<Preencher
especificamente os códigos-fonte, <Detalhar
com o
11 satisfazem a matriz de rastreabilidade, ou <S/N/NA> o desvio
responsável
seja, os itens presentes na matriz de ocorrido>
pelo desvio.>
rastreabilidade estão presentes na
baseline?
Para os requisitos que não foram <Preencher

<Detalhar
verificados ou não passaram na verificação, com o
outros testes foram programados? (por responsável
ocorrido>
exemplo, teste de regressão) pelo desvio.>
<Preencher
<Detalhar
com o
13 Foram verificados todos os requisitos? <S/N/NA> o desvio
responsável
ocorrido>
pelo desvio.>
Existe alguma não-conformidade achada

<Preencher
nas auditorias anteriores que não foram <Detalhar
com o
14 executadas as ações de correção? Se sim, <S/N/NA> o desvio
responsável
existe um plano e/ou cronograma para ocorrido>
pelo desvio.>
finalização desta atividade?
<Preencher
Toda a documentação associada aos itens <Detalhar
com o
15 de configuração foram colocados sob <S/N/NA> o desvio
responsável
controle da Gerência de Configuração? ocorrido>
pelo desvio.>
Fonte: ASSEMBLA (2013).

40
APÊNDICE C – CHECKLIST DE AUDITORIA FÍSICA
Quadro 4 – Checklist de Auditoria Física
ID Identificação S/N/NA Desvios Responsável
<Preencher
A estrutura do repositório está de <Detalhar
com o
1 acordo com a estrutura definida no <S/N/NA> o desvio
responsável
Plano de Gerência de Configuração? ocorrido>
pelo desvio.>
Os itens de configuração armazenados <Preencher

<Detalhar
no repositório estão definidos no Plano com o
2 <S/N/NA> o desvio
de Gerência de Configuração e vice- responsável
ocorrido>
versa? pelo desvio.>
<Preencher
A localização dos itens de configuração <Detalhar
com o
3 está conforme definido no Plano de <S/N/NA> o desvio
responsável
Gerência de Configuração? ocorrido>
pelo desvio.>
<Preencher
A nomenclatura está seguindo o Plano <Detalhar
com o
4 de Gerência de Configuração do <S/N/NA> o desvio
responsável
projeto? ocorrido>
pelo desvio.>
<Preencher
Há mais de um item de configuração <Detalhar
com o
5 com o mesmo nome no mesmo <S/N/NA> o desvio
responsável
ambiente? ocorrido>
pelo desvio.>
As permissões de acesso aos itens de <Preencher

<Detalhar
configuração estão seguindo as com o
6 <S/N/NA> o desvio
definições expressas no Plano de responsável
ocorrido>
Gerência de Configuração e Ambiente? pelo desvio.>
Os artefatos que estão no ambiente <Preencher

<Detalhar
controlado estão sendo alterados com o
7 <S/N/NA> o desvio
somente mediante uma Solicitação de responsável
ocorrido>
Mudança? pelo desvio.>
<Preencher
A equipe tem conhecimento do Plano <Detalhar
com o
8 de Gerência de Configuração e <S/N/NA> o desvio
responsável
Ambiente? ocorrido>
pelo desvio.>
<Preencher
As alterações da estrutura do <Detalhar
com o
9 repositório estão sendo feitas somente <S/N/NA> o desvio
responsável
pela Gerência de Configuração? ocorrido>
pelo desvio.>
10 Os itens de configuração estão sendo <S/N/NA> <Detalhar <Preencher

excluídos ou renomeados somente pela o desvio com o
41
Gerência de Configuração? ocorrido> responsável

pelo desvio.>
<Preencher
Os papeis de todos os envolvidos na <Detalhar
com o
11 Configuração foram citados no Plano de <S/N/NA> o desvio
responsável
Gerência de Configuração e Ambiente? ocorrido>
pelo desvio.>
<Preencher
Após a mudança do Plano de Gerência <Detalhar
com o
12 de Configuração e Ambiente, houve a <S/N/NA> o desvio
responsável
divulgação? ocorrido>
pelo desvio.>
<Preencher
Todos os artefatos estão sendo <Detalhar
com o
13 alterados pela ferramenta de Controle <S/N/NA> o desvio
responsável
de Versão? ocorrido>
pelo desvio.>
<Preencher
<Detalhar
Os comentários estão sendo feitos em com o
todos os Commits? responsável
ocorrido>
pelo desvio.>
<Preencher
<Detalhar
Os backups estão sendo realizados com o
com sucesso? responsável
ocorrido>
pelo desvio.>
<Preencher
Os Relatórios de Backup estão sendo <Detalhar
com o
16 enviados para o Gerente de <S/N/NA> o desvio
responsável
Configuração? ocorrido>
pelo desvio.>
<Preencher
As ferramentas para utilização da <Detalhar
com o
17 Gerência de Configuração e dos <S/N/NA> o desvio
responsável
envolvidos no projeto foram definidas? ocorrido>
pelo desvio.>
<Preencher
<Detalhar
Estão sendo usadas somente com o
ferramentas definidas? responsável
ocorrido>
pelo desvio.>
Fonte: ASSEMBLA (2013).

42
APÊNDICE D – GERÊNCIA DA CONFIGURAÇÃO NO CMMI
Quadro 5 – Trab. Relacionado: Avaliação de Ferramentas de CM
Rational Borland
Processo CVS
ClearCase StarTeam
1. Processo de Definição da Politica Organizacional
DIP 1.1 – Definição da Politica Organizacional N/A N/A N/A

de Gerência da Configuração
DIP 1.2 – Definição de Repositório F F F
DIP 1.3 – Definição do Grupo de Gerência da N/A N/A N/A

Configuração
DIP 1.4 – Elaboração do Plano de Gerência da N/A N/A N/A

Configuração de Software
2. Identificação da Configuração
IIC 2.1 – Identificação dos Itens de N/A N/A N/A

Configuração de Software
3. Controle da Configuração
PCC 3.1 – Controle de Mudanças N F N
PCC 3.2 – Definição de Baselines F F F
PCC 3.3 – Armazenamento de Status de Itens F F F

de Configuração
4. Relato da Situação da Configuração
DSC 4.1 – Disponibilização do Status da L L L

Configuração
5. Avaliação da Configuração
AGC 5.1 – Auditoria de Gerência de N/A N/A N/A

Configuração
AGC 5.2 – Coleta de Métricas de Gerência da P L P

Configuração
6. Gerência de Liberação e Entrega
GLE 6.1 – Integração do Software F L P
GLE 6.2 – Pacote de Releases L L L

43
7. Controle de Subcontratados e Fornecedores
CSF 7.1 – Monitoramento do Subcontratado N/A N/A N/A
CSF 7.2 – Auditoria de Gerencia de N/A N/A N/A

Configuração do Subcontratado
Fonte: Cia (2006).

Nota: N/A = Não se aplica (não tratado pela
ferramenta);
N = Atributo não atingido pelo processo (<15%);
P = Atributo atingido apenas parcialmente (15 – 50 %);
L = Atributo atingido largamente pelo processo (51 –
85 %);
F = Atributo atingido completamente (86 – 100 %).
44
APÊNDICE E – TRABALHO RELACIONADO: SISTEMA PARA

GERENCIAMENTO DE CM
Figura 10 – Trab. Relacionado: Cadastro de Auditoria
Fonte: Furlaneto (2006).
Figura 11 – Trab. Relacionado: Relatório de Auditoria
Fonte: Furlaneto (2006).

45
APÊNDICE F – REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS
1. Requisitos Funcionais
Quadro 6 – Requisito Funcional 1
Requisito RF001
Nome Permitir estabelecer e gerenciar os usuários do sistema
Descrição
O sistema deverá permitir o estabelecimento e gerenciamento de usuários que utilizaram

o sistema.
Requisito RF002
Nome Permitir estabelecer projetos
Descrição
O sistema deve permitir o estabelecimento de projetos, onde poderá ser definido a data de
inicio e fim.
Requisito RF003
Nome Permitir estabelecer baselines
Descrição
O sistema deve permitir o estabelecimento de baselines para os projetos.

46
Requisito RF004
Nome Permitir estabelecer diretórios
Descrição
O sistema deve permitir o estabelecimento de diretórios.
Requisito RF005
Nome Permitir o estabelecer artefatos vinculados a uma baseline e um

diretório
Descrição
O sistema deve permitir o estabelecimento de artefatos. Ao cadastrar um artefato, deve

ser permitido que o mesmo seja vinculado a uma baseline e um diretório. Quando um
artefato for cadastrado, obrigatoriamente deverá ser informado sua baseline e seu
diretório.
Requisito RF006
Nome Permitir estabelecer padrões de estrutura para diretórios
Descrição
O sistema deve permitir o estabelecimento de padrões de estruturas para diretórios.

Essas estruturas padrões deveram ser consideradas nas auditorias.

47
Requisito RF007
Nome Permitir estabelecer padrões de nomenclatura para artefatos
Descrição
O sistema deve permitir o estabelecimento padrões de nomenclatura dos artefatos. Essas

nomenclaturas padrões deveram ser consideradas nas auditorias.
Requisito RF008
Nome Permitir estabelecer auditorias manuais
Descrição
O sistema deve permitir o cadastro de auditorias manuais. Ao cadastrar uma auditoria,

deverá ser informado seu tipo, que deve ser igual a “Manual”. Neste tipo de auditoria, o
usuário deverá cadastrar manualmente os itens do checklist que pertencem à auditoria.
Esse item de checklist deve, por consequência, gerar uma métrica. Essa métrica deve ser
informada no mesmo momento em que é cadastrado o item.
Os itens da auditoria devem possuir um status, que ser conforme descrito a seguir:
- Aprovado: Indica que o item foi aprovado.
- Reprovado: Indica que o item foi reprovado e possui inconsistências, nesse caso, devem
ser cadastradas as inconformidades do item em questão.
- Parcial: Indica que o item foi aprovado parcialmente.

48
Requisito RF009
Nome Permitir estabelecer auditorias automáticas
Descrição
O sistema deve permitir o cadastro de auditorias automáticas. Ao cadastrar uma auditoria,

deverá ser informado seu tipo, que deve ser igual a “Automática”. Neste tipo de auditoria,
deve ser selecionado os agentes, que por sua vez, deverão realizar a auditoria
automática.
Esse item de checklist deve, por consequência, gerar uma métrica. Essa métrica deve ser
cadastrada automaticamente quando a verificação for executada.
Requisito RF010
Nome Permitir estabelecer métricas
Descrição
O sistema deve permitir o cadastro de métricas. Essa métrica será vinculada a um item de
checklist no momento do cadastro da auditoria. A métrica é composta pelo seu nome e
valor, e deve ser utilizada como dados para relatórios futuros.
Requisito RF011
Nome Permitir cadastrar inconformidades resultantes de auditorias
Descrição
O sistema deve permitir o cadastro de inconformidades de auditorias. As inconformidades

devem ser relacionadas aos itens de checklist das auditorias. No caso de auditorias
automáticas, sistema deve efetuar esse cadastro automaticamente.

49
Requisito RF012
Nome Permitir o cadastro de métricas resultantes de auditorias
Descrição
O sistema deve permitir a geração de relatórios e gráficos de auditorias que foram

realizadas.
Requisito RF013
Nome Permitir a geração de relatórios e gráficos de auditorias
Descrição
O sistema deve permitir a geração de relatórios e gráficos de auditorias que foram

realizadas.
2. Requisitos Não-Funcionais
Quadro 19 – Requisito Não Funcional 1
Requisito RNF001
Nome Utilizar arquitetura MVC
Descrição
O ferramenta deve utilizar a arquitetura MVC.

50
Requisito RNF002
Nome Utilizar plataforma WEB
Descrição
O sistema deve ser desenvolvido em uma plataforma WEB.
Requisito RNF003
Nome Utilizar linguagem de programação PHP
Descrição
A ferramenta deve utilizar a linguagem de programação PHP.
Requisito RNF004
Nome Utilizar banco de dados MySQL
Descrição
Utilizar o banco de dados MySQL para manipular os dados do sistema.
Requisito RNF005
Nome Utilizar servidor Web Apache
Descrição
A ferramenta deve utilizar o servidor Web Apache.

51
Requisito RNF006
Nome Utilizar framework Adianti Framework para PHP
Descrição
A ferramenta deve ser desenvolvida utilizando o framework Adianti Framework para PHP.

52
APÊNDICE G – DETALHAMENTO DO DIAGRAMA DE CLASSES
Quadro 25 – Descrição do Diagrama de Classes
Nome da Classe Descrição
Classe utilizada para representar um projeto dentro do

Project
sistema.
Classe utilizada para representar uma baseline que estará

Baseline
vinculada a um projeto.
Classe utilizada para representar um diretório que estará

Directory
vinculado a um projeto.
Classe utilizada para representar um artefato do projeto.

Artefact
Esses artefato será vinculado a uma baseline e um diretório.
Classe utilizada por controlar o vinculo do diretório com seus

DirectoryArtefact
artefatos.
Classe utilizada para controlar o vinculo da baseline com

BaselineDirectory
seus diretórios.
Classe utilizada para representar uma auditoria dentro do

Audit
sistema.
Classe utilizada para representar uma verificação dentro do

sistema. Uma auditoria possui um checklist que é composto
Verification
por itens (perguntas). A verificação representa uma dessas
perguntas.
Classe utilizada para representar o resultado de uma

VerificationResult verificação. A auditoria possui resultado de verificações.
Essa classe irá representar esses resultados.
Classe utilizada para representar uma inconformidade de um

Unconformity
resultado de auditoria, caso a mesma não esteja aprovada.
Classe utilizada para representar uma métrica dentro do

Metric sistema. Uma verificação possui métricas. Essa classe irá
representar essas métricas.
Classe utilizada para representar o resultado de uma métrica

MetricResult
dentro do sistema.
Classe utilizada para representar uma agente que será

Agent
executada nas auditorias automáticas.
Classe utilizada para representar um usuário dentro do

User
sistema.

53
APÊNDICE H – DETALHAMENTO DO DIAGRAMA ER
Quadro 26 – Descrição do Diagrama ER
Nome da Tabela Descrição
Project Tabela destinada aos projetos existentes dentro do sistema.
Baseline Tabela destinada as baselines dos projetos.
Directory Tabela destinada aos diretórios dos projetos.
Tabela destinada aos padrões de artefatos. Esses artefatos

Artefact
estarão vinculados a uma baseline e um diretório.
Directory_Artefact Tabela destinada aos vínculos entre o diretório e um artefato.
Tabela destinada aos vínculos entre uma baseline e um

Baseline_Directory
diretório.
Audit Tabela destinada as auditorias de uma baseline.
Tabela destinada as verificações que serão vinculadas nas

Verification
auditorias.
Tabela destinada aos resultados das verificações, ou seja, as

Verification_Result
respostas das perguntas da auditoria.
Tabela destinada as inconformidades de um resultado de

Unconformity
verificação, caso a mesma não seja aprovada.
Metric Tabela destinada as métricas de uma verificação.
Tabela destinada aos resultado das métricas que serão

Metric_Result
geradas pelos resultados das verificações.
Tabela destinada aos agentes que serão executados quando

Agent
uma auditoria for automática.
User Tabela destinada ao usuários que terão acesso ao sistema.
SVN Tabela destinada aos parâmetros do SVN.

54
APÊNDICE I – DETALHAMENTO DOS CASOS DE USO
Quadro 27 – Descrição do Caso de Uso 1
Caso de Uso UC01
Nome Configure SVN
Ator (es) Auditor
Descrição
O sistema deve ter acesso as pastas do SVN. Para isso, o auditor deve configurar o SVN
informando o nome e caminho do repositório onde estão salvo os arquivos dos projetos.
Esses dados devem ser informados para que as auditorias automáticas tenham acesso
aos projetos para realizar as verificações necessárias. (Ver figura 12)
Figura 12 – Interface do Caso de Uso 1 (SVN)

55
Caso de Uso UC002
Nome Configure Artefacts
Ator (es) Auditor
Descrição
O auditor deverá cadastrar os artefatos (Itens de Configuração) que serão adicionados

nas baselines. Quando as baselines forem criadas, esses artefatos, com seus respectivos
padrões, já deverão estar cadastrados no sistema. (Ver figura 13)
Figura 13 – Interface do Caso de Uso 2 (Artefatos)

56
Caso de Uso UC003
Nome Configure Verifications
Ator (es) Auditor
Descrição
O auditor deverá cadastrar as verificações (Itens de Checklist) que serão utilizadas nas
auditorias. Quando as auditorias forem criadas, essas verificações já deverão estar
cadastradas no sistema. Neste caso, algumas verificações já estarão cadastradas por
padrão, para serem utilizadas nas auditorias automáticas. (Ver figura 14)
Figura 14 – Interface do Caso de Uso 3 (Verificações)

57
Caso de Uso UC004
Nome Configure Metrics
Ator (es) Auditor
Descrição
Ao cadastrar as verificações, também deverão ser cadastradas as possíveis métricas para

essas verificações. Esse cadastro poderá ser acessado pelo cadastro de verificações,
pois cada verificações possui suas métricas especificas. Neste caso, algumas métricas já
estarão cadastradas por padrão, para serem utilizadas nas auditorias automáticas. (Ver
figura 15)
Figura 15 – Interface do Caso de Uso 4 (Métricas)

58
Caso de Uso UC005
Nome Configure Agents
Ator (es) Auditor
Descrição
O cadastro de auditorias automáticas permite que o auditor cadastre os agentes de

software que serão chamados para realizar as auditorias automáticas. A ferramenta já irá
possuir os agente nativos pré-cadastrados. (Ver figura 16)
Figura 16 – Interface do Caso de Uso 5 (Audit. Automática)

59
Caso de Uso UC006
Nome Keep Projects
Ator (es) Auditor
Descrição
Inicialmente, o auditor deve cadastrar um projeto. Neste cadastro deve ser informado o
nome do projeto, data de inicio, caminho da pasta do projeto no SVN (Local) e Login e
Senha do SVN. (Ver figura 17)
Figura 17 – Interface do Caso de Uso 6

60
Caso de Uso UC007
Nome Configure Diretories
Ator (es) Auditor
Descrição
Quando um projeto já estiver cadastrado no sistema, o auditor poderá criar seus

respectivas diretórios. O auditor deverá usar o Plano de Gerencia da Configuração como
apoio para esses cadastros, que irá conter os diretórios do projeto. (Ver figura 18)

61
Caso de Uso UC008
Nome Keep Baselines
Ator (es) Auditor
Descrição
Quando um projeto já estiver cadastrado no sistema, o auditor poderá criar suas

respectivas baselines. O auditor deverá usar o Plano de Gerencia da Configuração como
apoio para esses cadastros, que irá conter as baselines de um projeto, juntamente com
seus diretórios e artefatos. (Ver figura 19)
Figura 19 – Interface do Caso de Uso 8 (Baselines)

62
Caso de Uso UC009
Nome Keep Directories
Ator (es) Auditor
Descrição
Depois de cadastrar as baselines no sistema, o auditor deverá cadastrar para cada

baseline uma estrutura de diretórios que irá possuir artefatos. Os diretórios disponíveis
para este cadastro são os mesmo diretórios cadastrados no projeto. (Ver figura 20)
Figura 20 – Interface do Caso de Uso 9 (Diretórios)

63
Caso de Uso UC010
Nome Keep Artefacts
Ator (es) Auditor
Descrição
Durante o cadastro de diretórios, o usuário terá a possibilidade de vincular os artefatos

desse diretório. Os artefatos vinculados possui um padrão de nomenclatura que serão
considerados nas futuras auditorias. (Ver figura 21)
Obs: Ao vincular os diretórios e artefatos, em uma baseline, o auditor terá a opção de
copiar esses dados de um projeto já existente. Essa opção será criada para agilizar
processo, em vista de que muitos projetos possuem dados semelhantes (como a estrutura
de diretórios).
Figura 21 – Interface do Caso de Uso 10 (Artefatos)

64
Caso de Uso UC011
Nome Keep Audits
Ator (es) Auditor
Descrição
Quando a baseline, diretórios e artefatos estiverem cadastrados, o auditor poderá criar as

auditorias de uma baseline. (Ver figura 22) Cada baseline pode possuir várias auditorias e
existe dois tipos de auditorias que poderão ser cadastradas:
- Manual: O auditor deverá cadastrar manualmente todos os resultados da auditoria,
tais como verificações, inconformidades e métricas;
- Automática: O auditor irá apenas criar a auditoria e selecionada como automática,
através disso, o sistema irá criar os resultado da auditoria automaticamente.
Figura 22 – Interface do Caso de Uso 11 (Auditorias)

65
Caso de Uso UC012
Nome Keep Verifications
Ator (es) Auditor, Sistema
Descrição
Cada auditoria pode possuir uma ou várias verificações, que por sua vez são composta
por pelo código e nome. Essas verificações devem ser vinculadas nas auditorias pelo
auditor ou pelo sistema. (Ver figura 23) Ao serem vinculadas, as mesmas irão possuir um
status, que podem ser:
- Aprovado: Verificação não possui nenhuma inconformidade;
- Reprovado: Verificação possui uma inconformidade;
- Aprovado Parcial: Verificação possui advertências.
Figura 23 – Interface do Caso de Uso 12 (Verificações)

66
Caso de Uso UC013
Nome Keep Unconformities
Ator (es) Auditor, Sistema
Descrição
Caso uma verificação tenha o status como Reprovada ou Aprovada Parcial, a mesma irá
possui inconformidades que também devem ser cadastradas no sistema pelo auditor ou
pelo próprio sistema, dependendo se for manual ou automática. (Ver figura 24)
Figura 24 – Interface do Caso de Uso 13 (Inconformidade)

67
Caso de Uso UC014
Nome Keep Metrics
Ator (es) Sistema
Descrição
As verificações geram métricas para futuros relatórios. O valores dessas métricas também
serão cadastrados manualmente ou automaticamente. Neste caso, só será cadastrado o
valor da métrica, pois a própria métrica já é cadastrada e vinculada a uma verificação nas
configurações do sistema. (Ver figura 25)
Figura 25 – Interface do Caso de Uso 14 (Métricas)

68
Caso de Uso UC015
Nome Generate Reports
Ator (es) Usuário
Descrição
O usuário poderá gerar relatórios e gráficos através dos resultado das auditorias e suas
respectivas métricas. (Ver figura 26)

69
Caso de Uso UC016
Nome Generate Charts
Ator (es) Usuário
Descrição
O usuário poderá gerar relatórios e gráficos através dos resultado das auditorias e suas
respectivas métricas. (Ver figura 27)

70
APÊNDICE J – QUESTIONÁRIO DE AVALIAÇÃO
Rapid-Audit - Questionário do Trabalho de Conclusão
Este questionário visa avaliar o protótipo Rapid-Audit, desenvolvido para o trabalho

de conclusão do curso Análise e Desenvolvimento de Sistemas, da Universidade do
Vale do Rio dos Sinos (UNISINOS).
Pré-Requisito: Assistir o vídeo disponível no link:

http://andrewsjuchem.com/video.html
Publico alvo: Especialistas da área de Engenharia/Qualidade de Software.
Descrição: A ferramenta busca melhorar e apoiar a atividade de avaliação de

auditoria de configuração. Na Engenharia de Software, as auditorias podem ser
físicas ou funcionais, neste caso, a ferramenta visa atender apenas as auditorias
físicas. Essa ferramenta permite o cadastro de projetos e suas baselines, onde cada
baseline irá possuir suas respectivas auditorias. Essas auditorias podem ser
auditorias automáticas, onde o sistema irá efetuar as validações através dos agentes
cadastrados no próprio sistema, ou então, auditorias manuais onde o usuário efetua
as validações e cadastra os resultados manualmente. Os resultados das auditorias
irão gerar métricas, que avaliam a qualidade das baselines, e podem ser
consultadas através de relatórios ou gráficos.
Andrews Juchem
Estudante de Graduação em Análise e Desenvolvimento de Sistemas - UNISINOS
aajuchem@gmail.com
Prof. Ms. Pablo Dall'Oglio

Orientador e professor na UNISINOS
pablo.dalloglio@gmail.com
Qual sua faixa de idade?

( ) De 18 à 24 anos
( ) De 24 à 28 anos
( ) De 28 à 32 anos
( ) De 32 à 36 anos
( ) De 36 à 40 anos
71
( ) Mais de 40 anos
Qual sua área de atuação?

[ ] Analista de Qualidade de Software
[ ] Especialista em Qualidade/Engenharia de Software
[ ] Gerente de Projetos
[ ] Lider de Grupo
[ ] Administrador/Gerente de Configuração
[ ] Outro
Você tem quantos anos de experiência na sua área de atuação

(aproximadamente)?
( ) 1 ano ou menos
( ) 1 à 2 anos
( ) 2 à 4 anos
( ) 4 à 6 anos
( ) 6 anos ou mais
Que tipo de melhoria o software poderia agregar no dia-a-dia?
Como você avalia a navegabilidade deste software?
Como você avalia a interface deste software?
Como você avalia os termos/vocabulários que foram utilizados no software?

( ) Inadequados
( ) Parcialmente inadequados
( ) Indiferente
( ) Parcialmente adequados
( ) Adequados
O que você considera que poderia ser melhorado ou acrescentado no

software?
Você considera que o software está maduro para ser utilizado em um ambiente
real?
O quanto o software atende a necessidade de uma auditoria física de

configuração:
( ) Não atende
( ) Não atende parcialmente
( ) Indiferente
( ) Atende parcialmente
( ) Atende
O quanto o software atende a necessidade de automatizar a auditoria física de

configuração:
( ) Não atende
( ) Indiferente
72
( ) Atende
O quanto o software auxilia no fornecimento de métricas sobre as auditorias

de configuração:
( ) Não atende
( ) Indiferente
( ) Atende
Comentários/sugestões:
73
APÊNDICE L – CRONOGRAMA DO PROJETO
Figura 26 – Cronograma do Projeto

Uma Ferramenta de Apoio A Auditoria de C PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uma Ferramenta de Apoio A Auditoria de C PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS

UNIDADE ACADÊMICA DE GRADUAÇÃO

ANDREWS AZEVEDO JUCHEM

UMA FERRAMENTA DE APOIO À AUDITORIA DE CONFIGURAÇÃO DE

UMA FERRAMENTA DE APOIO À AUDITORIA DE CONFIGURAÇÃO DE

Trabalho de Conclusão de Curso

Orientador: Prof. MS. Pablo Dall’Oglio

UMA FERRAMENTA DE APOIO À AUDITORIA DA CONFIGURAÇÃO DE

Andrews Azevedo Juchem

Resumo: A quantidade de informações geradas nos dias atuais acabam tornando

Palavras-chave: Auditoria de Configuração. Engenharia de Software. Gerência da

Nos dias atuais, sistemas de software estão presentes em todos os lugares,

competitivo, as empresas necessitam de alguma solução que as ajude a evitar esse

1.1 Motivação e Justificativa

As auditorias de configuração são tradicionalmente conduzidas no

meio de agentes de software, eliminando dessa forma, a necessidade de efetuar

1.2.1 Objetivo Geral

Melhorar a atividade de avaliação em auditoria de configuração através da

1.2.2 Objetivos Específicos

a) Definir uma arquitetura para gerenciar a auditoria física de

Para analisar a implementação e resultados da Ferramenta de Apoio à

2.1 Qualidade de Software

Conforme Guerra (2009), a qualidade de software constitui uma área cuja

Visando buscar a Qualidade de Software, Pressman (2009) afirma que um

2.2 Engenharia de Software

O conceito “Engenharia de Software“ foi cunhado em 1969 por Fritz Bauer em

Para o Institute of Eletrical and Eletronic Engineering a Engenharia de

Com o propósito de criar um consenso sobre as áreas de conhecimento da

2.3 Processos de Software

Um processo de software é um conjunto de atividades e resultados

Segundo Pressman (2009), o processo de software é importante porque

Melhorar processos de software não é algo fácil. Sommerville (2011) afirma

2.4 Modelos de Processo de Software

Os modelos de processo de software buscam apoiar a produção do software

Pressman (2009) destaca que a aplicação inteligente de qualquer modelo de

Desenvolvido pelo SEI (Software Engineering Institute), o CMMI (Capability

O CMMI foi baseado nas melhores práticas para desenvolvimento e

2.5.1 Áreas de Processo

As Áreas de Processo são um cluster de práticas relacionadas em uma área

2.5.2 Objetivos Genéricos

Os objetivos genéricos são chamados “genéricos” porque a mesma

2.5.3 Objetivos e Práticas Específicas

Cada área de processo é definida por um conjunto de objetivos e práticas.

2.5.4 Níveis do CMMI

O CMMI suporta dois caminhos de melhoria usando níveis. Um deles permite

O CMMI-DEV (2010) associa estes dois caminhos com os dois tipos de

Esses níveis correspondem a duas formas de melhoria de processo,

a) Contínua: Possibilita à organização utilizar a ordem de melhoria que

b) Por estágios: Disponibiliza uma sequência pré-determinada para

O uso da representação contínua permite que você atinja níveis de

2.6 Gerência da Configuração

Gerência da Configuração (CM) é uma disciplina formal da engenharia de

Segundo Pressman (2009), a CM pode ser vista como uma atividade de

2.6.1 Atividades da Gerência da Configuração

Segundo o SWEBOK (2004), as atividades da CM são: Gerenciamento do

2.6.2 Gerência da Configuração conforme o CMMI

O CMMI trata a gerência da configuração como uma área de processo de

No apêndice A é possível visualizar a relação das atividades da Gerência da

2.7 Auditoria De Configuração De Software

Uma variedade de situações podem causar problemas durante o processo da

A auditoria de configuração de software é uma atividade realizada de forma

2.7.1 Auditoria Funcional

A finalidade da Auditoria Funcional (FCA) de software é garantir que o item de