Atividade:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: As práticas de CM descritas nesta atividade precisam ser estabelecidas no início da fase de elaboração, após a aprovação do projeto, e retomadas no ciclo de vida do projeto, no início das fases de construção e de transição. | |
| Papel: Gerente de Configuração | |
Mentores de Ferramentas:
|
|
| Detalhamentos do Fluxo de Trabalho: |
Finalidade
|
| Mentor de Ferramentas: Criação de Baselines Usando o Rational ClearCase |
A identificação da configuração é uma parte essencial do gerenciamento de configuração e é definida pelo IEEE como "um elemento do gerenciamento de configuração que consiste em selecionar os itens de configuração para um sistema e registrar suas características físicas e funcionais na documentação técnica". Em termos de gerenciamento de configuração de software, a identificação da configuração significa ser capaz de localizar e identificar rápida e facilmente a versão correta de qualquer artefato de projeto. O impacto negativo de um sistema de identificação de configuração ineficaz é avaliado em termos de perda de tempo e qualidade.
Os rótulos identificam versões específicas de artefatos. O conjunto de artefatos que constitui a versão de um subsistema é coletiva e individualmente identificável por uma determinada versão e rótulo. Os rótulos são, portanto, úteis na reutilização ou referência a conjuntos originais de artefatos com controle de versão.
A seguir, é sugerida uma convenção de rotulamento de artefato do produto que pode ser usada para rotular caminhos e artefatos na Estrutura de Diretórios do Produto.
<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]
<SYSTEM> Identifica o sistema
<A> significa o acrônimo de três letras (TLA) dos vários tipos de artefatos utilizados na criação do sistema. Por exemplo,
PLN Planos do Projeto REQ Campos de Requisitos USC Casos de Uso MOD Arquivos de Modelo SRC Arquivos de Código-Fonte INT Interfaces Públicas TST Scripts e Resultados de Teste DOC Documentação (Notas de Release, do Usuário) BIN Executáveis
<SUBSYSTEM> Identifica cada subsistema
<A> significa o acrônimo de três letras dos vários tipos de artefatos utilizados na criação do subsistema. De acordo com a tabela acima.
R|A|B Significa release, alfa ou beta <X> Inteiro, significa um release principal (por exemplo, 1) <Y> Inteiro (opcional), significa um release secundário <Z> Inteiro (opcional), significa um release alternativo (patches, portas etc.) BL Significa nível base (um release interno) # Inteiro, para releases internos
A seguir, são apresentados alguns exemplos:
| T2K_R1.0 | Release 1 do sistema Thorn 2000 |
| T2K_GUI_R2.0.BL5 | Release interno do sistema da GUI destinado à liberação no release 2 |
| T2K_B1.1 | Release beta 1.1 do sistema Thorn 2000 |
| T2K_R2.0.BL16 | Baseline de sistema interna 16 do Thorn 2000 destinada à criação do release 2 |
| T2K_R1.0.5 | Release de manutenção do Thorn 2000 |
Uma baseline oferece um ponto estável e uma imagem dos artefatos de projeto. Conceitos: Criação de uma Baseline descreve em que momento do ciclo de vida do projeto as baselines precisam ser criadas. Este passo fornece orientação adicional sobre a prática.
As baselines identificam conjuntos fixos de controles de versão de diretórios e de arquivos, e são criadas em marcos de projeto específicos. Elas podem ser criadas para um subsistema ou para todo o sistema. As baselines devem ser identificadas de acordo com o esquema descrito na etapa anterior (Definir a Convenção de Rotulamento de Artefato).
Uma diferença que precisa ser especificada no momento da criação de uma baseline é se você estará criando:
ou
Geralmente, facilitaria o gerenciamento do release criar Baselines de Sistema nos marcos de projeto principais e secundários, e Baselines de Subsistema quando necessário ou em uma freqüência maior. Como regra geral, uma boa idéia é criar uma baseline se, no máximo, 30% dos componentes de um subsistema foram modificados.
A finalidade deste passo é assegurar que o software do projeto e os ativos relacionados (documentos mestre) foram submetidos a backup, catalogados e transferidos para locais de armazenamento designados. Os arquivos mostram o seu valor quando é necessária alguma reutilização ou quando acontecem desastres. Os arquivos precisam ser criados regularmente e nos marcos principais e secundários.
As diretrizes de rotulamento descritas anteriormente no passo 'Definir a Convenção de Rotulamento de Artefato' podem ser usadas durante a criação dos rótulos de arquivamento. No entanto, informações adicionais sobre o local onde a mídia real será armazenada podem ser necessárias. Por exemplo:
| NÚMERO DE SÉRIE | 123456789 |
| VOLUME | 1 de 3 |
| VAULT | B5 |
| DATA DO ARMAZENAMENTO | 21 de junho de 1999 |
Todas as informações relacionadas devem ser mantidas em um banco de dados para facilitar o release e a reutilização.
Finalidade
|
| Subpassos: |
| Mentores de Ferramentas: |
Conceitos: Relatório de Status de Configuração descreve as várias fontes de criação dos Relatórios de Status de Configuração.
Aqui, você deve selecionar relatórios que podem ser derivados das Solicitações de Mudança realizadas no projeto. Existem várias Solicitações de Mudança úteis baseadas em relatórios.
Na categoria 'vencimento', os relatórios podem ser solicitados em termos de número de Solicitações de Mudança em períodos semanais ou mensais, de acordo com os seguintes critérios:
A listagem de problemas por estado pode ajudar a determinar se o projeto está ou não perto de terminar. Por exemplo, se a maior parte dos problemas foi resolvida, isso significa que a conclusão do projeto está mais próxima do que se os problemas estivessem no estado 'enviado'.
Na categoria 'distribuição', os relatórios podem ser solicitados para responder aos seguintes tipos de perguntas:
Essas métricas podem ajudar a analisar a carga de trabalho, quem está trabalhando nos problemas mais críticos e com que rapidez os problemas estão sendo solucionados.
Na categoria 'tendência', os relatórios podem ser solicitados para responder aos seguintes tipos de perguntas:
Esses dados são úteis durante a avaliação de taxas de reparo e podem fornecer indicações da eficiência do pessoal da engenharia.
Assegure-se de que os relatórios são recebidos na freqüência correta a fim de que uma contribuição significativa seja fornecida para a tomada de decisões. Os relatórios podem ser solicitados na seguinte freqüência
|
Rational Unified Process
|
