PRÓ-REITORIA DE GRADUAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
Ciência da
Computação
GUIA DE GERÊNCIA DE CONFIGURAÇÃO
DE SOFTWARE PARA O MPS-BR
Autora: Adriana Reis de Almeida Rodrigues
Orientador: Vilson Carlos Hartmann
Co-orientador: Cândido Gerrero Salgado
2007
ADRIANA REIS DE ALMEIDA RODRIGUES
GUIA DE GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE PARA O MPS-BR
Trabalho apresentado ao
curso de Graduação em
Ciência da Computação
da Universidade Católica
de
Brasília,
como
requisito para obtenção
do Título de Bacharel em
Ciência da Computação.
Brasília
2007
Trabalho de autoria de Adriana Reis de Almeida Rodrigues, intitulado “Guia de
Gerência de Configuração de Software para o MPS-BR”, requisito parcial para
a obtenção do título de Bacharel em Ciência da Computação, defendida e
aprovada, em ---/---/--- pela banca examinadora constituída por:
___________________________________
Prof. Vilson Carlos Hartmann
Orientador
___________________________________
Prof. Cândido Gerrero Salgado
Co-orientador
___________________________________
Vilson Carlos Hartmann
__________________________________
Cândido Gerrero Salgado
Brasília
2007
Dedico o presente estudo aos meus
pais pelo apoio incondicional, sem o
qual não teria chegado até aqui, ao
meu marido Hernani e meus filhos
Bruno
e
Vítor,
por
tudo
representam na minha vida.
que
Agradeço aos nobres Professores
Vilson e Candido pelo apoio e
compreensão durante essa jornada.
À minha prima Pollyanna e à minha
irmã Karina que contribuíram, direta
ou indiretamente, para a realização
desse trabalho.
RESUMO
A demanda por produtos de software de qualidade, tem despertado o interesse
das empresas desenvolvedoras em uma área específica da Engenharia de
Software: a Qualidade de Software. Essa área visa garantir um produto final de
qualidade por meio do investimento na melhoria dos seus processos de
desenvolvimento. O que se dá através da implantação de padrões, normas e
modelos de referências. Dentre esses modelos destaca-se o MPS-BR, que é
voltado à realidade das empresas brasileiras. O referido modelo está dividido
em sete níveis de capacitação sendo que o presente trabalho refere-se à
Gerência de Configuração inserida no nível F. O MPS-BR, assim como outros
modelos, não é descritivo, ou seja, ele relata o que fazer para atingir suas
metas, mas não diz como. O objetivo desse trabalho é preencher essa lacuna,
na medida em que descreve os passos a serem seguidos para que os
desenvolvedores de software possam alcançar as metas estabelecidas no
MPS-BR para o processo de Gerência de Configuração.
Palavras-chave: Qualidade de Software. Modelos de Referência. Gerência de
Configuração.
Abstract
The demand for software products with quality, has collect such interest of
development companies in a specific area of the software engineering: the
software’s quality. This area might guarantee a final product with quality by
investing in best process of development. What happens by the creation of
patterns, IAS and model references. Among these models, we show the MPSBR that is focus to the Brazilian’s companies reality. This model is divided in
seven levels of capacity, and this work is referred to the configuration manager
in the F level. The MPS-BR, as the others models, isn’t de descriptive,
whatever, it relates what to do to reach your goals, but not how. The objective of
this work is to fulfill the spaces, as long as descript the steps to follow to the
software developers can reach the goals established in the MPS-BR to the
configurations managing.
Key words: Software’s quality. Reference Models. Configuration Managing.
Lista de quadros
Quadro 1: Áreas de processo – CMMI por estágios
Quadro 2: Áreas de processo – CMMI na representação contínua
Quadro 3: A visão sobre a GC em cada nível do CMMI
Quadro 4: Níveis de maturidade e processos do MPS-BR
Quadro 5: Pontos positivos do MPS-BR
Quadro 6: Subcaracterísticas da qualidade interna e externa
Quadro 7: Características da qualidade de uso
Quadro 8: Metas do MPS-BR X Subprocessos do Guia de Gerência de
Configuração
Lista de figuras
Figura 1: Modelo do ciclo de vida codifica-remenda
Figura 2: Modelo do ciclo de vida cascata
Figura 3: Modelo do ciclo de vida de Prototipagem evolutiva
Figura 4: Modelo do ciclo de vida espiral
Figura 5: Níveis de maturidade do CMMI
Figura 6: Base de construção do MPS.BR
Figura 7: Modelo de processos do MPS-BR
Figura 8: Evolução do grau de formalismo
Figura 9: Descrição de um item de configuração
Figura 10: Exemplo de política Trava-Modifica-resolve
Figura 11: Exemplo de política copia-Modifica-Resolve
Figura 12: Ciclo de uma requisição de mudança aprovada
Lista de siglas
BID - Banco Interamericano de Desenvolvimento
CMM - Modelo de Maturidade de Capacitação
CMMI - Modelo integrado de Maturidade de Capacitação
ES - Engenharia de Software
EUA – Estados Unidos da América
FINEP - Financiadora de Estudos e Projetos
GC - Gerência de Configuração
GQA - Garantia da Qualidade
HRD - Projetos de alto risco de desenvolvimento
IEC – Comissão Eletrotécnica Internacional
IEEE - Instituto de Engenheiros Eletricistas e Eletrônicos
IPPD - Desenvolvimento Integrado de Produtos e Processos
ISO - Organização Internacional para Padronização
MCT - Ministério da Ciência e Tecnologia
MCVS - Modelo de ciclo de vida do software
MED - Medição
MPS.BR - Melhoria de Processo do Software Brasileiro
NBR – Norma Brasileira
RUP – Processo Unificado da Rational
SEI - Instituto de Engenharia de Software
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro
SW - Software
SUMÁRIO
INTRODUÇÃO .......................................................................................................... 11
1 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ................................. 16
1.1 A Engenharia de Software................................................................................... 16
1.2 Paradigmas do ciclo de vida................................................................................ 18
2 QUALIDADE DE SOFTWARE ............................................................................... 26
2.1 Visão geral .......................................................................................................... 26
2.2 Qualidade do Processo ....................................................................................... 27
2.3 Qualidade do Produto ......................................................................................... 38
3 GERÊNCIA DE CONFIGURAÇÃO ........................................................................ 42
3.1 Abordagem Teórica ............................................................................................. 42
3.1.1 Visão Geral....................................................................................................... 42
3.1.2 Conceitos Iniciais ............................................................................................. 44
3.1.3 Definição do escopo e do grau de formalismo das tarefas de GCS ................. 46
3.2 Abordagem operacional....................................................................................... 47
3.2.1 Atividades de Gestão da Configuração ............................................................ 47
3.2.1.1 Identificação .......................................................................................................... ....47
3.2.1.2 Armazenamento ....................................................................................................... 49
3.1.2.3 Controle de versões ................................................................................................. 49
3.2.1.4 Controle de mudanças............................................................................................. 53
3.2.1.5 Relato de status ........................................................................................................ 56
3.2.1.6 Entrega na GC .......................................................................................................... 56
3.2.1.7 Auditoria da configuração ....................................................................................... 57
4 CONSTRUÇÃO DO GUIA ...................................................................................... 59
4.1
Definição do Layout ......................................................................................... 59
4.2
Definição dos subprocessos ............................................................................ 59
4.3
Definição dos anexos ...................................................................................... 64
4.4
Metas do MPS-BR X Guia de Gerência de Configuração ............................... 66
Conclusão ................................................................................................................. 68
Apêndice A – Guia para Gerência de Configuração de Software.............................. 70
Referência Bibliográfica .......................................................................................... 114
11
INTRODUÇÃO
Motivação
A competitividade no mercado, entre outros fatores, fez com que uma
área da engenharia de software crescesse nos últimos tempos: a Qualidade de
Software. A exemplo de outras áreas, as empresas desenvolvedoras de
softwares buscam a cada dia um diferencial a ser oferecido aos seus clientes; a
entrega de um software de qualidade é, além desse diferencial, uma
necessidade para que as organização se tornem bem-sucedidas.
“A qualidade de software é uma área da engenharia de software que
visa garantir, por meio da definição e da normatização dos processos de
desenvolvimento, a qualidade do software” (WIKIPÉDIA, 2007). De acordo com
a norma ISO 9000, qualidade é o grau com que um conjunto de características
de um determinado produto atende aos requisitos estipulados. No que diz
respeito à engenharia de software, a qualidade é subdividida em qualidade do
processo e qualidade do produto.
Quando há uma preocupação com a qualidade do processo de
desenvolvimento do software, estamos a caminho de produzir produtos de
qualidade visto que, dessa forma, estaremos adotando práticas que garantam a
qualidade do software desde o início de seu desenvolvimento.
Com o intuito de subsidiar o processo de desenvolvimento e a
manutenção de softwares de qualidade, foram desenvolvidos alguns modelos
de referência de qualidade, entre eles podemos destacar o Modelo de
Maturidade de Capacitação para Software (SW-CMM), o Modelo Integrado de
Maturidade de Capacitação (CMMI) e o MPS-BR (Melhoria de Processo do
Software Brasileiro).
Koscianski e Soares (2007) relatam que o SW-CMM foi criado no final da
década de 1980 pelo SEI (Instituto de Engenharia de Software) e é um modelo
de capacitação de processo, patrocinado pelo Departamento de Defesa dos
Estados Unidos da América (EUA) para a avaliação da capacidade dos seus
12
fornecedores de software. Este modelo é específico para a área de software e
tem foco nos processos, pois para o referido modelo esse é o fator com maior
potencial de melhoria a curto prazo.
Segundo os mesmos autores, o sucesso do CMM, levou ao
aparecimento de diversos outros modelos direcionados a outras áreas, como
gestão de recursos humanos e aquisição de software. Então, para integrar
todos esses modelos, surgiu o CMMI, como uma evolução do CMM. O objetivo
do CMMI é “fornecer direcionamentos para melhorar os processos de uma
organização e sua capacidade de gerenciar o desenvolvimento, aquisição e
manutenção de produtos e serviços” (SEI, 2006).
Tanto o CMM como o CMMI descrevem 5 níveis de maturidade do
processo, são eles: Nível 1(Inicial), Nível 2(Gerencial), Nível 3(Definido), Nível
4 (Quantitativamente definido) e Nível 5 (Otimizado).
Koscianski e Soares (2007) relatam sobre outro modelo de referência, o
MPS-BR, que teve seu início em dezembro 2003. Ele constitui um programa de
melhoria de processo do software Brasileiro e é coordenado pela Associação
para Promoção da Excelência do Software Brasileiro (SOFTEX). Seu objetivo é
permitir que micro, pequenas e médias empresas tenham acesso à melhoria de
processos de software. Assim, ele é adequado à realidade brasileira, sem
deixar de ser compatível com os padrões de qualidade internacionais.
O MPS-BR também é estruturado em níveis de maturidade de evolução
dos processos de software e na capacidade para a avaliação e melhoria da
qualidade e da produtividade dos softwares. Ele apresenta sete níveis de
maturidade, a saber: Nível A (Em Otimização), Nível B (Gerenciado
Quantitativamente), Nível C (Definido), Nível D (Largamente Definido), Nível E
(Parcialmente Definido), Nível F (Gerenciado) e Nível G (Parcialmente
Gerenciado).
Conforme descrito no guia geral V1.2 do MPS-BR:
[...] para cada um destes sete níveis de maturidade é atribuído um
perfil de processos que indicam onde a organização deve colocar o
esforço de melhoria. O progresso e o alcance de um determinado
13
nível de maturidade do MPS-BR se obtém quando são atendidos os
propósitos e todos os resultados esperados dos respectivos
processos e dos atributos de processo estabelecidos para aquele
nível. (SOFTEX, 2007, p.16).
A Gerência de Configuração (GC), devido a sua importância, está
presente tanto no CMMI como no MPS-BR. Neste último, ela é descrita no nível
F, o qual se refere à garantia da qualidade. “O propósito do processo de
Gerência de Configuração é estabelecer e manter a integridade de todos os
produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os
envolvidos” (SOFTEX, 2007, p.28).
Pressman (2002) relata que inúmeras mudanças ocorrem durante o ciclo
de desenvolvimento de um software, pelos mais diversos motivos, que podem
ser novas condições do mercado, novas necessidades dos clientes,
reorganização dos negócios ou restrições de orçamento e cronograma. Assim,
podemos perceber que a GC é fundamental para a administração de todas
essas modificações durante o desenvolvimento e a manutenção de um
software.
“A GC é um conjunto de atividades de apoio ao desenvolvimento do
software que é aplicada ao longo de todo o processo de software. Essas
atividades são desenvolvidas para (1) identificar as modificações, (2) controlar
modificações, (3) garantir que as modificações sejam adequadamente
implementadas e (4) relatar as modificações a outros que possam ter interesse.
Essas atividades começam quando o projeto de engenharia de software se
inicia e só termina quando o software é retirado de operação” (PRESSMAN,
2002).
Produzir software de qualidade traz diversos benefícios, tanto para as
empresas quanto para os clientes, uma vez que como conseqüência de tal
prática, as empresas estabelecem processos bem definidos, reduzem o
retrabalho, aproveitam melhor os recursos, diminuem riscos, reduzem custos e,
na medida do possível, cumprem o cronograma. Já para o cliente, entre outras
vantagens, podemos destacar que ele adquire um produto que atende às suas
necessidades, num menor preço e dentro do prazo estabelecido.
14
Problema diagnosticado
O
MPS-BR
é
muito
importante
para
as
empresas brasileiras
desenvolvedoras de software, pois é um modelo voltado para nossa realidade,
porém é limitado, uma vez que esse modelo descreve o que uma organização
deve fazer para alcançar o nível F de maturidade, porém não descreve como
fazê-lo. O presente trabalho visa preencher essa lacuna, no que se refere à
Gerência de Configuração, pois culmina com a implementação de um guia que
orienta a implantação desse processo.
Restrições
O nível F do MPS.BR, inclui, além da Gerência de Configuração, a
Garantia da Qualidade (GQA) e a Medição (MED) , porém os dois últimos
tópicos não serão contemplados no presente trabalho, sendo esta uma
restrição desse trabalho.
Beneficiados
Como beneficiados com este estudo, destacamos os desenvolvedores
de softwares, de modo geral, especialmente empresas que buscam atingir o
nível F de maturidade do MPS-BR, podem ser beneficiados com este estudo,
pois o mesmo servirá como um guia que descreve as atividades a serem
desenvolvidas para que as metas, correlatas à Gerência de Configuração,
definidas no referido modelo sejam alcançadas.
Objetivo
O objetivo do presente trabalho é descrever de forma detalhada as
atividades a serem desenvolvidas pelas empresas desenvolvedoras de
software para que elas possam atingir as metas estabelecidas para o nível F do
MPS-BR no que tange ao processo de Gerência de Configuração.
Resultados Esperados
Dessa forma, os resultados esperados é que desenvolvedores de
software tenham um material de apoio que possa efetivamente auxiliá-los a
atingir as metas estabelecidas para o nível F do MPS-BR com relação ao
processo de Gerência de Configuração.
15
Metodologia
Esta pesquisa será de natureza aplicada e abordagem bibliográfica, pois
poderá ter uma aplicação prática na área da qualidade de software, visto
empresas desenvolvedoras de software que tenham interesse em melhorar
suas atividades na área de Gerência de Configuração podem utilizá-la e será
baseada em material bibliográfico impresso e eletrônico.
Organização
A organização dos capítulos ocorrerá da seguinte maneira, no Capítulo 1
será realizada uma abordagem geral sobre a Engenharia de Software,
relatando alguns conceitos básicos e seus principais paradigmas de
desenvolvimento, além disso, também será abordada a importância da
qualidade no contexto de desenvolvimento de software.
No Capítulo 2 a qualidade de software será explanada nas suas duas
visões: qualidade do processo e qualidade do produto.
Já no capítulo 3 o tema Gerência de Configuração será dissecado em
seus aspectos teórico e prático. Será visto a conceituação de termos
importantes e os principais tópicos que fazem parte da Gerência de
Configuração,
a
saber:
Identificação
dos
itens
de
configuração,
Armazenamento, Controle de acesso, Controle de versão, Relato do status e
Auditoria da configuração.
Finalmente, o capítulo 4 abordará a construção do Guia de Gerência de
Configuração, explicando a finalidade de cada subprocesso, o motivo de sua
criação e como eles são subdividos.
16
1 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
1.1 A Engenharia de Software
Há diversas definições para software, mas, para o escopo desse
trabalho, é suficiente dizer que “Software é o nome dado ao conjunto de
produtos desenvolvidos durante o processo de desenvolvimento de software, o
que inclui não só o programa de computador propriamente dito, mas também
manuais, especificações, planos de teste, e etc”. (WIKIPEDIA, 2007)
O processo de concepção de um software fica a cargo da Engenharia de
Software (ES). Ela emergiu na década de 70 objetivando a produção de
software de alta qualidade a um baixo custo.
Para Costa, Quaresma e Sabattini (s.d., p. 2) a Engenharia de Software
tem por objetivo [...] a melhoria da qualidade de seu produto, com propostas de
modelo de desenvolvimento, métodos e técnicas para aplicação nas diversas
fases de desenvolvimento do software.
De acordo com Pressman (2002), a Engenharia de Software abrange um
conjunto de três elementos fundamentais – métodos, ferramentas e
procedimentos.
Os métodos especificam "como fazer" para se construir o
software, as ferramentas proporcionam apoio automatizado
ou semi-
automatizado aos métodos, e os procedimentos unem os métodos às suas
ferramentas.
O mesmo autor ressalta que de acordo com a natureza da aplicação, o
tamanho e complexidade do projeto, os métodos e as ferramentas a serem
usados, deve-se escolher o paradigma de engenharia de software mais
adequado.
Cada paradigma da Engenharia de Software possui suas próprias
subdivisões, ou fases. Conforme o paradigma adotado, tais subdivisões podem
17
ser em maior ou menor número, mais extensas ou mais curtas, se repetir
durante o processo ou não. O conjunto de todas as atividades praticadas
durante o desenvolvimento do software chama-se ciclo de vida do software.
Independente do paradigma de engenharia adotado, o processo de
desenvolvimento de software é composto por três fases genéricas que
Pressman (1995) as descreve da seguinte forma:
a) Definição - essa fase focaliza o o quê. Ela é composta por três
etapas específicas:
- análise do sistema: define o papel de cada elemento num sistema
de computador, inclusive o do próprio software;
- planejamento do projeto: nessa fase são efetuadas tarefas
correspondentes, por exemplo, à definição do escopo do software,
análise de riscos, alocação de recursos e estimativas de custos;
- análise de requisitos: nessa fase definem-se o domínio da
informação, os requisitos funcionais e não-funcionais, além das
restrições funcionais e de projeto.
b) Desenvolvimento - essa fase focaliza o como. Ela é composta por
três passos específicos:
- projeto de software: traduz os requisitos do software num conjunto
de representações que descrevem a estrutura de dados, a
arquitetura, o procedimento algoritmo e as características de
interface;
- codificação: fase de conversão das representações do projeto
numa linguagem de programação;
- realização de testes: nessa etapa o software é testado para que se
possa descobrir o maior número de defeitos, desde a especificação
até implementação.
c) Manutenção - concentra-se nas mudanças que possam ocorrer, seja
por erros descobertos, adaptações ou ampliações no software.
18
Nessa fase aplicam-se novamente os passos das fases de definição
e planejamento, mas em um software já existente.
Três tipos de mudanças podem ocorrer durante essa fase: (1)
correção – ocorre quando algum tipo de defeito encontrado, (2)
adaptação – ocorre quando é necessário adequar o software às
mudanças que ocorreram em seu ambiente e (3) melhoramento
funcional – ocorre quando se quer acrescentar exigências funcionais
que não foram definidas originalmente.
1.2 Paradigmas do ciclo de vida
Os paradigmas do ciclo de vida, também chamados de modelos de ciclo
de vida do software, descrevem as etapas principais da produção e
manutenção do software.
A seguir veremos os modelos típicos de
desenvolvimento:
1.2.1 Modelo codifica-remenda
Esse é um ciclo de vida caótico, aqui temos o que Pádua (2003) chama
de ciclo de vida “codifica-remenda”, nessa abordagem parte-se de uma fraca
especificação, quando existente. Os desenvolvedores começam imediatamente
a codificar, remendando à medida que os erros vão sendo descobertos. Não é
preciso nenhuma sofisticação gerencial ou técnica e nenhum processo definido
é seguido. Projetos que seguem esse modelo, são projetos de alto risco e que
não permitem uma boa gestão.
19
Figura1: Modelo do ciclo de vida codifica-remenda. Fonte: Páuda, 12.
1.2.2 Modelo cascata ou clássico
Segundo Pressman (1995) o modelo cascata é uma abordagem
sistemática, onde o desenvolvimento do software se dá de forma seqüencial,
que se inicia no nível do sistema e avança ao longo da análise, projeto,
codificação, teste e manutenção. Essas etapas são descritas abaixo:
a) Análise e Engenharia de Sistemas: esta etapa esta relacionada à
coleta dos requisitos do sistema em relação ao ambiente que ele
está inserido e em relação aos outros elementos com o qual ele
precisa se comunicar;
b) Análise de requisitos de software: é a fase de levantamento dos
requisitos funcionais e não-funcionais, ou seja, define-se que o
software precisa fazer e como;
c) Projeto: é um processo de múltiplos passos que se concentra em
quatro atributos distintos: estrutura de dados, arquitetura de
software, detalhes procedimentais e caracterização da interface;
20
d) Codificação: é a etapa onde se traduz o que está especificado no
projeto para uma linguagem de programação;
e) Teste: essa etapa esta voltada para descobrir o maior número de
erros possíveis, tanto nos aspectos lógicos internos do software,
como nos aspectos funcionais externos, antes que o software entre
em operação;
f) Manutenção: nessa fase aplica-se novamente as etapas anteriores
a um software que precise de manutenção preventiva ou corretiva.
Este modelo não é tão utilizado como anteriormente por diversos
motivos, entre eles podemos citar o fato do levantamento de requisitos ocorrer
somente na fase inicial do projeto e a atividade de teste somente ao final de
todo processo, além de ser muito raro um projeto seguir um fluxo seqüencial
proposto pelo referido modelo.
Veja a seguir uma ilustração desse modelo:
Engenharia
de sistemas
Análise de
Requisitos
Projeto
Codificação
Teste
Manutenção
Figura 2: Modelo do ciclo de vida cascata. Fonte: Pressman, 33.
21
1.2.3 Prototipação
De
acordo
com
Pressman
(1995),
a
prototipação
permite
ao
desenvolvedor criar um modelo do software que será implementado. Esse
modelo poderá ser: (1) um protótipo em papel; (2) um protótipo que implementa
algum subconjunto da função exigida; (3) um programa que executa parte ou
toda a função desejada.
A prototipação é iniciada com a coleta dos requisitos. Desenvolvedor e
cliente definem os objetivos globais para o software.
Com base nesses
requisitos um projeto rápido é elaborado levando-se em consideração os
aspectos do software que serão visíveis ao usuário, ou seja, as entradas e
saídas. A partir daí, efetua-se a construção do protótipo que será avaliado pelo
cliente e usado para refinar os requisitos.
O objetivo inicial do protótipo é identificar requisitos de software e,
idealmente, o mesmo deve ser descartado, ao menos em parte, logo após ter o
seu objetivo concluído. A partir daí, o software real deverá ser projetado,
levando-se em conta a qualidade e manutenibilidade.
Alguns pontos problemáticos quanto a esse paradigma podem ser
levantados: O primeiro, refere-se ao entusiasmo que o usuário pode ter, pois
ao ver as interfaces do sistema, tende a achar que o mesmo estará a sua
disposição rapidamente e não concebe o fato que esse protótipo será
descartado. O segundo, refere-se à pressão com relação à urgência da
implantação, sugerindo-se que o protótipo seja, ao invés de descartado,
evoluído e entre rapidamente em funcionamento.
A figura a seguir ilustra a seqüência de eventos para o paradigma da
prototipação:
22
Figura 3: Modelo do ciclo de vida de Prototipagem evolutiva. Fonte: Páuda, 14.
1.2.4 Modelo espiral
Pressman (1995) explica que o modelo espiral reune as melhores
características dos dois modelos anteriores, acrescentando um novo elemento:
a análise de risco. A dimensão radial desse modelo representa bem a espiral
percorrida ao longo das atividades de desenvolvimento. Pois as atividades
iniciais encontram-se no centro da espiral, e na medida em que o
desenvolvimento do software avança, percorre-se a espiral do centro pra fora.
A figura a seguir ilustra os quadrantes que representam as quatro atividades
importantes desse ciclo, são elas:
a) Planejamento: determinação dos objetivos, alternativas e restrições;
b) Análise dos riscos: análise de alternativas e identificação/resolução
dos riscos;
c) Engenharia: desenvolvimento do produto no “nível seguinte”;
d) Avaliação feita pelo cliente: avaliação dos resultados da engenharia.
A cada iteração versões mais completas do software vão sendo
construídas, durante o primeiro giro ao redor da espiral, os objetivos,
23
alternativas e restrições são definidos e os riscos são identificados e
analisados. O cliente avalia o trabalho da engenharia e apresenta sugestões
para modificações. Com base na entrada do cliente, avança-se para a fase de
planejamento e análise de risco. Em cada arco da espiral, a conclusão da
análise de risco resulta numa decisão de prosseguir ou não com o projeto.
Atualmente, esse ciclo de vida é o que possui uma abordagem mais
realista, pois sua estrutura iterativa corresponde melhor ao que vivemos no
mundo real. Além disso, ele capacita o desenvolvedor, bem como o cliente, a
entender e reagir aos riscos em cada etapa evolutiva. Contudo, ele exige uma
considerável experiência na avaliação de riscos e dependendo dessa
experiência o projeto pode resultar em sucesso ou fracasso.
Figura 4: Modelo do ciclo de vida espiral. Fonte: Pádua, 14.
24
1.3 A qualidade no processo de desenvolvimento do software
Apesar dos vários paradigmas de ciclo de vida e da diversidade de
métodos, técnicas e ferramentas disponíveis para subsidiar o desenvolvimento
de software, grande parte dos usuários não esta satisfeita com seus produtos.
Além dos problemas decorrentes de falhas, desempenho inadequado ou nãoconformidades, existem aqueles relacionados ao custo e ao prazo de entrega
dos produtos, entre outros.
Os benefícios que os sistemas informatizados trouxeram, para as mais
diversas áreas, são inegáveis. Avanços na medicina com microcirurgias e na
educação, com a educação multimídia e a distância, são alguns exemplos.
Contudo, os usuários ainda querem mais. O patamar de exigências está cada
vez mais alto e a necessidade de melhorar os softwares é crescente.
Diante desse contexto, e segundo Curtis (2000) apud Rocha,
Maldonado, Weber (2001), as empresas desenvolvedoras de software estão
buscando adequar-se através do investimento em qualidade de software. A
qualidade de software é, portanto, não apenas algo desejável, mas uma
necessidade de mercado. Desse modo, organizações que sejam capazes de
integrar, harmonizar e acelerar seus processos de desenvolvimento e
manutenção de software têm a primazia do mercado.
(JOMORI; DELLA VOLPE; ZABEU, 2007, s.n) relatam que:
Muitas organizações têm investido na busca de melhorias, não
somente para diminuir os problemas decorrentes da baixa qualidade
de seus processos de desenvolvimento e do produto final, mas
também para alcançar melhores resultados financeiros com o
aumento de produtividade e conseqüente diminuição de prazo de
entrega e maior satisfação de seus clientes.
Machado e Sousa (2007) afirmam que para se chegar aos objetivos
esperados, no que se refere à qualidade do software, é fundamental que a
preocupação com a qualidade seja constante e presente desde o início do ciclo
de desenvolvimento do software. Práticas de garantia e controle da qualidade
25
garantem que os artefatos de software sejam desenvolvidos e entregues aos
clientes com melhor aceitabilidade, menos defeitos e menores custos.
Segundo Pressman (2002), quanto mais os cedo defeitos – que podem
ser desde uma especificação de requisito inadequada até um erro na linha de
código – forem descobertos, menos tempo e recursos serão necessários para
removê-los.
Mas qualidade não surge do acaso. As empresas desenvolvedoras de
software necessitam de investimento tanto na qualidade do processo de
desenvolvimento como na qualidade do produto. Uma vez que investir só em
processo não garante que o produto de software seja de boa qualidade. Por
isso, as organizações que pretendem aperfeiçoar sua qualidade de modo
contínuo, se interessam cada vez mais, em seguir padrões, normas e modelos
de referência de qualidade.
26
2 QUALIDADE DE SOFTWARE
2.1 Visão geral
Definir qualidade não é uma tarefa fácil, visto que tal conceito varia de
acordo com a visão e as necessidades de cada um. De acordo com a norma
NBR ISO 8402 (1994) apud Machado e Sousa (2007), qualidade é a totalidade
das características de uma entidade, que lhe confere a capacidade de
satisfazer necessidades explícitas e implícitas.
Na área de software, tais necessidades podem ser traduzidas na forma
de requisitos. “A especificação de requisitos de um produto implica, também, a
determinação de requisitos não-funcionais, entre os quais se incluem os
requisitos de qualidade” (ROCHA; MALDONADO; WEBER, 2001).
Ainda segundo os mesmos autores, definir requisitos de qualidade
significa identificar os atributos relevantes para um produto específico. Tornase, portanto, necessário identificar quais são as características de qualidade
necessárias para um determinado produto de software e definir em que grau
essas característica precisam ser alcançadas para satisfazer as necessidades
dos usuários.
A crescente demanda por softwares de qualidade, tem feito com que a
indústria de software invista cada vez mais na qualidade de seus processos e
produtos. A adoção de normas e modelos de referência se insere nesse
esforço.
Tsukumo, et al. (1997) relatam que com a melhoria da qualidade do
processo é possível melhorar o produto, no entanto, as duas abordagens
(produto e processo) são necessárias e complementares uma vez que
melhorar o processo não garante, necessariamente, a melhoria do produto já
27
que sempre há fatores imponderáveis e imprevisíveis que escapam ao controle
do processo de produção e que podem afetar seu resultado final.
2.2 Qualidade do Processo
Nogueira e Capra (2003) explicam que quando colocamos o foco no
processo de desenvolvimento, garantimos, a partir de então, a qualidade desde
o início da construção do software, uma vez que controlamos a sua fabricação
passo a passo e medimos a sua qualidade antes dele sair da fábrica.
Para buscar a melhoria dos processos de desenvolvimento, as
empresas desenvolvedoras de software estão investindo em normas e modelos
de capacitação, seja pela adequação ou certificação.
(KOSCIANSKI, SOARES, 2007, p.49) relatam que:
A adequação a uma norma consiste em colocar em prática, total ou
parcialmente, aquilo que nela é proposto. Isso pode ser feito pela
empresa de maneira autônoma, ou com auxílio de uma consultoria,
por exemplo. Já a certificação envolve a participação de um
organismos ou empresa externa, devidamente regulamentado ou
credenciado, que possa atestar que a empresa candidata segue
corretamente um dado padrão.
De acordo com Pádua (2003), um modelo de capacitação serve de
referência para avaliar a maturidade dos processos de uma organização. Esta
pode ser avaliada comparando-se suas práticas reais com aquelas que o
modelo de capacitação descreve ou recomenda. Essa aferição produz um
diagnóstico da organização quanto aos seus processos. O diagnóstico serve de
base para recomendações de melhoria de processos, e essas recomendações
podem ser consolidadas em um plano de melhoria.
“A maturidade de uma organização em Engenharia de Software mede o
grau de competência, técnica e gerencial, que essa organização possui para
28
produzir software de boa qualidade, dentro de prazos e custos razoáveis e
previsíveis” (PÁDUA, 2003, p.53).
Este autor descreve, ainda, alguns sintomas que demonstram a
imaturidade das organizações, a saber: (1) os projetos não são definidos com
clareza, (2) as pessoas não recebem o treinamento necessário, (3) as
ferramentas não ajudam realmente a resolver os problemas, (4) os
procedimentos e padrões, quando existem, são definidos e seguidos de forma
burocrática.
A partir daí, podemos listar alguns exemplos de prejuízos que essa
imaturidade causa: (1) os mesmos problemas se repetem de projeto em
projeto, (2) o trabalho é excessivo e desgastante, onde corridas desesperadas
contra os prazos são a regra, (3) a qualidade de vida no trabalho é ruim, (4) os
profissionais são desmotivados e (5) os orçamentos e cronogramas estouram
rotineiramente.
A fim de evitar os problemas supracitados, entre outros, as empresas
têm buscado implantar modelos de capacidade como o CMMI e o MPS.BR.
2.2.1 CMMI – Modelo de Integração de Maturidade da Capacidade
O modelo de Integração de Maturidade da Capacidade (CMMI Capability Maturity Model Integration) é uma evolução do CMM - Capability
Maturity Model, a versão 1.1, foi publicada em 2002. Esse modelo possui
duas representações: “por estágio” ou níveis e “contínua” ou por disciplinas.
Jomori, Della Volpe e Zabeu (2007) descrevem algumas características
da representação contínua: (1) permite melhorar o desempenho em um
processo único, (2) permite melhorar o desempenho em várias áreas alinhadas
aos objetivos de negócio e (3) é apropriado para quem sabe que processo
deve ser melhorado. Na representação por estágios, eles destacam as
29
seguintes características: (1) possui um enfoque de melhoria do processo de
forma sistêmica e estruturada, (2) atingir cada um dos estágios garante a base
fundamentada necessária para o próximo estágio, (3) permite a organização ter
um caminho evolutivo pré-defindo pela melhoria.
A ilustração a seguir representa os níveis/estágios de maturidade de
processo no CMMI:
Figura 5: Níveis de maturidade do CMMI. Fonte: Molinari, 50.
A seguir temos uma tabela representando os níveis de maturidade e
suas respectivas áreas de processo na abordagem por estágios:
30
Gerência de requisitos
Planejamento do projeto
Nível de maturidade
2
Gerência e controle do projeto
Gerência de acordos com fornecedores
Medição e análise
Garantia da qualidade do processo e do produto
Gerência de configuração
Desenvolvimento de requisitos
Solução técnica
Integração de produto
Verificação
Validação
Nível de maturidade
3
Foco no processo organizacional
Treinamento organizacional
Gerência de projeto integrada
Gerência de riscos
Análise de decisão e resolução
Desempenho do processo organizacional
Definição do processo organizacional
Nível de maturidade
Desempenho do processo organizacional
4
Gerência quantitativa do projeto
Nível de maturidade
5
Inovação e implantação na organização
Análise e resolução de causas
Quadro 1: Áreas de processo - CMMI por estágios. Fonte: Kosianski, 108.
31
O quadro abaixo apresenta as áreas de processo na representação
contínua:
Foco no processo
Definição de processos
Gerência de processos
Treinamento
Desempenho de processo
Inovação e implantação
Planejamento de projeto
Controle e monitoramento de projeto
Gerência de acordos com fornecedores
Gerência de projeto
Gerência de projeto integrada
Gerência de riscos
Integração de equipe
Integração de fornecedores
Gerência quantitativa de projeto
Gerência de requisitos
Gerência de desenvolvimento
Engenharia
Solução técnica
Integração do produto
Verificação
Validação
Gerência de configuração
Garantia de qualidade de produto e processo
Suporte
Medida e análise
Análise e decisão e resolução
Ambiente organizacional para integração
Resolução e análise de causas
Quadro 2: Áreas de processo CMMI na representação contínua. Fonte: Kosicianski,
110.
32
Devido ao escopo desse trabalho vamos detalhar apenas o processo de
Gerência de Configuração. Para maiores informações sobre cada nível e suas
respectivas áreas: www.sei.cmu.edu/cmmi.
O (SEI, 2006, p. 499) descreve o objetivo da GCS no CMMI versão 1.1
como:
O propósito da Gestão de Configuração de software (GCS) é
estabelecer e manter a integridade dos produtos de trabalho, usando
identificação da configuração, controle de configuração, status da
configuração contábil e auditoria de configuração (SEI, 2006).
As metas específicas de Gerência de Configuração definidas no CMMI ,
segundo Molinari (2007) e as propostas para cada uma delas são:
a) Estabelecer baselines, que são utilizadas para o trabalho nos produtos
bem como sua manutenção;

Identificar itens de configuração.

Estabelecer sistemas de gestão de configuração.

Criar ou liberar baselines.
b) Rastreamento e controle de mudanças, para permitir a rastreabilidade e
controle das mudanças dos produtos;

Rastrear mudanças.

Controlar as mudanças.
c) Estabelecer integridade, para permitir que a integridade das baselines
seja estabelecida e manutenida.

Estabelecer registros da Gerência de Configuração.

Executar auditorias de configuração.
Molinari (2007) descreve, em linha gerais, como a GC é vista em cada
nível:
33
Nível 1: a GC é implantada como um membro que deve ser evoluído.
Nível 2: a GC em um processo gerenciado, que significa planejar, executar, monitar e
controlar o tipo de processo.
Nível 3: a GC é processo definido, ou seja, é processo ajustado e próprio para a
organização, com a devida documentação atualizada e revisada.
Nível 4: a GC é processo quantitativamente gerenciado, de modo que se passa a usar
o controle estatístico de processo dentro da organização e dos projetos.
Nível 5: a GC é um processo otimizado, pois as causas e problemas de processo são
entendidos e corrigidos de forma pró-ativa. Foca-se na constante otimização do
processo.
Quadro 3: A visão sobre a GC em cada nível do CMMI. Fonte: Molinari, 62.
2.2.2 MPS.BR – Melhoria de Processo do software Brasileiro
Koscianski e Soares (2007) esclarecem que o MPS.BR é um programa
para Melhoria de Processo do Software Brasileiro que teve seu início no final
de 2003 e é coordenado pela Associação para Promoção da Excelência do
Software Brasileiro (SOFTEX). Tal programa conta com o apoio do Ministério
da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos
(FINEP) e do Banco Interamericano de Desenvolvimento (BID).
De acordo com os mesmos autores, o MPS.BR está dividido em três
componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MAMPS) e Modelo de Negócio (MN-MPS). A sua construção é baseada nas
normas NBR ISO/IEC 1210, ISO/IEC 15504 e no CMMI. A construção do
modelo é um esforço conjunto do SOFTEX, do Governo e Universidades, para
aplicação em empresas brasileiras.
34
A figura a seguir indica a base para construção desse modelo:
Figura 6: Base de construção do MPS.BR. Fonte: Koscianski,143.
Segundo os autores do modelo, os sete níveis do MPS-BR devem
permitir uma implantação mais gradual do que o CMMI, facilitando a tarefa em
empresas de pequeno porte.
Os níveis de maturidade estabelecem patamares de evolução de
processos, caracterizando estágios de melhoria de implementação de
processos na organização. O MR.MPS define sete níveis de maturidade: A (Em
Otimização), B (Gerenciado Quantitativamente), C (Parcialmente Gerenciado),
D (Largamente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A
escala de maturidade se inicia no nível G e progride até o nível A. Para cada
um destes sete níveis de maturidade foi atribuído um perfil de processos e de
capacidade de processos que indicam onde a organização tem que colocar
esforço para melhoria de forma a atender os objetivos de negócio. Para
maiores informações sobre cada nível e processos correlatos: www.
softex.br/mpsbr.
O quadro abaixo representa os níveis de maturidade e os processos do
MPS-BR:
35
A
Inovação e implantação na organização
Análise de causas e resolução
B
Desempenho do processo organizacional
Gerência quantitativa do projeto
C
Análise de decisão e resolução
Gerência de riscos
D
Desenvolvimento de requisitos
Solução técnica
Integração de produto
Instalação de produto
Liberação de produto
Verificação
Validação
E
Treinamento
Avaliação
e
melhoria
do
processo
organizacional
Definição do processo organizacional
Adaptação do processo para gerência de
projeto
F
Medição
Gerência de configuração
Aquisição
Garantia da qualidade
G
Gerência de requisitos
Gerência de projetos
Quadro 5: Níveis de maturidade e processos do MPS.BR. Fonte: Koscianski,
Soares,146
O modelo MPS-BR possui uma série de características que o tornam
mais adequado à realidade das empresas brasileiras, tais características são
listadas no quadro a seguir:
36
Pontos fortes do MPS.BR
Possui sete níveis de maturidade, o que possibilita uma implantação
mais gradual e adequada a pequenas empresas;
Compatibilidade plena com o CMMI e com a norma ISO/IEC 15504;
Criado no Brasil, onde a maioria das empresas que desenvolvem
software são micro, pequenas e médias;
Custo acessível;
Avaliação bienal das empresas;
Forte interação Universidade-Empresa.
Quadro 5: Pontos positivos do MPS-BR. Vasconcelos,35.
De acordo com o que a (SOFTEX, 2006, p.28) descreve no MPS.BR, “O
propósito do processo de Gerência de Configuração é estabelecer e manter a
integridade de todos os produtos de trabalho de um processo ou projeto e
disponibilizá-los a todos os envolvidos”.
A Gerência de Configuração é definida no MPS.BR como um processo
de apoio ao desenvolvimento e está inserido no nível F. As atividades a serem
desenvolvidas no processo de GC são descritas por Molinari (2007) da
seguinte forma:
a) Os itens de configuração são identificados.
b) Os itens de configuração gerados pelo projeto são definidos e
colocados sob uma linha base.
c) É estabelecido e mantido um Sistema de Gerência de Configuração.
d) As modificações e liberações dos itens de configuração são
controladas.
e) As modificações e liberações são disponibilizadas para todos os
envolvidos.
f) A situação dos itens de configuração e as solicitações de mudanças
são registradas, relatadas e o seu impacto é analisado.
37
g) A completeza e a consistência dos itens de configuração são
asseguradas.
h) O armazenamento, manuseio e entrega dos produtos de trabalho são
controlados.
i) A integridade das linhas-base (baselines) é estabelecida e mantida
através de auditoria da configuração e de registros da Gerência de
Configuração.
O quadro a seguir representa uma visão de processo, onde a Gerência
de Configuração está colocada como um processo de apoio:
Figura 7: Modelo de processos do MPS-BR. Fonte Molinari, 80.
38
2.3 Qualidade do Produto
A qualidade de um produto de software é resultante das atividades
realizadas no processo de desenvolvimento do mesmo. Avaliar a
qualidade de um produto de software é verificar, através de técnicas e
atividades operacionais o quanto os requisitos são atendidos. Tais
requisitos, de uma maneira geral, são a expressão das necessidades,
explicitados em termos quantitativos ou qualitativos, e têm por
objetivo definir as características de um software, a fim de permitir o
exame de seu atendimento. (TSUKUMO, ET AL.,1997, p.10 )
Existem várias normas que versam sobre a qualidade dos produtos de
software, por exemplo :

ISO/IEC
14598-5
fornece
requisitos
e
recomendações
para
implementação prática da avaliação de produto de software.

ISO/IEC 9126 lista o conjunto de características que devem ser
verificadas em um software para que ele seja considerado um
"software de qualidade".

Norma ISO/IEC 12119 é aplicável a pacotes de software,
estabelecendo requisitos e instruções a respeito de como testar um
pacote de software em relação aos requisitos estabelecidos.
Dentre essas, veremos com mais detalhes a norma ISO/IEC 9126. Tal
norma está dividida em três partes. A primeira (9126-1) inclui definições e
características. As duas seguintes descrevem métricas externas (9126-2) e
internas (9126-3).
O presente trabalho descreverá apenas a parte ISO/IEC 9126-1, ela
refere-se ao modelo de qualidade e apresenta um conjunto de características
de qualidade aplicável a qualquer produto de software. Cada uma das
características pode ser detalhada em vários níveis de subcaracterísticas,
chegando-se a um amplo conjunto de atributos que descrevem a qualidade de
um produto de software.
39
O modelo de qualidade divide-se em qualidade interna, externa e
qualidade de uso. De acordo com Bianchi (2007), elas podem ser descritas da
seguinte maneira:
a) Qualidade interna – refere-se às características do produto segundo
uma visão interna, elas servem para definir estratégias de
desenvolvimento e critérios de avaliação e verificação; completar
b) Qualidade externa - refere-se a características do produto segundo
uma visão externa, tais características são percebidas quando o
software é executado;
c) Qualidade de uso – refere-se à visão do usuário quando o produto
está em uso num ambiente específico.
Esse quadro refere-se às subcaracterísticas de qualidade interna e externa.
Características
Subcaracterísticas
Pergunta chave para a
subcaracterística
Adequação
Acurácia
Propõe-se a fazer o que é
apropriado?
Faz o que foi proposto de forma
correta?
Funcionalidade
(satisfaz as necessidades
para a finalidade a que se
Interoperabilidade
Interage com os sistemas
especificados?
destina?)
Conformidade
Confiabilidade
(matém o desempenho ao
Está de acordo com as normas,
leis, etc.?
Segurança de
Evita acesso não autorizado aos
acesso
dados?
Maturidade
Com que freqüência apresenta
falhas?
40
longo do tempo e nas
condições estabelecidas?)
Usabilidade
(é fácil de usar?)
Tolerância a falhas
É capaz de recuperar dados em
recuperação
caso de falha?
Facilidade de
É fácil entender os conceitos
compreensão
utilizados?
Facilidade de
aprendizagem
Em relação ao tempo
(realiza as tarefas no tempo
adequado à complexidade
de cada uma delas?)
Qual é o tempo de resposta e de
processamento?
recursos
quanto tempo?
modificação
(é fácil de modificar?)
Estabilidade
Testabilidade
É fácil de encontrar um erro,
quando ocorre?
É fácil modificar e remover erros?
Há grande risco quando se faz
alterações?
É fácil testar quando se faz
alterações?
É fácil adaptar a outras
Portabilidade
outro ambiente?)
É fácil de operar e controlar?
Quanto recurso usa? Durante
Facilidade de
(é fácil transferir para
É fácil aprender a usar?
Em relação aos
Facilidade de análise
Manutenibilidade
reage?
Facilidade de
Operacionalidade
Eficiência
Ocorrendo falhas, como ele
Adaptabilidade
plataformas sem aplicar outras
ações além dos fornecidos para
esta finalidade?
41
Facilidade de
É fácil instalar em outras
instalação
plataformas?
Está de acordo com padrões de
Conformidade
portabilidade?
Facilidade de
É fácil substituir por outro
substituição
software?
Quadro 6: Subcaracterísticas da qualidade interna e externa. Fonte: Adapatação de
Biacnhi, 2006
O quadro a seguir refere-se às características de qualidade de uso.
Características
Eficácia
Pergunta-chave
Permite atingir os objetivos estabelecidos em certas condições de
funcionamento?
Produtividade
Capacidade de utilizar um determinado número de recursos em
relação aos objetivos pretendidos em certas condições de
Segurança
funcionamento.
Capacidade de obter níveis de risco, aceitáveis em certas
condições de funcionamento.
Satisfação
Satisfaz aos requisitos do usuário?
Quadro 7: Características da qualidade de uso. Fonte: Biacnhi, 2006
42
3 GERÊNCIA DE CONFIGURAÇÃO
3.1 Abordagem Teórica
Essa seção conterá a parte contextual da Gerência de Configuração,
abordando sua definição e conceituando termos importantes.
3.1.1 Visão Geral
À medida que a complexidade dos projetos aumentou e as equipes de
trabalho se tornaram maiores, muitas vezes distribuídas geograficamente, ter
um processo de desenvolvimento definido e gerenciado tornou-se uma
necessidade.
Para Molinari (2007), no que diz respeito à Gerência de Configuração de
Software ter algo organizado e gerenciado refere-se a guardar um histórico real
do que foi desenvolvido e modificado, inclusive tratando as seguintes questões:
por que foi modificado, quando, como, quem modificou, qual o impacto da
mudança e qual a produtividade associada.
A Gerência de Configuração ou Gestão de Configuração, segundo
Pressman (2002), é um conjunto de atividades de apoio ao desenvolvimento do
software que é aplicada ao longo de todo o processo de software. Essas
atividades são desenvolvidas para (1) identificar as modificações, (2) controlar
modificações, (3) garantir que as modificações sejam adequadamente
implementadas e (4) relatar as modificações a outros que possam ter interesse.
Essas atividades começam quando o projeto de engenharia de software se
inicia e só termina quando o software é retirado de operação.
Uma definição formal para a Gerência de Configuração (GC) seria:
43
“uma disciplina que aplica procedimentos técnicos e administrativos
para identificar e documentar as características físicas e funcionais de
um Item de Configuração (IC), controlar as alterações nessas
características, armazenar e relatar o processamento das
modificações e o estágio da implementação e verificar a
compatibilidade com os requisitos especificados” (IEEE apud Murta,
2006, p.8).
Conforme a visão de Molinari (2007), a GC trata da gestão do ciclo de
vida de desenvolvimento do software, incluindo seu histórico de alterações. Ela
pode ser usada por todos os envolvidos no processo de desenvolvimento de
um software, desde o desenvolvedor, utilizando-a para gerenciar as versões de
seu novo programa, até os gestores da empresa, fazendo uso da GC para
saber o impacto das mudanças e seus custos associados. Para tal, ela deve
dar suporte a diversas atividades, tais como: identificação dos componentes,
gerenciamento da configuração do software, controle de versão e controle das
mudanças.
Segundo o mesmo autor, a GC passou, ao longo dos anos, por quatro
fases que caracterizam a sua evolução. De 1970 a 1980, a GCS era baseada
em arquivos, sendo voltada para o controle e versionamento de arquivos pura e
simplesmente. De 1998 a 1990, era baseada em repositório, as informações de
cada arquivo versionado (metadados) passam a ser armazenados em banco
de dados e a gestão de mudanças começa a ser iniciada. De 1990 a 2000, a
GC era baseada em transparência, onde os dados gerenciados passam a ser
armazenados em repositórios centrais, e há uma preocupação com a
segurança de acesso e com a rastreabilidade desses dados. Do início de 2000
até hoje, a GCS é baseada em processos e produtividade, essa fase é
caracterizada pela preocupação com a produtividade e com o impacto da
mudança.
44
3.1.2 Conceitos Iniciais
a) Metadados: Molinari (2007) explica que são informações relativas
aos itens de configuração, tais como: data de entrada em produção,
data de criação, quem criou e, principalmente, o seu relacionamento
com os outros itens, o que proporciona a rastreabilidade entre eles.
Os metadados dos itens colocados sob controle são compartilhados
por todas as áreas de atividades de GC. Sendo usados, entre outras,
para pesquisas direto na base de dados e para determinar se um
item de configuração está fora dos padrões;
b) Item de Configuração: Pressman (1995) o descreve como sendo
cada um dos elementos de informação que são criados durante o
desenvolvimento de um produto de software, ou que para este
desenvolvimento sejam necessários, que são identificados de
maneira única e cuja evolução é passível de rastreamento;
c) Configuração de Software: é o conjunto de itens de configuração de
um determinado software;
d) Baseline (ou linhas de referência): para Rocha, Maldonado, Weber,
(2001) é um conjunto de um ou mais itens de configuração
identificados, analisados, corrigidos, aprovados e armazenados em
um local sob controle de acesso. Segundo Pádua (2003), tais itens
só podem ser modificados se forem satisfeitas uma série de etapas
de formalização, análise, aprovação e registro de acordo com o
padrão de GC da empresa;
e) Plano de configuração: documento que consta as atividades
relacionadas à implantação e administração do processo de
Gerência de Configuração. Deve conter, também, a descrição de
como e quando as atividades serão efetuadas e quem serão os
responsáveis por elas, bem como os recursos necessários. Tal plano
varia de acordo com as necessidades de cada empresa e, se for
45
necessário, pode-se fazer um estudo dos padrões internacionais de
planos de Gerência de Configuração para escolher o mais adequado
(Rocha, Maldonado, Weber, 2001);
f) Repositório (ou biblioteca): local onde os itens de configuração são
armazenados e só podem ser acessados de acordo com a política de
acesso da Gerência de Configuração (Molinari, 2007). Pelo fato de
manipular uma grande quantidade de informações, a gestão da
biblioteca só é viável com o suporte de uma ferramenta. (Páuda,
2003);
g) Papéis (ou roles): indicam as atribuições de cada um dentro do
desenvolvimento do software em relação à GC. “A GC requer o
funcionamento colaborativo de vários papéis da organização. Os
papéis que se destacam são: (1) o grupo de GC que centraliza o
funcionamento dos mecanismos dessa disciplina, por exemplo,
desenvolve, mantém e divulga os procedimentos de GC e uso das
respectivas ferramentas; (2) o grupo de controle de configuração de
software que toma as decisões importantes relativas à GC no nível
de projeto, por exemplo, autorizar a identificação dos itens de
configuração e a criação de baselines, bem como, avaliar o impacto
das alterações; (3) os gerentes de projeto são responsáveis por
cobrar dos desenvolvedores a aplicação da GC no dia-a-dia do
projeto” (Pádua, 2003, 287)
h) Check-in/check-out: de acordo com Rocha, Maldonado, Weber
(2001), esses métodos de conferência na entrada e na saída são
aplicados para a inclusão e extração dos itens de configuração no
repositório, respectivamente. Quando é preciso fazer uma alteração
em um item de configuração uma cópia dele é colocada na área de
trabalho do desenvolvedor (check-out). Ao término das suas
modificações, esse item é revisado e recolocado no repositório
(check-in).
46
3.1.3 Definição do escopo e do grau de formalismo das tarefas de GCS
Molinari (2007) explica que o escopo diz respeito ao número e aos tipos
de objetos colocados sob controle da GC. A princípio, qualquer objeto de
software pode ser colocado sob controle da GC, porém quanto mais objetos
controlarmos mais alto será seu custo. Definir o escopo, portanto, é encontrar
o ponto de equilíbrio.
O grau de formalismo está relacionado ao nível de controle com o qual a
Gerência de Configuração é desempenhada. Quanto maior o risco, maior deve
ser o nível de controle.
Conforme vemos na figura abaixo, o grau de formalismo aumenta à
medida que as atividades vão sendo realizadas.
Figura 8: Evolução do grau de formalismo. Fonte: Molinari, 87.
47
3.2 Abordagem operacional
Nessa seção a parte prática da Gerência de Configuração será
abordada, discorrendo sobre seus aspectos fundamentais e as atividades que
devem compor esse processo.
3.2.1 Atividades de Gestão da Configuração
Diversas atividades são desenvolvidas no processo de Gerência de
Configuração. Identificação, armazenamento, controle de versão, controle de
mudança, relato de status e auditoria são algumas delas, cada uma será vista a
seguir:
3.2.1.1 Identificação
Nessa
atividade
determina-se
os
metadados
de
um
item
de
configuração. Normalmente, os itens que devem estar sob a Gerência de
Configuração são os mais usados no ciclo de vida, os mais genéricos, os mais
importantes para a segurança, os projetados para reutilização e os que podem
ser alterados simultaneamente. (Berlack, 1992 apud Rocha, Maldonado,
Weber, 2001)
De acordo com Molinari (2007), um aspecto importante dessa atividade
é garantir uma identificação única para cada item, para que a evolução de cada
uma das versões dos componentes e a hierarquia entre eles possam ser
reconhecidos por meio de seus nomes.
O mesmo autor ressalta que é preciso descrever como os itens de
configuração se relacionam, pois a identificação desses relacionamentos
permite uma rápida localização dos itens afetados em decorrência de alguma
alteração por meio da rastreabilidade.
48
Figura 10: Descrição de um item de configuração. Fonte: Molinari,107.
Segundo Molinari (2007) diversos artefatos produzidos ao longo do
desenvolvimento do projeto podem passar a ser itens de configuração
controlados pela Gerência de Configuração. Alguns desses artefatos são:
a) Objetos de Produto: podem ser software (inclui arquivos, códigosfonte, arquivos de cabeçalho), hardware (podem ser cabos,
maquinário em geral e periféricos), rede (interfaces de protocolo,
servidores específicos, switches), dados (seriam os dados iniciais ou
básicos do sistema) e ferramentas (processadores de banco de
dados são um exemplo);
b) Objetos de projeto: Cada etapa de desenvolvimento e suporte possui
seus respectivos produtos. Podemos ter, por exemplo, contratos,
plano
de
projeto,
cronogramas,
relatórios,
planos de
teste,
requisições de release, registro de eventos, etc;
c) Objetos Organizacionais: podem ser documentos administrativos,
tais como correspondências, (cartas, e-mails, fax), material de venda
do produto (protótipos, apresentações), bem como objetos de infraestrutura, como compiladores, computadores pessoais, sistemas
49
operacionais e os ligados à qualidade, por exemplo, descrições de
processo da empresa, templates e padrões.
3.2.1.2
Armazenamento
Segundo Molinari (2007), sua finalidade é garantir a consistência,
integridade e disponibilidade do item de configuração. Por se tratar de algo
físico, pode ser uma estrutura de diretório. Cada registro é guardado de forma
a identificar com quem esteve e se a cópia do item foi efetuada.
Ao conjunto de dados armazenados, damos o nome de biblioteca, ou
repositório. Em termos de desenvolvimento de software, Molinari (2007)
classifica as bibliotecas da seguinte maneira:
a) Biblioteca controlada: quando o armazenamento dos itens de
configuração é feito de forma organizada, de acordo com alguma
característica ou funcionalidade envolvida;
b) Biblioteca dinâmica: os itens de configuração são armazenados
nessa biblioteca enquanto estão sendo produzidos, por isso também
é conhecida como biblioteca de desenvolvimento.
3.1.2.3
Controle de versões
Diversas alterações em um item de configuração são efetuadas ao longo
do seu desenvolvimento, o que acarreta, conseqüentemente, a criação de
novas versões. De acordo com Molinari (2007), o controle de versões, ou
versionamento, permite a edição colaborativa e o compartilhamento dos dados,
além de rastrear e controlar os artefatos do projeto.
Segundo Rocha, Maldonado e Weber (2001), para efetuar o controle
dessas versões, estas devem ser devidamente armazenadas e identificadas. É
conveniente que tal esquema de identificação seja feito em forma de árvore,
50
pois além de permitir um histórico das versões, permite identificação única e
ramificações a partir de qualquer versão.
“Quando um item existe simultaneamente em duas ou mais formas
diferentes, que atendam a requisitos similares, temos variantes do item,
representadas por ramificações na árvore” (Rocha, Maldonado, Weber, 2001,
62).
“Quando temos várias pessoas trabalhando paralela e concorrentemente
nos mesmos arquivos pode surgir o problema de uma sobrescrever o trabalho
da outra. Para que isso seja evitado, é preciso um conjunto de políticas para
ordenar e integrar todas essas fontes de alterações” (MOLINARI, 2007, 170).
O mesmo autor explica que por uma questão de segurança, os
desenvolvedores costumam fazer uma cópia dos arquivos a serem alterados
ao invés de trabalhar diretamente nos arquivos do repositório.
Veremos a seguir como Molinari (2007) descreve os tipos de
sincronização (ou políticas de versionamento):
a) Trava-Modifica-Destrava
Nesse caso, o processo de versionamento permite que apenas uma
pessoa altera o arquivo de cada vez. Essa visão pode causar um processo de
serialização desnecessário, mas se o ambiente necessitar de um alto grau de
formalização, esse tipo de processo é o adequado. Essa abordagem é ilustrada
na figura a seguir:
51
Figura 12: Exemplo de política Trava-Modifica-Destrava. Fonte:Molinari, 172.
52
b) Copia-Modifica-Resolve
Nessa abordagem não há travamento de arquivos, cada desenvolvedor
trabalha de forma independente na sua cópia. Se mais de um deles tiver
trabalhado no mesmo arquivo, ao final, as alterações são mescladas formando
uma versão final única. Veja a ilustração na figura a seguir:
Figura 13: Exemplo de Política Copia-Modifica-Resolve. Fonte: Molinari, 173.
53
3.2.1.4
Controle de mudanças
Rocha, Maldonado e Weber (2001) reforçam que ao longo do
desenvolvimento
do
software
muitas
informações
são
produzidas
e
modificadas, para que as informações relevantes ao desenvolvimento não se
tornem inconsistentes, suas modificações devem ser acompanhadas e
controladas.
De acordo com Molinari (2007), inúmeros fatores são causadores de
mudanças, erro cometido por alguém, surgimento de novos requisitos ou
adequação ao novo ambiente no qual o produto está inserido são alguns
exemplos. Portanto, a mudança em uma aplicação é para corrigir algo,
adicionar novas funcionalidades ou otimizar as já existentes.
Molinari (2007) ressalta um aspecto fundamental da mudança: o
chamado “efeito dominó”, pois qualquer mudança, por menor que seja, sempre
causará algum impacto. Por isso é fundamental que todos os envolvidos sejam
informados.
Conforme Pádua (2003) explica, para que um item de configuração sofra
alguma alteração após está inserido numa baseline, é preciso passar por um
processo formal de solicitação de alteração, avaliação, aceitação, desenho,
implementação e testes. Caso tenha um resultado positivo nos testes, então a
solicitação será, enfim, disponibilizada.
“O controle de mudança é a combinação de procedimentos humanos e
ferramentas automatizadas” (Pressman, 1995, 930). O processo de controle de
mudança explicado a seguir, está descrito conforme o entendimento de Páuda
(2003) e complementado com a visão de Pressman (1995).
O primeiro passo para dar início a essa atividade é o envio de uma
solicitação de mudança. Tal solicitação vai para análise para determinar os
respectivos custos e benefícios. Nessa etapa, é produzido um relatório de
avaliação de solicitação de mudança no qual constam os seguintes itens:
a) Especificação dos requisitos da mudança;
54
b) Identificação dos itens possivelmente afetados;
c) Possível impacto da modificação sobre o produto;
d) Possíveis soluções alternativas;
e) Possíveis impactos sobre outros produtos;
f) Identificação dos problemas de segurança;
g) Possíveis fatores humanos envolvidos;
h) Custos da modificação;
i) Benefícios da modificação;
j) Riscos da modificação;
k) Plano de desenho e implementação;
l) Estratégias de testes.
De acordo com as conclusões desse relatório, define-se por aceitar ou
rejeitar a solicitação de alteração. Caso seja escolhida a primeira opção, um
aviso de aceitação de alteração é emitido, e uma solicitação de liberação dos
itens afetados da baseline é feita ao grupo de GC.
Caso a solicitação de liberação dos itens da baseline seja aceita, de
acordo com as prioridades, passa-se à fase seguinte, de desenho, onde são
identificados os itens que serão efetivamente modificados, bem como a
definição dos testes a serem aplicados, para evitar efeitos colaterais negativos
com relação às alterações. O resultado do desenho é uma proposta de
alteração. Tal proposta deve constar:
a) Lista dos itens que deverão ser efetivamente alterados;
b) Desenho das alterações;
c) Testes que deverão ser realizados;
d) Plano detalhado de implementação das alterações.
Depois disso, vem a fase de implementação. Nesta, as alterações dos
itens são efetivamente realizadas, e para isso é preciso fazer o check-out dos
55
itens necessários. Nessa fase também são efetuados os testes de unidade e,
quando preciso, as atualizações dos modelos e documentos.
A próxima etapa é a de testes, onde são realizados teste de integração,
de regressão, além de revisões e inspeções. Ao final, os respectivos relatórios
são enviados ao grupo da garantia da qualidade, o qual realiza a auditoria nos
itens modificados. Estando de acordo, os referidos itens são enviados ao grupo
de GC juntamente com um relatório de formalização de alteração. O grupo de
GC, verifica a conformidade com as regras de gestão e incorpora os itens em
uma baseline, através do check-in, mecanismos apropriados de controle de
versão devem ser aplicados nesse momento. Uma cópia do relatório de
formalização da alteração é enviada aos interessados.
Figura 14: Ciclo de uma requisição de mudança aprovada. Fonte: Adaptada de
Molinari, 122
56
3.2.1.5
Relato de status
“O objetivo dessa tarefa é relatar a todas as pessoas envolvidas no
desenvolvimento e na manutenção do software as seguintes informações: o
que aconteceu, quem o fez, quando aconteceu, o que mais será afetado.”
(ROCHA; MALDONADO; WEBER, 2001).
Segundo
Molinari
(2007),
essa
atividade
é
responsável
por
procedimentos de extração dos dados, por meio de consultas e relatórios.
Estes permitem a formatação e o alinhamento dos dados e devem ser
totalmente automatizados, bem como seus templates disponíveis para
utilização sempre que preciso.
De acordo com Rocha, Maldonado, Weber (2001) o rápido acesso à
base de dados sobre as ocorrências na GC traz os benefícios de agilizar o
processo de desenvolvimento e melhorar a comunicação entre as pessoas.
3.2.1.6
Entrega na GCS
“No contexto da Engenharia de Software, definimos uma linha básica
como um marco de referência no desenvolvimento de um software, que é
caracterizado pela entrega de um ou mais itens de configuração e pela
aprovação dos mesmos, obtida por meio de uma revisão técnica formal”
(Pressman, 1995, 919).
De acordo com Molinari (2007), em vários momentos do ciclo de
desenvolvimento do software, são efetuadas entregas (ou deliveries) de um
determinado objeto. Esses momentos vão variar de acordo com o modelo de
desenvolvimento adotado e são chamados marcos de entrega (ou milestones).
As entregas citadas acima podem ser internas, ou seja para ser utilizada
em desenvolvimentos futuros, ou pode ser uma entrega externa, para um
cliente.
57
“Um release de um sistema é uma versão que é distribuída para os
clientes. Cada release de sistema deve incluir nova funcionalidade ou se
destinar a uma diferente plataforma de hardware. Ele pode conter, além do
código executável, a seguinte documentação:
a) Arquivos de configuração que definem como o release deve ser
configurado para instalações específicas;
b) Arquivos de dados que são necessários para operação bemsucedida;
c) Um programa de instalação que é utilizado para ajudar a instalar
o sistema no hardware-alvo;
d) Documentação eletrônica e em papel que descreva o sistema”
(SOMMERVILLE, 2003).
“A entrega dos produtos e da documentação do software devem ser
formalmente controladas. Itens relativos a funções críticas de segurança devem
ser elaborados, armazenados, empacotados e liberados de acordo com as
políticas da organização” (Rocha, Maldonado, Weber, 2001).
3.2.1.7
Auditoria da configuração
Conforme Pádua (2003) descreve, o grupo de GC deve efetuar
auditorias do repositório periodicamente. A finalidade da auditoria é verificar se:
a) as baselines estão atualizadas;
b) as alterações se originam de solicitações de mudanças aprovadas;
c) na as baselines há consistência entre descrição e conteúdo;
d) as baselines estão conformes com as regras especificadas;
e) os backups necessários foram atualizados.
Os resultados das auditorias são comunicados aos responsáveis para
que os problemas encontrados sejam resolvidos. Caso necessário, os
58
problemas encontrados também podem ser reportados à alta administração da
empresa.
59
4 CONSTRUÇÃO DO GUIA
4.1 Definição do Layout
O Layout do guia para o processo de gerência de configuração foi
baseado no layout do guia de aquisição do MPS-BR.
4.2 Definição dos subprocessos
O processo de gerência de configuração, definido nesse guia, foi
subdividido em cinco subprocessos, onde se procurou englobar atividades que
cobrissem de forma satisfatória as funções do processo de gerência de
configuração do MPS-BR.
a) Subprocesso: Planejar a Gerência de configuração do projeto
O planejamento é fundamental para o êxito de qualquer projeto. Antes
de iniciar um projeto é preciso planejar estratégias, definir regras,
elaborar atividades, definir responsabilidades, estipular metas, preparar
os recursos necessários, enfim, definir previamente como o projeto
deverá se desenvolver. Dessa forma, entre outros benefícios, evita-se o
desperdício de tempo e recursos, os improvisos são menos freqüentes e
os imprevistos são melhor administrados.
Esse subprocesso foi dividido em três atividades:
1. Estabelecer/Consultar Políticas de GC - As políticas de GC foram
estabelecidas de forma que as metas – GCO1 - Os itens de
configuração são identificados e GCO8 - O armazenamento, o
manuseio e a entrega dos produtos de trabalho são controlados – do
MPS-BR fossem atendidas, na medida em que se definiu:
60

Os itens de configuração que devam ser controlados pela gerência
de configuração;

A nomeclatura para que esses itens possam ser identificados
unicamente;

A estrutura de diretórios para armazenamento dos artefatos
produzidos ao longo do projeto;

As políticas de acesso aos dados dos repositórios;

A forma como os itens de configuração devam ser recuperados do
repositório;

As regras de versionamento para itens de configuração liberados
para entrega.
Além disso, o Backup foi incluso nas políticas de GC por se tratar de
uma atividade importante para preservação do conteúdo do repositório, como o
próprio modelo MPS-BR cita quando trata de sua meta GCO3 – É estabelecido
e mantido um Sistema de Gerência de Configuração.
2. Elaborar Plano de GC - O plano de gerência de configuração é citado
em diversos momentos no MPS-BR, por exemplo, quando trata da
identificação dos itens de configuração e da criação de linhas de
base. Portanto, essa atividade foi descrita para a elaboração desse
artefato tão importante e que vai ser utilizado em todo o processo.
3. Criar ambiente de GC - Todos os artefatos que farão parte do escopo
da gerência de configuração devem estar armazenados em um
repositório seguro e confiável. A criação da estrutura desse
repositório e as respectivas permissões de acesso são realizadas
nessa atividade e deve seguir as regras estabelecidas nas políticas
de GC.
b) Subprocesso: Manipular baseline
Baselines são elementos que ficam sobre o controle da gerência de
configuração, a partir dos quais se pode dar continuidade a
desenvolvimentos posteriores. Todas as atividades do processo de
61
Gerência de Configuração são efetuadas direta ou indiretamente em
cima das baselines. Portanto, esse é um subprocesso essencial que foi
descrito de modo a atender as seguintes metas do MPS-BR: GCO2 Os itens de configuração gerados pelo projeto são definidos e
colocados sob uma linha base e GCO4 - As modificações e liberações
dos itens de configuração são controladas.
Para atender a essas metas este subprocesso foi dividido em três
atividades:
1. Criar baseline – O momento de criação e os itens que farão parte
de uma baseline devem ser previamente definidos no plano e nas
políticas de GC. Como as baselines são pontos de referência para
outras etapas do desenvolvimento, a sua criação necessita ser
analisada e aprovada por um comitê.
2. Recuperar baseline – Esse é um passo intermediário entre a
criação e a liberação de uma baseline. Após sua criação, sempre
que uma baseline precisar passar por alterações, é necessário
recuperá-la da base de dados. Esse passo dever seguir as
formalidades
estabelecidas
pelo
subprocesso
“Controlar
Mudanças”. A forma com que uma baseline é recuperada do
repositório controlado - por check-out – está estabelecido nas
políticas de GC.
3. Liberar baseline – Uma baseline pode ser liberada internamente para ser utilizada em outras etapas do desenvolvimento do projeto –
ou externamente – para instalação no ambiente do cliente. Seja
como for, antes de sua liberação a baseline deve passar por uma
auditoria e deve seguir as regras de versionamento estabelecidas
nas políticas de GC.
62
c) Subprocesso: Controlar mudanças
As mudanças em um projeto são invitáveis e ocorrem constantemente.
Todas as mudanças que possam ocorrer em uma baseline devem
passar por um processo formal, para serem previamente analisadas de
modo a não comprometer o desenvolvimento do projeto com mudanças
inadequadas. Portanto, esse subprocesso foi estabelecido para atender
as seguintes metas do MPS-BR: GCO4 - As modificações e liberações
dos itens de configuração são controladas e GCO6 - A situação dos
itens de configuração e as solicitações de mudanças são registradas,
relatadas e o seu impacto é analisado.
1. Formalizar solicitação de mudança – Esse passo deve ser
executado para se registrar, formalmente, a necessidade de se
alterar uma baseline.
2. Analisar impacto da mudança – A análise do impacto é uma
atividade explícita na meta GCO6 do MPS-BR e é fundamental para
o desenvolvimento do projeto, pois é nela que se avalia a
abrangência das modificações e se estima, entre outros, o esforço,
tempo, recurso e prazo para realizá-las. O resultado dessa atividade
é um relatório com todas essas informações.
3. Analisar solicitação de mudança – O relatório elaborado na atividade
anterior é analisado pelo Comitê de Controle de Mudanças, grupo
formado por representantes dos diversos segmentos envolvidos no
projeto, a partir dessa análise, decide-se por aprovar ou não a
solicitação de mudança.
4. Atribuir mudança – Caso aprovada e de acordo com sua natureza, a
mudança proposta deve ser atribuída ás pessoas que tenham
competência técnica implementá-la.
5. Implementar mudança – Nessa atividade as mudanças propostas
são efetivamente realizadas. Diversas atividades do processo de
desenvolvimento do software podem efetuadas, como análise,
modelagem, implementação, revisão e teste.
63
d) Subprocesso: Relatar status da configuração
Tornar as informações e modificações da configuração do software
disponíveis aos envolvidos com elas é fundamental para o bom
andamento do projeto, uma vez que facilita a comunicação entre as
pessoas e evita o retrabalho. Esse subprocesso foi estabelecido para
atender às seguintes metas do MPS-BR: GCO5 - As modificações e
liberações são disponibilizadas para todos os envolvidos, GCO6 - A
situação dos itens de configuração e as solicitações de mudanças são
registradas, relatadas e o seu impacto é analisado e GCO9 - A
integridade das linhas bases (baselines) é estabelecida e mantida,
através de auditoria da configuração e de registros da Gerência de
Configuração.
Esse subprocesso foi dividido em duas atividades:
1. Gerar relatórios/Notificações - Nessa atividade os responsáveis
coletam as informações e agregam os dados na forma de relatórios
ou
notificações.
Isso
é
feito
em
diversos
momentos
do
desenvolvimento do projeto para que os envolvidos sejam
cientificados a respeito de qualquer acontecimento, mudança ou
informação relevante.
2. Enviar relatórios/Notificações - É a efetiva comunicação formal das
informações geradas na atividade anterior.
e) Subprocesso: Auditar configuração
Realizar a auditoria na configuração do software é muito importante
para verificar se processo esta sendo seguido, bem como a integridade
das baselines.
Esse subprocesso foi estabelecido para atender a meta GCO9: A
integridade das linhas bases (baselines) é estabelecida e mantida,
através de auditoria da configuração e de registros da Gerência de
64
Configuração. Para isso, o subprocesso foi dividido em duas
atividades:
1. Executar auditoria – Nessa atividade realiza-se a verificação do
cumprimento de tudo que está especificado no processo de Gerência
de Configuração, bem como a integridade física e funcional das
baselines.
2. Reportar resultados – Os profissionais, das áreas gerencial e técnica,
responsáveis por providenciar a correção dos possíveis desvios são
comunicados nessa atividade.
4.3 Definição dos anexos
Os anexos foram elaborados como forma de exemplificar os produtos
gerados no processo de desenvolvimento, porém eles podem ser adaptados de
acordo com as necessidades da empresa.
a) Anexo A – Plano de Desenvolvimento de Software
Esse plano de desenvolvimento de software foi adaptado do Rational
Unified Process (RUP) uma vez que é um processo de engenharia de
software reconhecido mundialmente e atende de forma satisfatória ao
processo de Gerência de Configuração estabelecido nesse guia.
A adaptação foi feita em determinados locais do plano que fazia
referência apenas ao termo “iteração”, incluindo-se o termo “etapa” de
modo que pudesse ser utilizado também por um processo de
desenvolvimento não iterativo.
b) Anexo B – Plano de Gerência de Configuração
Esse plano de gerência de configuração foi adaptado do Rational
Unified Process (RUP) uma vez que é um processo de engenharia de
65
software reconhecido mundialmente e atende de forma satisfatória ao
processo de Gerência de Configuração estabelecido nesse guia.
A adaptação foi feita em determinados locais do plano que fazia
referência apenas ao termo “iteração”, incluindo-se o termo “etapa” de
modo que pudesse ser utilizado também por um processo de
desenvolvimento não iterativo.
c) Anexo C – Planilha de controle de criação baseline
Essa planilha foi elaborada de modo a conter os dados essenciais para
identificar uma baseline que foi criada, ela descreve a data, o nome e
número correspondente à fase ou iteração da criação da baseline, o
que originou a sua criação, os itens de configuração que a compõem,
bem como o seu rótulo.
d) Anexo D – Planilha de acompanhamento de mudança
Essa
planilha
foi
proposta
como
uma
forma
de
facilitar
o
acompanhamento do andamento da solicitação de mudança, uma vez
que ela contém a identificação da solicitação de mudança, o número do
Relatório de Controle de Mudança se for o caso, e a situação em que
ela se encontra.
e) Anexo E – Relatório de controle de Mudança
Esse relatório foi baseado no referencial teórico que trata a respeito do
controle das mudanças. Portanto, as principais informações que um
relatório dessa natureza deve conter foram sintetizadas nesse relatório,
tais como descrição da mudança, o impacto nos requisitos, produtos e
prazos, bem como a estimativa de esforço. Ele contém ainda um tópico
destinado às assinaturas das pessoas aprovam as mudanças, caso
não sejam aprovadas, existe um local para tal justificativa.
f) Anexo F – Registro de Auditoria
Esse documento foi elaborado devido à necessidade de se registrar os
dados da atividade de auditoria. Ele contém campos para identificação
66
e registro dos desvios encontrados, bem como das possíveis
melhorias.
4.4 Metas do MPS-BR X Guia de Gerência de Configuração
O Guia de Gerência de Configuração tem por objetivo descrever um
processo de Gerência de Configuração que atenda, de forma satisfatória, as
metas do MPS-BR. Portanto, o quadro abaixo mostra a correspondência entre
a meta descrita mo MPS-BR e o subprocesso elaborado neste guia que vai
atendê-la, demonstrando, assim, que o objetivo foi alcançado.
Metas do MPS-BR
Subprocessos do Guia de
Gerência de Configuração
GCO1 - Os itens de configuração são
Subprocesso - Planejar a Gerência
identificados
de configuração do projeto
(atividades: Definir Políticas de GC
e Elaborar Plano de GC do projeto)
GCO2 - Os itens de configuração
Subprocessos – Planejar a
gerados pelo projeto são definidos e
Gerência de configuração do projeto
colocados sob uma linha base
(atividades: Definir Políticas de GC
e Elaborar Plano de GC do projeto)
e Manipular Baseline (atividade:
Criação de Baseline)
GCO3 – É estabelecido e mantido um
Essa meta é atendida no processo
Sistema de Gerência de Configuração
como um todo.
GCO4 - As modificações e liberações
Subprocessos: Planejar a Gerência
67
dos itens de configuração são
de configuração do projeto
controladas
(atividade: Definir Políticas de GC),
Manipular Baseline (atividade:
Liberação de Baseline) e Controlar
Mudanças
GCO5 - As modificações e liberações
Subprocessos: Manipular Baseline
são disponibilizadas para todos os
(atividade: Liberação de Baseline) e
envolvidos
Controlar Mudanças (atividade:
Comunicar os envolvidos).
GCO6 - A situação dos itens de
Subprocessos: Controlar Mudanças
configuração e as solicitações de
(atividades: Formalizar Solicitação
mudanças são registradas, relatadas e
de Mudança e Analisar Impacto da
o seu impacto é analisado
Mudança) e Relatar status da
Configuração
GCO7 - A completeza e a consistência
Essa meta é atendida no processo
dos itens de configuração são
como um todo.
asseguradas
GCO8 - O armazenamento, o manuseio
Subprocessos: Planejar a Gerência
e a entrega dos produtos de trabalho
de configuração do projeto
são controlados
(atividade: Definir Políticas de GC e
Elaborar Plano de GC do projeto) e
Manipular Baseline (atividade:
Liberação de Baseline)
GCO9 - A integridade das linhas bases
Subprocessos: Relatar Status da
(baselines) é estabelecida e mantida,
Configuração e Auditar
através de auditoria da configuração e
configuração
de registros da GC.
Quadro 8: Metas do MPS-BR X Subprocessos do Guia de Gerência de Configuração
68
Conclusão
A demanda por produtos e serviços de qualidade é crescente em todas
as áreas. A cada dia o mercado consumidor está mais exigente e, por
conseguinte, o investimento em práticas que levam a obtenção da qualidade
nos processos de produção e no produto final tem sido cada vez maior.
Nesse contexto, a área da engenharia de software tem sido subsidiada
pela disciplina de qualidade de software. A indústria de software tem investido
na qualidade através da adoção de normas, padrões e modelos de referência
de qualidade que se preocupam não só com a qualidade do produto, mas
também com a qualidade do processo de desenvolvimento do software.
Dentre esses modelos de referência, destaca-se o MPS-BR, que é um
modelo adequado a micro e pequenas empresas e voltado para a realidade
brasileira. Tal modelo, no que se refere à implantação dos processos de
desenvolvimento de um software, é subdividido em níveis de maturidade.
Dentre esses níveis, destacamos o nível F o qual contempla o processo de
Gerência de Configuração de Software, foco do presente trabalho.
O processo de Gerência de Configuração é um processo de apoio ao
desenvolvimento do software e seu objetivo é manter a integridade dos
artefatos produzidos ao longo do ciclo de vida do projeto, de modo que a
evolução desses artefatos seja acompanhada e suas mudanças sejam
controladas e comunicadas aos envolvidos.
Pelo fato do modelo MPS-BR não ser um modelo descritivo, ou seja,
ele diz o que fazer, mas não como fazer, esse trabalho teve o objetivo de
preencher essa lacuna. Portanto, foi elaborado um guia para o processo de
Gerência de Configuração, onde são relatados, de modo detalhado, os seus
subprocessos com suas respectivas atividades, bem como os produtos
requeridos e gerados em cada uma delas.
Para elaborar o guia foi necessária uma pesquisa bibliográfica sobre o
tema, utilizando-se livros, materiais eletrônicos disponíveis na Web e
69
programas que abordavam o assunto. É importante destacar que o material
publicado na Web se mostrou muito superficial, sendo imprescindível, para o
êxito do trabalho, a pesquisa em livros voltados exclusivamente para o tema.
Com a produção do guia, procurou-se subsidiar as empresas
desenvolvedoras de software a atingir as metas estabelecidas no nível F do
MPS-BR para o processo de Gerência de Configuração, ou simplesmente a
estabelecer um processo de Gerência de Configuração no âmbito de sua
organização, de modo a tornar seu processo de desenvolvimento mais
eficiente.
Como continuidade desse trabalho, é possível efetuar um estudo de
caso com a aplicação do guia em uma empresa real, verificando-se, desse
modo, sua eficácia, outra sugestão seria desenvolver um aplicativo que desse
suporte às atividades descritas no processo de Gerência de Configuração.
70
Apêndice A – Guia para Gerência de Configuração de
Software
Este guia contém orientações
para
a
processo
implantação
de
de
um
Gerência
de
Configuração de Software.
Adriana Reis de Almeida Rodrigues
Universidade Católica de Brasília
Novembro de 2007
71
Sumário
1.
Introdução .................................................................................................... 72
2.
Objetivo..... ................................................................................................... 72
3.
Descrição do processo de Gerência de Configuração (GC)................. ........ 72
3.1
Visão Geral ...................................................................................................... 72
3.2
Planejar a GC do projeto ................................................................................. 76
3.3
Manipular baseline .......................................................................................... 84
3.4
Controlar as mudanças ................................................................................... 87
3.5
Reportar status de configuração...................................................................... 91
3.6
Auditar configuração ........................................................................................ 94
Anexo A – Plano de Desenvolvimento de Software .................................................. 97
Anexo B – Plano de Gerência de Configuração ...................................................... 105
Anexo C – Planilha de Controle de criação baseline ............................................... 108
Anexo D – Planilha de Acompanhamento de Mudanças ........................................ 109
Anexo E – Relatório de Controle de Mudanças....................................................... 110
Anexo F – Registro de Auditoria.............................................................................. 113
72
1. Introdução
Ao longo do ciclo de vida de um software diversas pessoas estão envolvidas e
inúmeros artefatos são produzidos. O conjunto de artefatos – incluindo
documentação, código, protótipo, etc. – forma a configuração de um software.
Tudo que for produzido e/ou alterado deve ser registrado para que haja um
efetivo controle das versões dos artefatos e assim, se possa fazer o
reconhecimento de qual versão é válida em um determinado momento.
Durante o processo de desenvolvimento de um software várias mudanças
podem ocorrer, pelos mais diversos motivos, que pode ser a necessidade de
adaptação ao novo ambiente em que o software está inserido, a inclusão de
um novo requisito não informado anteriormente ou a mudança no próprio
negócio. O controle dessas mudanças é fundamental para que informações
relevantes não se tornem inconsistentes, além de se evitar alterações
prejudiciais ao próprio projeto.
Outro aspecto importante diz respeito à comunicação das mudanças ocorridas.
Pelo fato de uma alteração, normalmente, gerar outras, é necessário que todas
as alterações sejam comunicadas às pessoas envolvidas e às que serão
afetadas por elas.
A gerência de configuração se preocupa com todos os elementos abordados,
por isso ela é uma atividade de apoio tão importante ao desenvolvimento do
software e deve estar presente desde o início do seu ciclo de desenvolvimento.
De acordo com o MPS-BR, o propósito do processo de Gerência de
Configuração “é estabelecer e manter a integridade de todos os produtos de
trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos”.
2. Objetivo
Este guia tem por finalidade descrever os subprocessos, e suas respectivas
atividades, que são necessários para que uma empresa possa implantar um
processo de Gerência de Configuração (GC) de modo a atender as metas do
MPS-BR.
3. Descrição do processo de Gerência de Configuração (GC)
3.1 Visão Geral
O gerenciamento de configuração é um processo de apoio ao desenvolvimento
do projeto e seu propósito é definir as atividades para aplicação de
procedimentos administrativos e técnicos destinados a identificar e definir os
itens de configuração, estabelecer e manter a integridade dos artefatos
gerados ao longo do projeto, bem como comunicar às pessoas interessadas da
produção ou modificação de tais artefatos. Este processo deve ser estar
presente desde o início do ciclo de vida do projeto.
73
Como resultado da implementação bem-sucedida do processo de Gerência de
Configuração temos:
1. Um Sistema de Gerência de Configuração é estabelecido e mantido;
2. Os itens de configuração são identificados;
3. Os itens de configuração sujeitos a um controle formal são colocados sob
baseline;
4. A situação dos itens de configuração e das baselines é registrada ao longo
do tempo e disponibilizada;
5. Modificações em itens de configuração são controladas e disponibilizadas;
6. Auditorias de configuração são realizadas;
7. O armazenamento, o manuseio e a liberação de itens de configuração e
baselines são controlados.
Este processo será descrito a seguir através dos seus 5 (cinco) subprocessos
(Figura 1):





Planejar a GC do projeto (ver 3.2)
Manipular baseline (ver 3.3)
Controlar mudanças (ver 3.4)
Relatar status da configuração (ver 3.5)
Auditar configuração (ver 3.6)
74
Visão Geral do processo de Gerência de Configuração
Planejar a GC
do projeto
Manipular
baseline
Controlar
mudanças
Relatar status
de configuração
Auditar
configuração
1. Estabelecer/Consultar Políticas de GC
2. Elaborar Plano de GC
3. Criar ambiente de GC
1. Criar baseline
2. Recuperar baseline
3. Liberar baseline
1.
2.
3.
4.
5.
6.
Formalizar solicitação de mudança
Analisar impacto da mudança
Analisar solicitação de mudança
Atribuir mudança
Implementar mudança
Comunicar os envolvidos
1. Gerar relatório/Notificação
2. Enviar relatório/Notificação
1. Executar auditoria
2. Reportar resultados
75
Cada um dos subprocessos está detalhado, quando pertinente, pelos seguintes
itens:
 Objetivo: descreve os objetivos a serem alcançados com a realização
do subprocesso e orientações gerais a respeito do subprocesso;
 Atividades previstas: identifica e descreve as atividades necessárias
para atingir os objetivos e obter os resultados previstos para o
subprocesso;
 Produtos requeridos e gerados: relaciona os insumos necessários
para executar cada atividade prevista no subprocesso, bem como os
produtos das atividades previstas no subprocesso.
76
3.2 Planejar a GC do projeto
Objetivo
O propósito do subprocesso “Planejar a GC do projeto” é definir as diversas
práticas relacionadas à GC, determinar COMO, QUANDO E POR QUEM as
atividades de GC serão desempenhadas ao longo do desenvolvimento do
projeto, bem como criar o ambiente necessário para o gerenciamento da
configuração. Ele é composto pelas seguintes atividades:
Estabelecer/Consultar políticas de GC (ver Pl-a1);
Elaborar o plano de GC (ver Pl-a2); e
Criar ambiente de GC (ver Pl-a3).
Atividades previstas
Id.
Atividade
Pl-a1
Estabelecer/consultar políticas de GC
Descrição:
As políticas de GC são estabelecidas pelo gerente de GC e são
usadas para estipular diversas práticas a serem aplicadas na
seleção, identificação, armazenamento, acesso, versionamento e
manutenção da configuração, de modo a torná-la consistente e
confiável.
1. Práticas de identificação da configuração:
A identificação da configuração agiliza a identificação e
localização de qualquer versão de item do configuração do
projeto.
 Seleção dos itens de configuração
A definição do escopo dos itens de configuração é fundamental
para uma gerência de configuração eficiente. Ele não deve ser
nem muito amplo, para não dificultar o gerenciamento e nem
muito restrito para não limitar ou prejudicar o processo de
gerência de configuração. Os critérios podem variar de acordo
com cada projeto, o analista de GC do projeto deve selecionar os
itens de configuração dentre os seguintes critérios:

Produtos que são passíveis de alterações e que devam ser
mantidos sob o controle de versões;

Produtos que são dependentes entre si e que, por esse motivo,
ocasionam um efeito dominó quando alterados;
77

Produtos que podem ser compartilhados por mais de um grupo;

Produtos que são críticos para o controle do projeto;

Produtos de uma fase que servem de insumo para outra fase do
projeto;

Produtos projetados para reutilização;

Produtos que serão entregues aos clientes.
 Definição dos rótulos de identificação
Identificar a configuração permite que se localize e identifique de
forma rápida e fácil a versão correta de qualquer artefato de
projeto. Para se identificar unicamente um item de configuração
deve-se rotulá-los. Os rótulos identificam versões específicas de
artefatos.
Utilizando a ferramenta de GC, o analista de GC do projeto deve
rotular os IC de acordo com a seguinte estrutura de rótulo de
identificação única:
<Cliente> - <Sigla do sistema> - <Nome do Item>
<Cliente>
Sigla do cliente
<Sigla do sistema>
Sigla que identifica o Sistema
<Nome do Item>
Nome que identifica o item.
Identificação de baseline
Quando um ou um conjunto de itens de configuração passa a ser
uma baseline, ele deve seguir o seguinte rótulo identificador de
versão:
BL-<Sigla do sistema>–<AAAAMMDD>–<Fase/Iteração>
BL:
Indica que é uma linha de base.
Sigla do sistema:
Sigla do sistema.
AAAAMMDD:
Ano, mês e dia.
78
Fase/Iteração:
Sigla da fase ou iteração.
Exemplo: BL-SGA-20070421-E1 (Elaboração 1 - Iterativo)
BL-SAB-20050702-F4 (Fase 4 - Cascata)
Documentos que possuem subclassificações, como atas e
relatórios, necessitam de um maior detalhamento na sua
nomeclatura, para isso deve-se seguir as seguintes instruções:
Atas e Relatórios:

Atas de Requisitos:
<Cliente > - <Sigla do Sistema> – Ata LREQ <AAAAMMDD>
(LREQ = Levantamento de Requisitos)
<Cliente> - <Sigla do Sistema> – Ata AREQ <AAAAMMDD>
(AREQ = Aprovação de Requisitos)

Relatórios:
<Cliente> - <Sigla do Sistema> – RAP <AAAAMMDD>
(RAP = Relatório de Acompanhamento de Projeto)
<Cliente> - <Sigla do Sistema> – RCM <AAAAMMDD>
(RCM = Relatório de Controle de Mudanças)
2. Práticas para definição da estrutura de armazenamento e
controle de acesso
Os ICs do projeto são mantidos no repositório, portanto, o servidor
destinado a esse fim precisa ser confiável, tolerante a falhas e
apresentar um alto nível de desempenho. A estrutura lógica do
repositório facilita a identificação dos artefatos e deve observar a
hierarquia entre eles. Devem existir dois repositórios, um para
itens de configuração em desenvolvimento e outro para baselines.
Os repositórios podem possuir a seguinte estrutura básica,
devendo ser adaptada de acordo com as necessidades da
organização:
Estrutura de diretórios dos Repositórios:
79
Figura 1: Estrutura dos repositórios
80
Políticas de acesso aos repositórios:
Diretório
Ambiente
Usuário
Acesso
Gerente do Projeto
R, C e A
Análise e Design
Gerente de GC e R, C, A e D
Documentos não Padronizados analista de GC do
Gerenciamento de Configuração projeto
Gerenciamento de Projeto
Implantação
Usuários da equipe
do projeto
Implementação
Todos os demais
R, C e A
R
Modelagem de Negócios
Requisitos
Teste
(Acesso) direitos de acesso: R (read), C (check-in/check-out), A (add/rename/delete) e D (destroy)
3. Práticas de controle de versão
O controle de versões dos ICs que não são passíveis de entrega
é realizado pela própria ferramenta de controle de versões e terá
o histórico das alterações documentadas no comentário de cada
versão criada.
O controle de versões dos ICs que são passíveis de entrega é
realizado através de rótulos, conforme descrito abaixo:
 Entrega de produtos:
O rótulo dos IC a ser entregues devem ter um sufixo identificando
a entrega e um número correspondente à versão. Por exemplo,
E1, onde E significa Entrega e o número 1 a versão interna do
produto.

Para homologação:
Enquanto o produto estiver com o responsável pela homologação,
o analista de GC deve bloqueá-lo com algum recurso da
ferramenta de controle de versão, para garantir que ninguém, sem
sua autorização, o altere. Até esse momento o produto deve fazer
parte do repositório de desenvolvimento.
Após a homologação, o produto deve ser rotulado como
homologado, conforme exemplo abaixo, e se for alterado, deve
ser homologado novamente.
Ele está apto a se tornar uma baseline, se for o caso, e para isso
81
deve seguir o especificado na atividade de “criar baseline”, caso
seja aprovada a criação de uma baseline, ele deverá ser
promovido para o repositório de baselines e rotulado de acordo
com as políticas de GC.
Primeira entrega:
GRU-20060403-E2-E1 (versão 1)
Segunda entrega:
GRU-20060405-E2-E2 (versão 2)
Enésima entrega:
GRU-20060407-E2-EN (versão N)
Homologado:
GRU-20000409-E2-H

Após homologação:
Quando se tratar de uma entrega de um item já homologado, ele
deve ser recuperado do repositório de baselines e seguir o que
está especificado em “Recuperar baseline”.
Caso seja uma entrega para um cliente, seu rótulo deve
especificar que se trata de um release colocando-se o sufixo “R”,
se for uma entrega interna para dar continuidade ao
desenvolvimento do software, ao seu rótulo deve-se acrescentar o
sufixo “I”, indicando que é uma entrega interna, conforme os
exemplos a seguir:
LB-GRU-20060511-I3-R (Release)
LB-GRU-20060511-I3-I (Interna)
4. Práticas para efetuar check-in/check-out
As ferramentas de controle de versão organizam os acessos ao
repositório por meio de operações básicas conhecidas como
check-in/check-out. O método adotado para efetuar essas
operações é o “Trava-Modifica-Destrava”. A grande vantagem
deste método é prevenir acessos conflitantes ao repositório,
quando mais de uma pessoa tenta trabalhar no mesmo conjunto
de ICs.
Check-out – obtém cópia de trabalho da versão desejada do IC
para modificação e, simultaneamente, impede acessos à versão
por outros usuários. Nessa operação não é necessário informar
comentários.
Check-in – cria nova versão do IC a partir de cópia de trabalho
modificada (obtida por check-out) e libera acessos. Nesta
operação o usuário deve obrigatoriamente registrar um
comentário que descreva o que foi alterado.
82
5. Práticas para realizar backup
O backup serve para assegurar a disponibilidade dos dados,
guardando-os em outro lugar seguro, em caso de acidente ou erro
fatal nas aplicações do sistema.
O backup deverá ser feito fora dos horários de pico e no modo offline para ter um melhor desempenho.
A estratégia de backup deverá ser:


Backup total semanalmente e
Backup incremental diariamente.
Produtos gerados:
Pl-p1 – Políticas de gerência de configuração.
Pl-a2
Elaborar o plano de Gerência de configuração
Descrição:
O plano de GC deve ser elaborado pelo analista de GC do projeto
e deve descreve quais as atividades relacionadas à GC devem
ser realizadas no decorrer do ciclo de vida do projeto. Bem como
o
cronograma
dessas
atividades,
a
atribuição
de
responsabilidades e os recursos necessários para desempenhálas. Ele deve ser elaborado no início do projeto e revisado a casa
fase de desenvolvimento, para assegurar que realmente está
adequado ao desenvolvimento do software.
Produtos requeridos:
Pl-p1 – Políticas de gerência de configuração.
Pl-p2 - Plano de desenvolvimento de software1.
Produtos gerados:
Pl-p3 – Plano de gerência de configuração2.
NOTA 1: Ver template do plano de desenvolvimento de software no
anexo A.
NOTA 2: Ver template do plano de gerência de configuração no anexo
B.
Pl-a2
Criar ambiente de GC
Descrição:
O analista de GC do projeto deve solicitar ao pessoal do suporte a
alocação de recursos de hardware necessários para instalar e
configurar a ferramenta de GC.
83
Com o auxilio da ferramenta de GC o analista de GC deve criar os
repositórios do projeto e atribuir os direitos de acesso, conforme
estabelecido nas Políticas de GC.
Produtos requeridos:
Pl-p1 – Políticas de gerência de configuração.
Pl-p3 - Plano de gerência de configuração.
Produtos gerados:
Pl-p4 – Repositórios do projeto.
Produtos requeridos e gerados
Id.
Produtos
Pl-p1
Políticas de gerência de Documento que consta as definições
de diversas práticas a serem seguidas
configuração
durante o desenvolvimento do software
em
relação
à
gerência
de
configuração.
Plano de desenvolvimento Documento que consta todas as
informações necessárias ao controle
de software
do projeto.
Plano de gerência de Documento que consta as atividades
relacionadas
à
implantação
e
configuração
administração do processo de gerência
de configuração.
Pl-p2
Pl-p3
Pl-p4
Repositório do projeto
Descrição
Local de armazenamento de todas as
versões de arquivos do projeto.
84
3.3 Manipular baseline
Objetivo
O propósito do subprocesso “Manipular baseline” é criar baselines, recuperálas para implementação de mudanças e liberá-las para o cliente ou para
utilização interna.
As atividades previstas compreendem:
Criar baseline (ver Mb-a1);
Recuperar baseline (ver Mb-a2); e
Liberar baseline (ver Mb-a3).
Atividades previstas
Id.
Atividade
Mb-a1
Criar baseline
Descrição:
Uma baseline tem por finalidade identificar um ou um conjunto
de itens de configuração que estabeleçam um marco do
projeto. Através das baselines é possível retroceder no tempo
e reproduzir uma determinada versão ou ambiente de
desenvolvimento do projeto, rastrear o relacionamento de um
produto e elaborar relatórios através de comparação entre os
conteúdos das baselines.
Os ICs que compõem as baselines deverão ser definidos e
documentados no plano de GC do projeto.
Os projetos deverão ter, no mínimo, o número de baselines
correspondentes às fases do ciclo de vida do projeto,
conforme a metodologia adotada. O gerente do projeto poderá
definir baselines intermediárias, caso considere necessário.
A criação de uma baseline é efetuada pelo analista de GC,
após solicitação do gerente do projeto. O analista de GC
registra a solicitação de criação da baseline e encaminha tal
solicitação ao Comitê de Controle de Mudança1 (CCM) para
análise e aprovação. Caso não seja aprovada, tal motivo deve
ser informado. Depois de criar a baseline o analista de GC do
projeto bloqueia os IC, que só podem ser alterados mediante
processo formal de mudanças.
Toda baseline criada deve ser rotulada conforme as Políticas
de GC e deve ser registrada na Planilha de Controle de
85
criação de baseline2.
Produtos requeridos:
Pl-p1 – Políticas de gerência de configuração.
Mb-p1 – Solicitação de criação de baseline.
Produtos gerados:
Mb-p2 – Baseline.
Mb-p3 – Planilha de controle de criação de baseline2.
NOTA 1: O Comitê de controle de Mudança é um grupo formado por
representantes de todos os afetados por possíveis mudanças no
projeto, tais como: usuários, desenvolvedores, gerente do projeto,
analista de GC, gerente de GC e a alta administração da empresa. A
formação desse grupo vai variar de acordo com impacto da
mudança no projeto. Quanto maior o impacto, maior deve ser o
poder de decisão das pessoas que formam o CCM. Esse comitê é
responsável por autorizar a criação e recuperação de baselines,
bem como revisar e aprovar as mudanças propostas.
NOTA 2: Ver template de Planilha de controle de criação de baseline
no Anexo C
Mb-a2
Recuperar baseline
Descrição:
A recuperação de uma baseline é efetuada somente mediante a
aprovação da solicitação de mudança pelo CCM, conforme o
subprocesso “Controlar mudanças”. O gerente do projeto
solicita a recuperação da baseline ao analista de GC
referenciando o RCM correspondente.
Produtos Requeridos:
Cm-p4 – Relatório de controle de mudança (RCM)1.
Produtos gerados:
Mb-p2 – Baseline.
NOTA 1: Ver template de relatório de controle de mudança no
anexo E.
Mb-a3
Liberar baseline
Descrição:
A liberação de uma baseline pode ser internamente, com
finalidade de reutilização em futuras iterações/etapas do projeto
e/ou em outros projetos ou externamente (release), que é a
86
entrega para um cliente.
O rótulo das baselines a serem liberadas deve seguir o padrão
especificado nas Políticas de GC. Sempre que uma baseline for
ser liberada, ela deve passar por uma auditoria, conforme
estabelecido no subprocesso de “Auditar Configuração”.
A liberação de uma baseline deve ser disponibilizada ao
envolvidos, por meio do subprocesso “Relatar status da
configuração”.
Quando se tratar da entrega de um produto executável para o
cliente, o analista de GC do projeto é responsável por
providenciar uma cópia dos produtos liberados na mídia
necessária para implantação no ambiente de destino.
Produtos requeridos:
Pl-p1 – Políticas de gerência de configuração.
Produtos gerados:
Mb-p2 – Baseline.
Produtos requeridos e gerados
Id.
Produtos
Pl-p1
Políticas de gerência de Documento que consta as definições
de diversas práticas a serem seguidas
configuração
durante o desenvolvimento do software
em
relação
à
gerência
de
configuração.
Solicitação de criação de Documento que registra um pedido
configuração base
formal de criação de uma configuração
base.
Mc-p1
Descrição
Cm-p4
Relatório de controle de Documento onde são registradas as
mudança
informações sobre a avaliação do
imapcto da mudança solicitada.
Mb-p2
Baseline
Mb-p3
Planilha de controle de Documento onde são registradas
criação de baseline
informações acerca da criação das
baselines.
É um IC ou um conjunto de ICs que
estabelecem um marco no projeto.
87
3.4 Controlar as mudanças
Objetivo
O propósito do subprocesso “Controlar mudanças” é garantir que as mudanças
propostas a um sistema sejam avaliadas e aplicadas de forma controlada. As
atividades previstas compreendem:
Formalizar solicitação de mudança (ver Cm-a1);
Analisar impacto da mudança (ver Cm-a2);
Analisar solicitação de mudança (ver Cm-a3);
Atribuir mudanças (ver Cm-a4);
Implementar mudanças (ver Cm-a5);e
Comunicar os envolvidos (ver Cm-a6).
Atividades previstas
Id.
Atividade
Cm-a1
Formalizar solicitação de mudança
Descrição:
As solicitações de mudanças podem ser propostas por qualquer
envolvido no projeto e surgem pelos mais diversos motivos,
como inclusão/alteração de requisitos e melhoria/correção de
algum artefato. O gerente do projeto registra a solicitação de
mudança numa planilha de acompanhamento de mudança
(PAM), com a data e a situação de “Aberta”. Nessa planilha
ficam registradas as informações da situação da solicitação
desde sua abertura até o fechamento. A cada mudança de
situação, o gerente do projeto de projetos deve atualizá-la
informando a data e a nova situação.
Produtos gerados:
Cm-p1 – Solicitação de mudança.
Cm-p2 – Planilha de acompanhamento de mudança (PAM)1.
NOTA1: Ver template da Planilha de acompanhamento de
mudança no Anexo D.
Cm-a2
Analisar o impacto
Descrição:
88
Nessa atividade verifica-se qual a abrangência da solicitação da
mudança e se haverá alteração no escopo do projeto e/ou
produto. O gerente do projeto e sua equipe avaliam o impacto da
mudança sob o ponto de vista técnico e gerencial, verificando
quais os produtos associados ao projeto serão afetados, bem
como as possíveis alterações no tamanho, no esforço, no prazo
e no custo que essas mudanças podem agregar ao projeto.
O gerente do projeto registra os resultados dessas avaliações no
Relatório de controle de mudança (RCM). A planilha de
acompanhamento de mudança deve ser atualizada com o nº do
RCM correspondente.
Produtos requeridos:
Cm-p1 – Solicitação de mudança.
Cm-p2 – Planilha de acompanhamento de mudança.
Pl-p1 – Plano de desenvolvimento de Software;
Cm-p3 – Produtos diversos que sirvam como base para essa
atividade.
Produtos gerados:
Cm-p4 – Relatório de controle de mudança (RCM).
Cm-a3
Analisar a solicitação de mudança
Descrição:
Todas as solicitações de mudanças devem ser submetidas à
aprovação do comitê de controle de mudança (CCM). O CCM,
de acordo com as conclusões do RCM, define por aceitar ou
rejeitar a solicitação de mudança.
A aprovação do RCM denota que o coordenador de projetos
está autorizado a dar seguimento às próximas atividades. Caso
a solicitação de mudança seja reprovada, a justificativa da
reprovação deve ser registrada no RCM.
O gerente do projeto deve atualizar a planilha
acompanhamento de mudança como “Aprovada”
“Reprovada” de acordo com a avaliação do CCM.
Produtos requeridos:
Cm-p2 – Planilha de acompanhamento de mudança.
Cm-p4 – Relatório de controle de mudança (RCM).
Produtos gerados:
Cm-p2 – Planilha de acompanhamento de mudança.
Cm-p4 – Relatório de controle de mudança (RCM).
de
ou
89
Cm-a4
Atribuir mudanças
Descrição:
Após a aprovação da mudança, o gerente do projeto deve
atualizar a planilha de acompanhamento de mudança
colocando a sua situação com “Atribuída”. Ele deve ainda
atribuir tarefas à equipe do projeto, que são os responsáveis
pela implementação e testes da mudança até o seu
fechamento, além de fazer as atualizações necessárias nos
planos e cronograma do projeto.
Produtos requeridos:
Cm-p2 – Planilha de acompanhamento de mudança.
Produtos gerados:
Cm-p2 – Planilha de acompanhamento de mudança.
Cm-a5
Implementar mudanças
Descrição:
Para que as mudanças possam ser implementadas deve-se
recuperar os itens de configuração no repositório. Esse
procedimento tem que ser feito de acordo com o estabelecido
nas políticas de GC no que corresponde ao controle de acesso
ao repositório e ao uso do check-in e check-out para modificar
os itens de configuração.
A implementação das mudanças envolve outras atividades do
processo de desenvolvimento do software, como análise,
modelagem, codificação, revisão e teste. Desse modo, cada
profissional deve implementar a tarefa de sua responsabilidade.
Durante a implementação das mudanças, a situação da
solicitação de mudança na PAM deve ser atualizada como:
“Desenvolvimento” e após concluí-las: “Em testes”.
O Analista de Sistemas responsável pela execução da revisão e
dos testes verifica se há alguma discordância, entre o que foi
planejado e o que foi efetivamente implementado, se for
encontrada deve-se retornar para atividade de implementar
mudanças a fim de torná-las coerente com o que foi
especificado. Caso esteja tudo correto, a planilha de
acompanhamento de mudanças deve ser atualizada, pelo
gerente do projeto, como “Encerrada”.
Produtos requeridos:
Cm-p2 – Planilha de acompanhamento de mudança.
Cm-p4 – Relatório de controle de mudança (RCM).
90
Cm-p5 – Produtos
desenvolvimento.
típicos
para
as
atividades
de
Produtos gerados:
Cm-p2 – Planilha de acompanhamento de mudança.
Cm-p3 – Nova versão dos IC alterados.
Cm-a6
Comunicar os envolvidos
Descrição:
A cada alteração da situação da solicitação de mudança, o
gerente do projeto deve notificar os envolvidos, para que
possam se atualizar sobre a nova situação, isso pode ser feito
através da própria planilha de controle de mudança, de um email ou de outra documentação específica para esse fim.
Após o encerramento de uma solicitação de mudança, ou seja,
quando ela tiver sido atendida, o gerente do projeto deve
comunicar formalmente todos os envolvidos na mudança ou
que serão afetados por elas. O analista de GC do projeto deve,
a partir dessa notificação, gerar novas baselines, conforme a
atividade “criar baseline” do subprocesso “Manipular baseline”.
Produtos requeridos:
Cm-p2 – Planilha de acompanhamento de mudança.
Cm-p3 – Nova versão dos IC alterados.
Produtos gerados:
Cm-p4 – Registro de comunicação de mudança.
91
Produtos requeridos e gerados
Id.
Produtos
Descrição
Pl-p1
Plano de desenvolvimento
de Software
Documento que consta as atividades
relacionadas
à
implantação
e
administração do processo de
gerência de configuração. Deve
conter, também, a descrição de como
e quando as atividades serão
efetuadas e quem serão os
responsáveis por elas, bem como os
recursos necessários.
Cm-p1
Solicitação de mudança
Documento usado para registrar um
pedido de mudança.
Cm-p2
Planilha de
acompanhamento de
mudança.
Documento onde são registradas as
informações
da
situação
da
solicitação de mudança desde a
abertura até o seu fechamento.
Cm-p3
Produtos diversos que
sirvam como base para
essa atividade
São documentos originados de
diversas atividades do ciclo de
desenvolvimento do projeto, tais
como atas de reuniões e estimativas
do projeto.
Cm-p4
Relatório de controle de
mudança (RCM).
Documento onde são registradas as
informações sobre a avaliação do
imapcto da mudança solicitada.
Cm-p5
Produtos típicos para as
atividades de
desenvolvimento
São produtos necessários para a
execução da mudança em si, tais
como casos de uso, modelo de
análise, modelo de design e planos
de teste.
3.5 Reportar status de configuração
Objetivo
O propósito do subprocesso “Relatar status da configuração” é auxiliar as
atividades de estimativa e assegurar que os dados sejam “agregados” e
reportados, por meio de atividades de relatórios e/ou notificações.
As atividades previstas compreendem:
92
Gerar relatório/Notificação (ver Rs-a1);e
Enviar relatório/Notifica (ver Rs-a2).
Id.
Atividade
Mb-a1
Gerar relatório/Notificação
Descrição:
O
analista
de
GC
do
projeto
deve
fornecer
relatórios/notificações, de acordo com o plano de
gerenciamento de configuração, cuja freqüência pode ser:
Diariamente, Semanalmente, Mensalmente, Por Iteração, Por
Fase e no Final do Projeto.
O analista de GC deve informar os envolvidos sempre que uma
baseline for criada ou liberada. O gerente do projeto deve
notificar os envolvidos sempre que a situação de uma
solicitação de mudança for alterada.
Com a ajuda de ferramentas de coleta de dados deve-se gerar
relatórios do status da configuração do software com base, por
exemplo, nas seguintes fontes:
1. Solicitações de Mudança;
2. Descrição de versão; e
3. Auditorias.
1. Quanto a Solicitações de Mudança
Os relatórios derivados das solicitações de mudança realizadas
no projeto podem esclarecer diversas questões e deles podem
ser extraídas métricas importantes que ajudam nas estimativas
do projeto com base no tipo, no número, na classificação e na
gravidade dos defeitos encontrados e corrigidos, durante o
desenvolvimento do produto. Exemplos de questões:
 Há quanto tempo as Solicitações de Mudança estão
pendentes?
 Qual é o número acumulado de defeitos encontrados e
corrigidos no decorrer do tempo?
 Qual é a classificação dos defeitos detectados e corrigidos?
 Qual é a 'lacuna de qualidade' em termos de defeitos
pendentes versus defeitos corrigidos?
 Qual é a média de tempo de correção de um defeito?
 Quem está detectando, qual tipo de defeito e em que ponto
do projeto?
 Quantos problemas estão em aberto para um determinado
profissional?
93
 Qual é o nível de gravidade dos defeitos que estão sendo
detectados?
 Em que ponto do processo os problemas estão sendo
gerados (causa original)?
 Quantos defeitos estão em aberto neste dia, nesta semana
ou neste mês?
 Quantos defeitos foram corrigidos neste dia, nesta semana ou
neste mês?
2. Descrição de versão
Relatórios de descrição de versão descrevem os detalhes de
um release do software. Tal relatório contém as seguintes
informações:




Inventário do material liberado (mídia física e documentos),
Inventário do conteúdo do software (listagens de arquivos),
Instruções de instalação e
Possíveis problemas e erros conhecidos.
3. Auditorias
As auditorias devem ser realizadas de acordo com o
subprocesso “Auditar configuração”. Ao final das auditorias, um
relatório deve ser gerado com o resultado das verificações
efetuadas.
Produtos requeridos:
Pl-p2 - Plano de gerência de configuração;
Pl-p4 – Repositório do projeto.
Produtos gerados:
Rs-p1 – Relatórios/Notificações diversos.
Rs-a2
Enviar relatório/Notificação
Descrição:
Os relatórios gerados devem ser enviados às pessoas que
precisam tomar conhecimento de seus dados, a fim de se
atualizarem sobre o novo status do projeto e tomar decisões, no
âmbito gerencial e/ou técnico, necessárias para resolver os
problemas que neles são reportados.
Produtos requeridos:
94
Rs-p1 – Relatórios/Notificações diversos.
Produtos gerados:
Rs-p2 – Registro de envio de relatório/Notificação.
Produtos requeridos e gerados
Id.
Produtos
Descrição
Pl-p2
Plano de gerência de
configuração
Documento que consta as atividades
relacionadas
à
implantação
e
administração do processo de gerência
de configuração.
Pl-p4
Repositório do projeto
Local de armazenamento de todas as
versões de arquivos do projeto.
Rs-p1
Relatórios/Notificações
diversos
São relatórios/notificações gerados a
partir de dados da configuração do
software. Podem sem baseados nas
solicitações
de
mudança,
nas
descrições de versões e nas
auditorias.
Rs-p2
Registro de envio de
relatório/Notificação.
É um registro formal, espécie de
comprovante,
do
envio
de
relatório/notificação. Pode ser através
de um e-mail ou outra documentação
específica para esse fim.
3.6 Auditar configuração
Objetivo
O propósito do subprocesso “Auditar configuração” é verificar se os
procedimentos estabelecidos nas políticas de GC e no processo de gerência de
configuração como um todo estão sendo seguidos, bem como, verificar a
integridade física e funcional das baselines. As atividades previstas
compreendem:
Executar auditoria (ver Ac-a1) e
95
Reportar resultados (ver Ac-a2).
Atividades previstas
Id.
Atividade
Ac-a1
Executar auditoria
Descrição:
As auditorias concentram-se na verificação do cumprimento dos
procedimentos estabelecidos tanto nas políticas de GC como no
processo de GC como um todo, além de verificar a integridade
física e funcional das baselines.
As auditorias devem ser realizadas pelo gerente de GC, ou por
uma pessoa do grupo de GC que não esteja envolvido
diretamente com o projeto auditado, por meio de uma Lista de
verificação de GC. As informações obtidas nas auditorias são
registradas no Relatório de auditoria de GC. A auditoria pode
verificar tanto aspectos físicos como funcionais da configuração,
para determinar que uma baseline contém todos os artefatos
necessários e que ela atende aos requisitos estabelecidos.
As auditorias devem ser realizadas mensalmente ou sempre
que as baselines forem liberadas, tais auditorias devem
verificar:
 A presença de todos os itens de configuração especificados
para baseline;
 O atendimento aos requisitos especificados;
 Estrutura de diretório dos repositórios;
 Rótulos dos IC e das baselines;
 IC que compõem as baselines;
 Procedimentos para criação de baselines;
 Procedimentos para fazer modificações em baselines;
 Solicitações de mudanças pendentes;
 Procedimentos de backup.
 Artefatos Ausentes
96
 Requisitos Não Testados
 Requisitos Reprovados
Para realizar uma auditoria funcional, deve-se preparar um
relatório que liste cada requisito estabelecido para a baseline,
seu procedimento de teste correspondente e o resultado do
teste (aprovado/reprovado). O intuito é verificar se cada
requisito passou por um ou mais testes e que o resultado de
todos esses testes foi 'aprovado'. Caso seja detectado que
algum requisito não tenha passado por procedimentos de teste
ou que tenham sido feitos de forma incompleta ou ainda que
foram reprovados, tal fato deve ser documentado no registro de
auditoria.
Ao se verificar desvios nas condutas adotadas, o gerente de GC
deve anotá-los no registro de auditoria de configuração e as
respectivas ações corretivas devem ser identificadas, as
responsabilidades atribuídas e uma data de conclusão
determinada.
Produtos requeridos:
Pl-p2 - Plano de gerência de configuração;
Ac-p1 – Lista de verificação de GC.
Produtos gerados:
Ac-p2 – Relatório de auditoria de configuração1;
NOTA 1: Ver template no anexo F.
Ac-a2
Reportar resultados
Descrição:
O relatório da auditoria deve ser encaminhado aos profissionais
das áreas de gestão e técnica, a fim de que sejam tomadas
providências para corrigir possíveis desvios.
Produtos Requeridos:
Ac-p2 – Relatório de auditoria de configuração2;
Produtos gerados:
Ac-p3 – Registro de envio de relatório.
97
Produtos requeridos e gerados
Id.
Produtos
Descrição
Pl-p2
Plano de gerência
configuração
de Documento que consta as atividades
relacionadas
à
implantação
e
administração do processo de gerência
de configuração.
Pl-p4
Repositório do projeto
Local de armazenamento de todas as
versões de arquivos do projeto.
Ac-p1
Lista de verificação de GC
Documento que orienta a atividade de
auditoria através da listagem de itens a
serem verificados.
Ac-p2
Relatório de auditoria de Documento que registra os desvios
configuração
encontrados, quanto ao processo de
gerência de configuração.
Ac-p3
Registro
relatório
de
envio
de É um registro formal, espécie de
comprovante, do envio de relatório.
Pode ser através de um e-mail ou
outra documentação específica para
esse fim.
Anexo A – Plano de Desenvolvimento de Software1
1
Esse Plano de Desenvolvimento de Software foi adapatado do Rational Unified Process
98
<Nome do Projeto>
Plano de Desenvolvimento de Software
Versão <X>
Histórico da Revisão
Data
Versão
Descrição
Autor
<dd/mmm/aa>
<x.x>
<detalhes>
<nome>
1. Introdução
A introdução do Plano de Desenvolvimento de Software deve fornecer uma
visão geral de todo o documento. Ela deve incluir a finalidade, o escopo, as
definições, os acrônimos, as abreviações, as referências e a visão geral deste
Plano de Desenvolvimento de Software.
1.1 Finalidade
Especifique a finalidade deste Plano de Desenvolvimento de Software.
1.2 Escopo
Uma breve descrição do escopo deste Plano de Desenvolvimento de
Software; a que Projeto(s) ele está associado e tudo o mais que seja afetado
ou influenciado por este documento.
1.3 Definições, Acrônimos e Abreviações
Esta subseção deve fornecer as definições de todos os termos,
acrônimos e abreviações necessárias à adequada interpretação do Plano de
Desenvolvimento de Software. Essas informações podem ser fornecidas
mediante referência ao Glossário do projeto.
1.4 Referências
Esta subseção deve fornecer uma lista completa de todos os
documentos mencionados em qualquer outra parte do Plano de
99
Desenvolvimento de Software. Cada documento deverá ser identificado por
título, número do relatório (se aplicável), data e organização de publicação.
Especifique as fontes a partir das quais as referências podem ser obtidas.
Essas informações podem ser fornecidas mediante referência a um apêndice
ou outro documento.
Para o Plano de Desenvolvimento de Software, a lista de artefatos
mencionados deverá incluir:
 Plano de Gerenciamento de Requisitos
 Plano de Métricas
 Plano de Gerenciamento de Riscos
 Caso de Desenvolvimento
 Guia de Modelagem de Negócios
 Guia de Interface do Usuário
 Guia de Modelagem de Caso de Uso
 Guia de Design
 Guia de Programação
 Guia de Teste
 Manual de Guia de Estilo
 Plano de Infra-estrutura
 Plano de Aceitação do Produto
 Plano de Gerenciamento de Configuração
 Plano de Documentação
 Plano de Garantia de Qualidade
 Plano de Resolução de Problemas
 Plano de Gerenciamento de Subcontratantes
 Plano de Melhoria do Processo
1.5 Visão Geral
Subseção descreve o que o restante do Plano de Desenvolvimento de
Software contém e explica como o documento está organizado.
100
2. Visão Geral do Projeto
2.1 Finalidade, Escopo e Objetivos do Projeto
Uma breve descrição da finalidade e dos objetivos deste projeto e uma
breve descrição dos produtos que se espera que o projeto libere.
2.2 Suposições e Restrições
Uma lista das suposições em que este plano se baseia e de quaisquer
restrições como, por exemplo, de orçamento, equipe, equipamento e
programação, que se aplicam ao projeto.
2.3 Produtos Liberados do Projeto
Uma tabela listando os artefatos a serem criados durante o projeto,
incluindo as datas-alvo de liberação.
2.4 Evolução do Plano de Desenvolvimento de Software
Uma tabela das versões propostas do Plano de Desenvolvimento de
Software e os critérios para a revisão não programada e a republicação deste
plano.
3. Organização do Projeto
3.1 Estrutura Organizacional
Descreva a estrutura organizacional da equipe do projeto, incluindo as
autoridades de gerenciamento e outras autoridades de revisão.
3.2 Interfaces Externas
Descreva como o projeto se relaciona com grupos externos. Para cada
grupo externo, identifique os nomes de contato internos e externos.
3.3 Papéis e Responsabilidades
Identifique as unidades organizacionais do projeto que serão
responsáveis por cada uma das disciplinas, detalhamentos do fluxo de trabalho
e processos de suporte.
4. Processo de Gerenciamento
4.1 Estimativas do Projeto
Forneça a programação e o custo estimado do projeto, assim como a base
dessas estimativas, e os pontos e circunstâncias do projeto em que serão feitas
novas estimativas.
4.2 Plano do Projeto
101
4.2.1 Plano de Fase
Inclua o seguinte:
 Estrutura de Divisão de Trabalho
 Uma linha de tempo mostrando a alocação do tempo para
as iterações ou fases do projeto
 Identifique os principais marcos com seus critérios de
realização
 Defina todas as demonstrações e pontos de release
importantes
4.2.2 Objetivos da Iteração/Etapa
Liste os objetivos a serem atingidos para cada uma das
iterações/etapas.
4.2.3 Releases
Uma breve descrição de cada release de software e se é uma
versão beta, de demonstração etc.
4.2.4 Programação do Projeto
Diagramas ou tabelas mostrando as datas-alvo para a
conclusão das iterações/etapas e fases, dos pontos de release, das
demonstrações e de outros marcos.
4.2.5 Recursos do Projeto
4.2.5.1 Plano de Formação de Equipe
Identifique aqui quantas pessoas serão necessárias e o tipo de
equipe, incluindo quaisquer experiências ou habilidades especiais,
definindo uma programação por fase ou iteração/etapa do projeto.
4.2.5.2 Plano de Aquisição de Recursos
Descreva como você pretende localizar e selecionar as
pessoas para integrarem a equipe necessária ao projeto.
4.2.5.3 Plano de Treinamento
Liste quaisquer treinamentos especiais necessários aos
integrantes da equipe do projeto, com as datas-alvo identificando
quando os treinamentos deverão ser concluídos.
4.2.6 Orçamento
Efetue a alocação de custos em relação à WBS e ao Plano de
Fase.
102
4.3 Planos de Iteração/etapa2
Cada plano de iteração será incluído nesta seção através de referências.
4.4 Controle e Monitoramento do Projeto
4.4.1 Plano de Gerenciamento de Requisitos
Incluído através de referência.
4.4.2Plano de Controle de Programação
Descreva o método a ser adotado para monitorar o progresso em
relação à programação elaborada e como executar ações corretivas quando
necessário.
4.4.3 Plano de Controle de Orçamento
Descreva o método a ser adotado para monitorar os gastos em relação
ao orçamento do projeto e como executar ações corretivas quando necessário.
4.4.4 Plano de Controle de Qualidade
Descreva o andamento e os métodos a serem usados para controlar a
qualidade dos produtos liberados do projeto e como executar ações corretivas
quando necessário.
4.4.5 Plano de Elaboração de Relatórios
Descreva os relatórios internos e externos a serem gerados, e a
freqüência e distribuição de publicação.
4.4.6 Plano de Métricas
Incluído através de referência.
4.4.7 Plano de Gerenciamento de Riscos
Incluído através de referência.
4.6.8 Plano de Encerramento
Descreva as atividades necessárias para que o projeto seja concluído
de forma organizada, incluindo a nova designação da equipe, o arquivamento
de materiais do projeto, interrogações e relatórios.
5. Planos de Processos Técnicos
5.1 Caso de Desenvolvimento
Incluído através de referência.
2
Esse tópico só será preenchido no caso de um processo de desenvolvimento iterativo
103
5.2 Métodos, ferramentas e técnicas
Liste os padrões técnicos documentados no projeto etc, através de
referências:
 Guia de Modelagem de Negócios
 Guia de Interface do Usuário
 Guia de Modelagem de Caso de Uso
 Guia de Design
 Guia de Programação
 Guia de Teste
5.3 Plano de Infra-estrutura
Incluído através de referência.
5.4 Plano de Aceitação do Produto
Incluído através de referência.
6. Planos de Processos de Suporte
6.1 Plano de Gerenciamento de Configuração
Incluído através de referência
6.2 Plano de Avaliação
Parte do Plano de Desenvolvimento de Software. Descreve os planos
do projeto para a avaliação do produto e aborda as técnicas, os critérios, as
métricas e os procedimentos usados para avaliação - entre eles estarão
incluídas inspeções técnicas, inspeções e revisões. Observe que esses
procedimentos são um complemento do Plano de Teste, que não está incluído
no Plano de Desenvolvimento de Software.
6.3 Plano de Documentação
Incluído através de referência.
6.4 Plano de Garantia de Qualidade
Incluído através de referência.
6.5 Plano de Resolução de Problemas
Incluído através de referência.
6.6 Plano de Gerenciamento de Subcontratantes
Incluído através de referência.
6.7 Plano de Melhoria do Processo
Incluído através de referência
104
7. Planos Adicionais
Planos adicionais se forem necessários devido a contratos ou regulamentos.
8. Anexos
Material adicional.
105
Anexo B – Plano de Gerência de Configuração3
<Nome do Projeto>
Plano de Gerência de Configuração
Versão <X>
Histórico da Revisão
Data
Versão
Descrição
Autor
<dd/mmm/aa>
<x.x>
<detalhes>
<nome>
1. Introdução
A introdução do Plano de Gerenciamento de Configuração oferece uma visão
geral de todo o documento. Ela inclui a finalidade, o escopo, as definições, os
acrônimos, as abreviações, as referências e uma visão geral deste Plano de
Gerenciamento de Configuração.
1.1 Finalidade
Especifique a
Configuração.
1.2 Escopo
finalidade
deste
Plano
de
Gerenciamento
de
Uma breve descrição do escopo deste Plano de Gerenciamento de
Configuração; o modelo ao qual ele está associado e tudo o que é afetado ou
influenciado por este documento.
3
Esse Plano de Gerência de Configuração foi adaptado do Rational Unified Process
106
1.3 Definições, Acrônimos e Abreviações
Esta subseção apresenta as definições de todos os termos, acrônimos
e abreviações necessários para a correta interpretação do Plano de
Gerenciamento de Configuração. Essas informações podem ser fornecidas
mediante referência ao Glossário do projeto.
1.4 Referências
Esta subseção apresenta uma lista completa de todos os documentos
mencionados no Plano de Gerenciamento de Configuração. Identifique os
documentos por título, número de relatório (se aplicável), data e organização
responsável pela publicação. Especifique as fontes a partir das quais as
referências podem ser obtidas. Essas informações podem ser fornecidas por um
anexo ou outro documento.
1.5 Visão Geral
Esta subseção descreve o conteúdo restante do Plano de
Gerenciamento de Configuração e explica como o documento está organizado.
2. Gerenciamento de Configuração de Software
2.1 Organização, Responsabilidades e Interfaces
Descreva quem será o responsável pela execução das diversas
atividades de Gerenciamento de Configuração (GC).
2.2 Ferramentas, Ambiente e Infra-estrutura
Descreva o ambiente de computação e as ferramentas de software a
serem utilizadas para desempenhar as funções de GC em todo o ciclo de vida
do projeto ou produto.
Descreva as ferramentas e os procedimentos necessários utilizados
para o controle de versão dos itens de configuração gerados no ciclo de vida do
projeto ou produto.
3. O Programa de Gerenciamento de Configuração
3.1 Identificação da Configuração
3.1.1 Métodos de Identificação
Descreva como os artefatos do projeto ou produto devem ser
nomeados. O esquema de identificação deve abranger o hardware, o software
do sistema, os produtos de terceiros e todos os artefatos de desenvolvimento de
107
aplicativos listados na estrutura de diretórios do produto; por exemplo, planos,
modelos, componentes, software de teste, resultados e dados, executáveis, etc.
3.1.2 Baselines do Projeto
As baselines funcionam como um padrão oficial no qual os trabalhos
subseqüentes são baseados. Somente mudanças autorizadas podem ser
efetuadas nas baselines.
Descreva em que pontos do ciclo de vida do projeto ou produto as
baselines devem ser estabelecidas. As baselines mais comuns devem ser
definidas ao final de cada uma das fases de desenvolvimento. Elas também
podem ser geradas no final de iterações/etapas ocorridas dentro das várias
fases ou com freqüência ainda maior.
Descreva quem autoriza uma baseline e o que ela contém.
3.2 Controle de Configuração e Mudança
3.2.1 Processamento e Aprovação de Solicitações de Mudança
Descreva o processo pelo qual os problemas e as mudanças são
submetidos, revisados e dispostos.
3.2.2 Comitê de Controle de Mudança (CCM)
Descreva a participação e os procedimentos para
solicitações e aprovações de mudança a serem seguidos pelo CCM.
processar
3.3 Estimativa do Status de Configuração
3.3.1 Processo de Armazenamento de Mídia e Liberação do Projeto
Descreva as políticas de retenção e os planos de backup, erros
irreversíveis e recuperação. Descreva também como a mídia deve ser mantida on-line, off-line, tipo de mídia e formato.
O processo de liberação deve descrever o conteúdo do release, a
quem ele se destina e se há quaisquer problemas conhecidos e instruções de
instalação.
3.3.2 Relatórios e Auditorias
Descreva o conteúdo, o formato e a finalidade dos relatórios e
auditorias de configuração solicitados.
Os relatórios são usados para avaliar a "qualidade do produto" em
qualquer fase do ciclo de vida do projeto ou produto. Os relatórios sobre defeitos
com base em solicitações de mudança podem fornecer alguns indicadores de
qualidade proveitosos e, dessa forma, alertar a administração e os
desenvolvedores para determinadas áreas prioritárias do desenvolvimento.
108
4. Marcos
Identifique os marcos internos e de cliente relacionados ao esforço de GC do
projeto ou produto. Esta seção deve incluir detalhes sobre quando o Plano GC
deve ser atualizado.
5. Treinamento e Recursos
Descreva as ferramentas de software, o pessoal e o treinamento necessários
para implementar as atividades de GC especificadas.
6. Controle de Software de Subcontratados e Fornecedores
Descreva de que forma o software desenvolvido fora do ambiente do projeto
será incorporado.
108
Anexo C – Planilha de Controle de criação baseline
<Nome do Projeto>
Planilha de Controle de baseline
Nº
Data
Fase/Iteração
Nº
Evidência
Itens de Configuração
Nome da CB
Número
Inserir a data
Inserir
Número da
Fase/Iteração
Informe a
Caso a baseline seja
Preencher o nome
seqüencial
da criação da
Fase/iteração do
Iteração/Fase
evidência da
composta por mais de um
da baseline de
baseline
ciclo de vida
geração da
IC, relacionar um de cada
acordo com as
baseline
vez.
políticas de GC
109
Anexo D – Planilha de Acompanhamento de Mudanças
<Nome do Projeto>
Planilha de acompanhamento de Mudanças
Identificação da Baseline
Nº RCM
*Aberta/Análise/Aprovada/Reprovada/Atribuída/Em testes/Encerrada
Data
Situação*
110
Anexo E – Relatório de Controle de Mudanças
<Nome do Projeto>
Relatório de controle de Mudanças
Versão <X>
1. Identificação
Informar o número do RCM (seqüencial)
Nº do RCM
Data de abertura do RCM
Informar a data de abertura do RCM
<dd/mm/aaaa>
Projeto
Descrever a sigla e o nome do projeto
Cliente
Descrever o nome do Cliente
Solicitante
da
Mudança Descrever o nome e a área do Solicitante
(Nome/Área)
da Mudança
2. Descrição da mudança
Descreva detalhadamente a solicitação da mudança, enfatize os motivos,
condições, restrições e premissas para a implementação das mudanças, bem
como os requisitos que estão sendo modificados.
3. Análise de impacto
Descrever aqui o resultado da análise do impacto da mudança, seja de escopo
do projeto ou de produto.
3.1 Nos Requisitos
Tipo da Mudança
Requisito Afetado
Tamanho
Informar(*)
o tipo da Informar
o
requisito Informar o tamanho em Pontos
mudança
afetado.
por Função (PF) do requisito
afetado.
(*) I – Inclusão; E – Exclusão; A – Alteração.
111
3.2 Nos Produtos
Nome do Produto Afetado pela Mudança (IC)
Descreva neste campo qual o produto e/ou componente afetado com a
mudança
IC – Item de Configuração
3.3 Nos Prazos
Informar qual fase/iteração foi afetada e em quantos dias foi afetado.
3.4 Outros Impactos
Informar outros impactos como, mudança de recursos, treinamento, qualidade,
etc.
4. Estimativa de Esforço
Informar no quadro abaixo o perfil profissional que será envolvido na mudança,
o esforço em horas.
Esforço – em horas
Perfil
Gerência
Análise
Implementação
5. Aprovação
Informar apenas os papéis envolvidos na aprovação
Papel
Nome
Gerente de Projetos
Gerente do Projeto
Gerente de GC
Analista de GC do
Cliente
projeto
Outros
do CCM
integrantes
Assinaturas
Data
112
6. Justificativa
Caso o CCM não aprove a mudança deve informar aqui a justificativa da
decisão.
7. Anexos
Mantenha neste item todos e-mails, documentações, etc que caracterizem a
solicitação da mudança.
113
Anexo F – Registro de Auditoria
<Nome do Projeto>
Registro de Auditoria
Identificação
Data da auditoria
Auditor(es)
Tipo de Auditoria:
1. Auditoria física
2. Auditoria funcional
3. Auditoria de procedimentos
Identificação da(s) baseline(s)
1. Lista de Verificação de GC
Inserir a referência à lista de verificação utilizada na auditoria.
2. Registro de Desvios de GC
Nº Desvio Ação
01
Tipo Desvio
Responsável Data
Corretiva Processo/Produto pelo
02
Situação*
Limite
Tratamento
03
04
(*) Opções de Situação: Novo, Encaminhado, Suspenso, Parado.
3. Registro de oportunidades de melhorias
Nº
Oportunidade
Tipo
01
de melhoria
melhoria
de Responsável
02
(*) Opções de Situação: Nova ou Pendente.
pelo
Tratamento
Data
Limite
Situação*
114
Referência Bibliográfica
ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE
BRASILEIRO. MPS-BR Guia Geral V1.2.[São Paulo] 2007. 52 p.
CAMPOS, Fábio Bianchi. Notas de Aula. Mensagem recebida por
<[email protected]> em 05 de jun. 2007.
COSTA, Claudio Giulliano Alves da; QUARESMA, Rodrigo Paulo; SABBATINI,
Renato Marcos Endrizzi. Uma Revisão sobre Engenharia de Software e sua
Utilização no Desenvolvimento de Sistemas de Prontuário Eletrônico de
Pacientes. Disponível em:
<http://www.medsolution.com.br/claudio/esepep.htm>. Acesso em: 15 jul. 2007.
INSTITUTO DE ENGENHARIA DE SOFTWARE. CMMI-SE/SW V1.1
Guidelines for Process Integration and Product Improvement. S.l. 2006.
551 p.
KOSCIANSKI, André, SOARES Michel dos Santos. – Qualidade de software:
aprenda as metodologias e técnicas mais modernas para o
desenvolvimento de software. – 2 ed. São Paulo: Novatec editora, 2007.
MOLINARI Leonardo. – Gerência de configuração: técnicas e práticas no
desenvolvimento do software. – Florianópolis: Visual Books, 2007.
PRESSMAN, Roger S. – Engenharia de software. São Paulo: Pearson
education do Brasil, 1995.
______ . ______. 5.ed. – Rio de Janeiro: McGraw-Hill, 2002.
ROCHA, Ana Regina Cavalcanti da, MALDONADO José Carlos e WEBER
Kival Chaves. – Qualidade de software. – São Paulo: Prentice Hall, 2001.
SOMMERVILLE, Ian. – Engenharia de software; Tradução André Maurício de
Andrade Ribeiro; revisão técnica Kechi Hirama. – São Paulo: Addison Wesley,
2003.
WIKIPÉDIA (Brasil). Qualidade de Sofware. Disponível em:
<WWW.WIKIPEDIA.ORG.BR>. Acesso em: 20 jun. 2007.
______. Software. Disponível em: <WWW.WIKIPEDIA.ORG.BR>. Acesso em:
03 jul. 2007.
JOMORI, Sergio Massao; DELLA VOLPE, Renato Luiz; ZABEU, Ana Cecília
Peixoto. CMM - CMMI Principais conceitos, diferenças e correlações.
115
Disponível em: <http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf>.
Acesso em: 30 jul. 2007.
MACHADO, Marcio P.; SOUZA, Sotério F..- Métricas e Qualidade de
Software. Disponível em: <http://fattocs.com.br/download/qualidade-sw.pdf>.
Acesso em: 04 jul. 2007.
TSUKUMO, Alfredo N. et al. Qualidade de Software: Visões de Produto e
Processo de software. In: II ERI da SBC, 1997, São Paulo.
Anais... São Paulo: CTI, 1997p. 173-189.
Disponível em:
<http://www.prodepa.psi.br/sqp/pdf/Qualidade%20de%20Software.pdf>.
Acesso em: 18 jul. 2007.
MURTA, Leonardo Gresta Paulino. – Gerência de Configuração no
Desenvolvimento Baseado em Componentes. [Rio de Janeiro] 2006,
213 p. Tese (Engenharia de Sistemas e Computação) – Universidade Federal
do Rio de Janeiro, 2006.
Disponível em: http://reuse.cos.ufrj.br/prometeus/publicacoes/odyssey-scm.pdf.
Acesso em: 10 ago.2007.