Template para a cria��o de documentos da f�brica USina

Document Sample
Template para a cria��o de documentos da f�brica USina Powered By Docstoc
					Modelo para documento de plano de gerência de
configuração de software

Objetivo:     Este documento é um modelo genérico para a criação do plano de
gerência de configuração de software a ser usado nos projetos da fábrica de
software.

Informações gerais de uso:
   1. Para alterar os campos de autotexto, como o nome do documento, a versão
      ou a data, deve-se usar a opção “Arquivo->Propriedades-> Personalizar ”.
      Nesta pasta estão as variáveis utilizadas pelo Word. Nela os valores dos
      campos podem ser editados e após realizar a edição é só clicar com o botão
      direito do mouse sobre o autotexto desejado e clicar na opção “Atualizar
      campo”. Após este procedimento o campo será atualizado para o valor
      desejado;
   2. Os corpos dos textos devem usar formatação “Normal”;


                Histórico de revisões do modelo
Versão     Data                Autor      Descrição                      Localização
(XX.YY)    (DD/MMM/YYYY)
00.01                          jmpv       Draft inicial
           30/MAR/2004
           31/MAR/2004         mscab      Atualização do draft inicial
00.02
00.03      06/ABR/2004         jmpv       Adicionado novo logo da
                                          fábrica,            pequenas
                                          modificações    no    modelo
                                          baseado nas sugestões de
                                          Márcia.
00.04      13/ABR/004          aa         Formatação do doc. e revisão
                                          para fechar uma versão.
01.00      18/ABR/2004         aa, tlvls, Versão final
                               prpa
02.00      26/MAI/2004         aa         Ajustes no doc.
02.01      26/MAI/2004         jmpv       Ajustes      no   documento,   www/artifac
                                          seguindo experiências do       ts/template
                                          projeto piloto                 s/
03.00      31/MAI/2004         jmpv       Versão final                   www/artifac
                                                                         ts/template
                                                                         s/

                               Aprovadores
Paulo Rogério            Gerente de Projeto


João Marcos              Gerente de Configuração
Márcia Seabra      Engenheira de Qualidade e Processo


Antônio Campello   Analista de Negócios


Alexandre Alvaro   Arquiteto de Software
             USINA


      <Nome do Projeto>
    Plano de Gerência de
Configuração de Software


                   Versão:<Versão XX.YY>
                     Data:<dia Mês, ano>
 Identificador do documento:SCMP
             Modelo usado:03.00
               Localização:<caminho de acesso no CVS ou URL>




            <Tipo do copyright>
USINA
Plano de Gerência de Configuração de Software                  <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>


                            Histórico de revisões
Versão     Data                  Autor                         Descrição    Localização
(XX.YY)    (DD/MMM/YYYY)




7135f7c1-8e4e-46c8-9a8d-                 <Tipo do copyright>                     Página 4 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                                                               <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>


                                                                      Índice
ÍNDICE DE FIGURAS ................................................................................................................................ 6
ÍNDICE DE TABELAS ............................................................................................................................... 7
1.      INTRODUÇÃO.................................................................................................................................... 8
     1.1.       PROPÓSITO ..................................................................................................................................... 8
     1.2.       PÚBLICO ALVO .............................................................................................................................. 8
     1.3.       ESCOPO .......................................................................................................................................... 8
     1.4.       DEFINIÇÕES, ACRÔNIMOS E ABREVIAÇÕES.................................................................................... 8
     1.5.       REFERÊNCIAS ................................................................................................................................ 8
     1.6.       VISÃO GERAL DO DOCUMENTO ...................................................................................................... 8
2.      ATIVIDADES ...................................................................................................................................... 9
     2.1.     NOMENCLATURA E IDENTIFICAÇÃO ............................................................................................... 9
        2.1.1.    Identificador de Documento (Doc ID) ................................................................................. 9
        2.1.2.    Número de versão................................................................................................................10
        2.1.3.    Local de armazenamento ....................................................................................................10
        2.1.4.    Baselines de projeto ............................................................................................................11
        2.1.5.    Política de uso de branches.................................................................................................12
        2.1.6.    Política de uso de branches para documentos ....................................................................13
     2.2.     CONTROLE DE CONFIGURAÇÃO ....................................................................................................13
        2.2.1.    Core teams ..........................................................................................................................13
        2.2.2.    Solicitação de mudanças .....................................................................................................13
     2.3.     CONTRIBUIÇÕES EXTERNAS ..........................................................................................................13
     2.4.     AUDITORIA DE CONFIGURAÇÃO ....................................................................................................14
     2.5.     RELATÓRIOS DE CONFIGURAÇÃO ..................................................................................................14
3.      PLANO DE CONTINGÊNCIA .........................................................................................................15
4.      PROCEDIMENTOS...........................................................................................................................16




7135f7c1-8e4e-46c8-9a8d-                                         <Tipo do copyright>                                                        Página 5 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                                            <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>



                                          Índice de Figuras
FIGURA 2-1 ESTRUTURA DE DIRETÓRIOS DO CVS ..........................................................................................11




7135f7c1-8e4e-46c8-9a8d-                              <Tipo do copyright>                                          Página 6 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                                                    <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>



                                              Índice de Tabelas
TABELA 2-1 TIPOS DE ARTEFATOS .................................................................................................................. 9
TABELA 2-2 DETALHAMENTO DAS PASTAS DO CVS ......................................................................................11
TABELA 2-3 BASELINES DE PROJETO ..............................................................................................................12
TABELA 2-4 MEMBROS DO CORE TEAM DE SCM ...........................................................................................13




7135f7c1-8e4e-46c8-9a8d-                                   <Tipo do copyright>                                               Página 7 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                 <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>



1. Introdução

1.1. Propósito
Este documento apresenta os processos necessários para gerenciar as mudanças no
projeto, provendo assim uma infra-estrutura necessária para a evolução do projeto.

1.2. Público Alvo
Os interessando diretamente nesse documento são todas as pessoas envolvidas no
projeto, em especial, aqueles envolvidos nas atividades de engenharia do projeto
(principalmente programação).

1.3. Escopo
Neste documento esta detalhada toda a infra-estrutura que será utilizada durante o
projeto.

1.4. Definições, Acrônimos e Abreviações.
<Nesta seção serão descritos as abreviações, definições e acrônimos relevantes ao
documento em ordem alfabética. Segue uma lista de definições, acrônimos e
abreviações usados neste documento.>

CVS       Control Version System. Abreviatura genérica para sistemas de controle de
          versão (configuração) de software.
SCMP      Software Configuration Management Plan (Plano de gerência de configuração
          de software)

1.5. Referências
Segue a lista de referencias deste documento.
[1]      WinCVS – official website, www.wincvs.org, acesso em março/2004.
[2]      Documento de Processo da USINA, Versão <01.00>. Localização:
      <localização>.
[3]      Relatório de Auditória do Projeto, Versão <01.00>. Localização:
      <localização>.

1.6. Visão geral do documento
O presente documento está estruturado assim:
    Seção 2: apresenta o ambiente no qual o projeto estará inserido, as
       atividades a serem realizadas pelo plano de gerência de configuração;
    Seção 3: apresenta um plano de contingência visando superar alguns
       problemas que podem surgir durante o projeto, como indisponibilidade de
       acesso ao ambiente do projeto e perda de dados; e
    Seção 4: apresenta os procedimentos de gerência de configuração.




7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                     Página 8 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                     <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>



2. Atividades
Nesta seção serão apresentadas algumas atividades a serem seguidas pelos
colaboradores do <Nome do Projeto>.

2.1. Nomenclatura e identificação

2.1.1.          Identificador de Documento (Doc ID)
<Defina um esquema de nomenclatura de documentos próprio para o projeto, ou
aceite o esquema descrito nesta seção>
Todos os itens de configuração do projeto, com exceção do código fonte, devem
possuir um identificador de documento (doc_id). Os doc_ids devem seguir o seguinte
esquema de nomenclatura:
         <nome_projeto>_<tipo_artefato>_<data_da_criação>[_<descrição>]
Onde:
<nome_projeto>           Nome do projeto em letras maiúsculas;
<tipo_artefato>          tipo do artefato, conforme apresentado na Tabela 2-1;
<data_da_criação> momento da criação do arquivo no formato AAAAMMDD;
<descrição>          breve descrição do arquivo, pode ser o título do documento.
Esta descrição só pode conter caracteres maiúsculos e não acentuados (A-Z),
números (0-9), hífen (-) e sublinhado (_).
Notas:
        Idealmente não deve ultrapassar 50 caracteres.
        Este campo é opcional, caso seja omitido, a identificação do arquivo termina
         no último dígito da data da criação.
        Para artefatos únicos de um projeto, como os planos, a descrição pode ser
         omitida, no caso de artefatos passíveis de ter várias instancias, como
         relatórios, por exemplo, então é necessário o preenchimento deste campo.


     Artefato                                                       tipo _artefato
     Plano de Gerência de Projeto de Software                         SPMP
     Plano de Gerência de Configuração de Software                    SCMP
     Plano de Garantia da Qualidade de Software                       SQAP
     Plano de Testes do Software                                      STP
     Pauta e Ata de Reunião                                           MEET
     Relatórios (status, métricas, auditorias, resultado de testes)   RPT
     Documentos de Arquitetura                                        ARCH
     Artefatos Comerciais                                             MKT
     Documentos de Requisitos                                         REQ
     Documentos de Processo                                           PRC
     Documentos de Testes                                             TST
                                  Tabela 2-1 Tipos de artefatos

7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                         Página 9 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                 <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>

Arquivos de código fonte são identificados pelo seu nome completo, ou seja, o nome
do pacote, seguido por ponto (.) e o nome da classe.



2.1.2.          Número de versão
<defina padrão para versionamento dos artefatos ou aceite a sugestão definida
nessa seção>
Todos os artefatos, excluindo código e relatórios, devem possuir um numero de
versão seguindo o padrão a seguir:
                                                XX.YY
Onde:
XX       Número da versão do documento
YY       Número de rascunho (draft) do documento


A evolução do número de versão segue as seguintes regras:
        A primeira versão do documento deve ser 00.01;
        A cada modificação do documento, o valor YY deve ser incrementado;
        Após cada aprovação do documento, sua versão XX deve ser incrementada
         em um, e o valor YY volta a 00, formando uma “versão cheia” ou oficial;
É considerada uma aprovação do documento: a) Aprovação do documento após uma
revisão; b) Aprovação por pelo menos dois (2) membros do core group responsável
pelo artefato respectivo.

2.1.3.          Local de armazenamento
Esta seção apresenta onde são armazenados os artefatos do projeto <Nome do
Projeto>.
É interessante apresentar tanto uma visão gráfica da estrutura de diretórios (arvore
de diretórios) quanto uma descrição mais detalhada, por exemplo, usando uma
tabela.
Esta seção apresenta onde são armazenados os artefatos do projeto <Nome do
Projeto>.




7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                    Página 10 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                  <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>




                            Figura 2-1 Estrutura de diretórios do CVS
Diretório                  Descrição
                           Contém diretórios para o código fonte, bibliotecas utilizadas e
code
                           scripts de compilação.
 bin                       Arquivos binários e executáveis
 build                     Scripts de compilação (build.xml).
 lib                       Bibliotecas externas utilizadas pelo projeto.
 model                     Modelos UML
 release                   Versões de release do projeto
 src                       O código fonte está localizado nesta pasta ou em sub-pastas.
docs                       A documentação para o projeto está nas sub-pastas de docs
                           Artefatos de design, como modelos UML e descrições da
  design
                           arquitetura do sistema.
                           Documentos de marketing como a proposta comercial,
  marketing
                           resposta ao RFP, e SLA.
  requirements             Documentos de requisito.
  scm                      Documentos de gerência de configuração de software.
  spm                      Documentos de planejamento.
  sqa                      Documentos de garantia de qualidade de software.
                           Documentos de teste para o projeto, incluindo documentos de
  test
                           procedimentos de testes, planos de teste, etc.
reports                    Relatórios do projeto
  audit                    Relatórios de auditoria do projeto
  test                     Relatórios de teste do projeto
                         Tabela 2-2 Detalhamento das pastas do CVS

2.1.4.          Baselines de projeto
<use essa seção para descrever que baselines serão gerados no projeto>
Os baselines de projeto são descritos na Tabela 2-3.

7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                     Página 11 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                  <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>

Baseline        Descrição                                 Formato

                                 Tabela 2-3 Baselines de projeto

2.1.5.          Política de uso de branches
<Defina nessa seção a política para uso de branches, ou aceite a política descrita nas
sub-seções a seguir>


2.1.5.1.        Branch principal (main)
É o branch principal do projeto. Apenas versões baselined devem ser integradas a
este branch, isso garante que este branch conterá um código testado e funcional ou
documentos revisados e aprovados.


2.1.5.2.        Branch de integração
Os branches de integração são utilizados para integrar um conjunto de mudanças
antes de integrá-las ao branch principal. Um conjunto extensivo de testes deve ser
realizado antes desta integração, assim, o branch principal conterá apenas código já
testado, e documentos revisados.
O label de um branch de integração segue o seguinte padrão:
                                <nome_projeto>_int_<build>
Onde:
<nome_projeto>           Nome do projeto em letras maiúsculas;
<build>         Número da build.


2.1.5.3.        Branch de desenvolvimento
É neste branch onde todos os desenvolvimentos devem ser feitos. Ele deve ser
sempre criado a partir de um baseline de release (branch principal).
Antes de integrar o código de um branch de desenvolvimento no branch de
integração, o engenheiro deve garantir que o código esteja atualizado com o ultimo
baseline e então testar novamente a modificação para garantir que continua
funcionando.
                      <nome_projeto>_dev_<issue_id>_<descrição>
Onde:
<nome_projeto>           Nome do projeto em letras maiúsculas;
<issue_id>               Identificador da issue sendo resolvida neste branch;
<descrição>              Breve descrição sobre as mudanças feitas.
Patches, vindos de colaboradores externos, devem ser inserido em seus próprios
branches de desenvolvimento, e então integradas em branches de integração.



7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                     Página 12 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                 <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>


2.1.6.          Política de uso de branches para documentos
<Defina nessa seção a política para uso de branches em documentos, ou aceite a
política descrita nas sub-seções a seguir. Esta seção é opcional uma vez que a
política pode ser a mesma que acima.>
Documentos não utilizaram branches. Antes de criar uma nova versão é preciso fazer
um check out no documento e um lock (travamento), para impedir o trabalho
paralelo no documentos.

2.2. Controle de Configuração
2.2.1.          Core teams
Cada projeto deve ter um core team definido para cada papel. Estes grupos decidirão
a necessidade e urgência da implementação de solicitações de mudanças. A
formação destes core teams estão descritas no processo de desenvolvimento de
software [2].
A formação do Core Team de gerência de configuração de software é mostrado na
Tabela 2-4.
Nome                                            e-mail para contato



                           Tabela 2-4 Membros do Core Team de SCM

2.2.2.          Solicitação de mudanças
Mudanças nos itens de configuração do projeto devem estar sempre associadas a
solicitações de mudanças. Esta é a força motriz por trás do processo.


2.2.2.1.        Preenchendo uma solicitação de mudanças
Solicitações de mudanças devem ser utilizadas por um gerenciador de mudanças
(i.e: bugzilla, issue tracker). Devem ser aprovadas pelo core team responsável pelo
artefato em questão.
<esta seção deve descrever como preencher os dados de uma solicitação de
mudança na ferramenta usada no projeto.>


2.2.2.2.        Estados de uma solicitação de mudança
<descreva estados de uma solicitação de mudança>


2.2.2.3.        Ciclo de vida de uma solicitação de mudança
<descreva ciclo de vida de uma solicitação de mudança>

2.3. Contribuições externas
<descreva como as contribuições externas devem ser feitas, como são aceitas, etc.>




7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                    Página 13 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                 <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>


2.4. Auditoria de configuração
Auditorias devem ser realizadas para cada ciclo do processo de desenvolvimento de
forma a assegurar que os processos de gerência de configuração estão sendo
seguidos e devem ser reportados no relatório de auditoria de artefatos do projeto [3]

2.5. Relatórios de configuração
A cada release deve ser gerado um documento de release notes, contendo quais são
as modificações adicionadas àquela versão (incluindo o número do bug), além de
informação útil para os usuários.




7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                    Página 14 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                 <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>



3. Plano de Contingência
<descreva o plano de contingência>




7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                    Página 15 de 16
b7c1f8b0ba85.doc
USINA
Plano de Gerência de Configuração de Software                 <Versão XX.YY>, <dia Mês, ano>
<Nome do Projeto>



4. Procedimentos
Esta seção descreve alguns procedimentos de gerência de configuração para o
projeto.




7135f7c1-8e4e-46c8-9a8d-                <Tipo do copyright>                    Página 16 de 16
b7c1f8b0ba85.doc

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:11/26/2011
language:Portuguese
pages:16