CMM. Práticas de Gerência de Configuração

Transcrição

1 REGINALDO PEREIRA DE SOUZA CMM Práticas de Gerência de Configuração Universidade São Francisco Itatiba 2004

2 ii REGINALDO PEREIRA DE SOUZA CMM Práticas de Gerência de Configuração Pesquisa desenvolvida sob orientação do professor Adalberto Nobiato Crespo para obtenção do título de graduação do curso de Análise de Sistemas da USF - Itatiba Universidade São Francisco Itatiba 2004

3 iii CMM Práticas de Gerência de Configuração REGINALDO PEREIRA DE SOUZA Monografia defendida e aprovada em 06 de dezembro de 2004 pela Banca Examinadora assim constituída: Prof. Adalberto Nobiato Crespo (Orientador) USF Universidade São Francisco Itatiba SP. Prof. Alencar de Melo Júnior (Membro Interno) USF Universidade São Francisco Itatiba SP. Prof. Rodrigo Prado (Membro Interno) USF Universidade São Francisco Itatiba SP.

4 iv RESUMO Esta pesquisa tem como objetivo principal, descrever as atividades de SCM Software Configuration Manager (Gerência de Configuração de Software), utilizando as práticas de Nível 2 do modelo de qualidade de software CMU/SEI-CMM Carnegie Mellon University/ Software Engineering Institute-Capability Maturity Model, também conhecido como CMM, mostrando as vantagens do desenvolvimento paralelo, componentização e a economia que se faz ao contemplar o modelo. Desta pesquisa, resulta um modelo contendo os procedimentos que possam ser implementados em uma software house que queira incluir SCM no seu processo de desenvolvimento de software. Portanto, os passos para atingir os benefícios de SCM formam o escopo principal desta pesquisa, mas para tais conclusões fez-se necessário estudar todo o modelo CMU/SEI-CMM Carnegie Mellon University/ Software Engineering Institute-Capability Maturity Model, com seus 5 (cinco) níveis de maturidade e suas áreas chaves, além do processo de engenharia de software RUP Rational Unified Process. ABSTRACT This research has as its main goal to describe the SCM - Software Configuration Manager activities using the practices of Level 2 in the model of software quality CMU/SEI-CMM Carnegie Mellon University/Software Engineering Institute-Capability Maturity Model, also known as CMM, showing the advantages of the parallel development, componentization and the economy made when contemplating the model. From this research results a model containing the procedures that can be deployed in a software house that would like to include SCM in its software development process. Therefore, the steps to reach the SCM benefits make the main scope of this research. But, for such conclusions, it was necessary to study the entire model CMU/SEI- CMM Carnegie Mellon University/ Software Engineering Institute-Capability Maturity Model with its five (5) levels of maturity and its key areas, besides the software engineering process RUP - Rational Unified Process.

5 v SUMÁRIO 1. INTRODUÇÃO MODELOS DE REFERÊNCIA CMM Capability Maturity Model Nível 1 Inicial Nível 2 Repetível Nível 3 Definido Nível 4 Gerenciado Nível 5 Em Otimização RUP - Rational Unified Process SCM SOFTWARE CONFIGURATION MANAGER Conceito Metas (Goals) Atividades Artefatos Plano de Gerência de Configuração Itens de Configuração (ICs) Requisição de Mudança Relatório de Balanço Release Notes FERRAMENTAS Rational ClearCase CVS - Concurrent Versions System StarTeam Microsoft Visual SourceSafe Rational ClearQuest CR MODELO DE PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO E MUDANÇA Fluxo de Atividades Estabelecer Gerência de Configuração Criar Ambiente de Configuração Gerenciar Mudanças Gerenciar Itens de Configuração Gerenciar Baseline e Release Monitorar Subcontratada CONSIDERAÇÕES FINAIS GLOSSÁRIO REFERÊNCIAS BIBLIOGRAFICAS BIBLIOGRAFIA... 38

6 vi 10. APÊNDICES Apêndice A Template de Plano de Gerência de Configuração Apêndice B Template de Relatório de Balanço de Configuração Apêndice C Template de Release Notes Apêndice D Template de Formulário de Requisição de Mudança... 38

7 7 1. INTRODUÇÃO A necessidade de sobrevivência comercial em um mercado sem fronteiras faz com que as empresas vivam um processo de transformação contínua. Especificamente, as empresas de software são umas das mais afetadas por estas transformações, dada a dinâmica dos componentes envolvidos num projeto de software. Neste contexto, a Engenharia de Software tem por finalidade auxiliar na construção de softwares da melhor maneira possível. Embora vários esforços no sentido de se produzir software com maior produtividade e qualidade tenham ocorrido em décadas anteriores, foi nos anos 90 que se iniciou um movimento de entendimento e solução de problemas crônicos que afetam a indústria de software, principalmente os relacionados ao não cumprimento de prazos, orçamentos e funcionalidades requeridas em seus produtos. Foi reconhecido que vários desses problemas estariam baseados no fato da construção de software estar sendo conduzida por métodos improvisados e de maneira artesanal, muitas vezes, mais dependente do talento profissional e de esforços heróicos individuais, do que de processos formais orientados ao gerenciamento e à engenharia de software. Com isso, os modelos de qualidade do processo de software ganharam visibilidade mundial. Em especial, o CMU/SEI-CMM Carnegie Mellon University/ Software Engineering Institute-Capability Maturity Model ou, simplesmente, CMM [1]. Uma das áreas-chaves desse processo é a SCM Software Configuration Manager (Gerência de Configuração de Software), que tem como objetivo estabelecer e manter a integridade dos produtos do projeto de software ao longo de todo o ciclo de vida de software do projeto.

8 8 2. MODELOS DE REFERÊNCIA A seguir serão apresentados o Modelo de Capacitação de Maturidade (Capability Maturity Model CMM) e o Processo Unificado da Rational (Rational Unified Process RUP), de grande aceitação em nível internacional e que foram utilizados como referência para a elaboração desta pesquisa CMM Capability Maturity Model O CMM é uma iniciativa do SEI para avaliar e melhorar a capacitação de empresas que produzem software. O projeto CMM foi apoiado pelo Departamento de Defesa do governo dos Estados Unidos (DOD), que é um grande consumidor de software e precisava de um modelo formal que permitisse selecionar os seus fornecedores de software de forma adequada. Embora não seja uma norma emitida por uma instituição internacional como a ISO ou o IEEE, este modelo tem tido uma grande aceitação mundial. O CMM é um guia designado a ajudar as organizações de software a selecionar estratégias de melhoria de processos[2]. O objetivo deste modelo é que o processo de software possa ser repetido, controlado e medido e estabelecer uma compreensão comum entre clientes e a equipe de desenvolvimento de software sobre a necessidade dos clientes, o CMM leva a organização em direção a uma visão integrada onde as necessidades técnicas devem ser mantidas consistentes com as atividades desenvolvidas e com o planejamento do projeto[3]. Para efetuar este processo, os requisitos do software devem ser documentados e revistos pelos gerentes de software e grupos afetados, incluindo representantes dos clientes e da comunidade de usuários. O modelo auxilia as organizações a implementarem um processo de melhoria gradativa, baseado em níveis de maturidade. O termo maturidade está associado ao grau de conhecimento, controle e sistemática de execução de um processo de software atingido por

9 9 uma organização[1]. O CMM se divide em cinco níveis conforme pode se observar na figura 2.1 apresentada abaixo: processo em melhoria contínua Em otimização (5) processo disciplinado Repetível (2) processo previsível Gerenciado (4) processo padronizado Definido (3) Pouco Controlado Inicial (1) Figura 2.1 Cada nível especifica um conjunto de processos que devem ser estabelecidos para se atingir a maturidade correspondente ao nível. Adicionalmente, cada nível serve de base para o estabelecimento dos processos do nível seguinte. Os cinco níveis do CMM são organizados em áreas chave (KPA). Ao todo, o modelo possui 18 áreas chave. Cada área chave possui 5 características comuns: Compromisso em realizar Capacidade de realizar Atividades realizadas Medição e Análise Verificação da Implementação Cada área chave possui práticas chave (KP). Ao todo, o modelo possui 316 práticaschave.

10 10 As áreas chave do processo constituem a primeira divisão sistemática dentro dos níveis de maturidade de uma organização. Esses grupos de atividades, quando executadas em conjunto, satisfazem um conjunto de metas relevantes para a melhoria da capacitação do processo. O CMM considera cada área chave um processo particular. Os níveis de maturidade descrevem os problemas mais predominantes daquele nível. Uma organização migra de um nível a outro sempre que consegue operacionalizar todas as áreas-chave específicas de um nível Nível 1 Inicial O processo de software é considerado como desorganizado, e ocasionalmente também caótico. Poucos processos são definidos e as qualidades alcançadas pelo software, os processos e o conhecimento pertencem às pessoas e não aos projetos. No primeiro nível do modelo destacam-se as seguintes características: Estágios das atividades mal definidos; Dificuldade de visualizar e gerenciar o progresso e as atividades do projeto; Os requisitos fluem no processo de uma forma não controlada e há um produto resultante; O cliente somente verifica se os seus requisitos foram atendidos na entrega do produto. Áreas-chave de Processo: Este nível não possui áreas-chave de processos.

11 Nível 2 Repetível Processos básicos de gerenciamento de projetos são estabelecidos para monitoramento de custo, prazo e funcionalidade. A necessária disciplina do processo é adequada para repetir sucessos anteriores em projetos com aplicações similares. No nível de maturidade definido como repetível, as políticas de gerenciamento do software e os procedimentos detalhados para sua implementação estão estabilizados. O planejamento e o gerenciamento dos novos projetos são baseados na experiência adquirida em projetos similares anteriormente executados. Um dos objetivos a ser alcançado no CMM Nível 2 é tornar corporativos todos os processos de gerenciamento de software, o que permitirá à organização repetir sistematicamente as melhores práticas internas estabelecidas pelas várias experiências adquiridas em projetos anteriores. Um efetivo processo de gerenciamento de software deve ser praticado, documentado, garantido, treinado, medido e constantemente melhorado. Projetos em organizações com CMM Nível 2 têm controles básicos de gerenciamento de software. As estimativas de tempo, recursos e custos do software são baseadas nos históricos dos projetos anteriores e projetadas através dos requisitos estabelecidos no atual projeto. Os gerentes de software possuem um controle de rastreabilidade em relação aos custos, cronogramas, funcionalidades e defeitos. Os problemas são identificados na mesma etapa em que são gerados, evitando a propagação de erros para fases posteriores. Os requisitos de software e todos os produtos gerados durante o desenvolvimento são sistematicamente monitorados, possibilitando um acompanhamento da evolução do seu tamanho e complexidade. Os padrões de desenvolvimento do software são definidos e a organização garante que estão sendo sistematicamente seguidos.

12 12 As organizações CMM Nível 2 que empregam terceiros (subcontratados) para todo ou parte dos processos de desenvolvimento de um software, devem estruturar políticas claras e padronizadas de como estabelecer vínculos precisos e transparentes no relacionamento cliente-fornecedor. O processo de software de uma organização CMM Nível 2 pode ser entendido como um processo disciplinado, pois as políticas de planejamento e rastreamento do projeto de software estão estáveis e as práticas aplicadas a determinados projetos podem ser convenientemente repetidas corporativamente. O processo de software está sob o controle de um consolidado modelo de gerenciamento de projetos regido por planos objetivos e realistas, estimados a partir das experiências de projetos anteriores. No segundo nível do modelo destacam-se as seguintes características: As atividades, medições, pontos e verificação estão definidos; Requisitos do cliente e produtos do trabalho são controlados; É possível medir qualidade, custo e cronograma; O processo de desenvolvimento de software permite o gerenciamento entre pontos de transição ( milestones ); O cliente pode analisar o produto durante o processo de software ( checkpoints ); Existem mecanismos formais para a correção de desvios; Os processos pertencem aos projetos e não às pessoas. Áreas chave de Processo: RM Gerência de Requisitos SPP Planejamento de Projeto de Software SPTO Acompanhamento e Supervisão do projeto de Software

13 13 SSM Gerenciamento de subcontratado de software SQA Garantia da qualidade de software SCM Gerência da configuração de software Nível 3 Definido O processo de software para as atividades de gerenciamento e engenharia é documentado, padronizado e integrado no âmbito da organização e todos os projetos são adaptados deste processo. No nível de maturidade classificado como Definido, os diversos processos padronizados de desenvolvimento de software estão adequadamente documentados. Os processos de gerenciamento do software estão convenientemente integrados aos processos de engenharia de software, tornando o modelo de processos único e integrado às diversas áreas organizacionais. Os processos estabelecidos em organizações CMM Nível 3 são usados e ajustados para auxiliar os gerentes e profissionais de software a ganharem mais produtividade. A organização busca as melhores práticas de engenharia de software quando padronizam seus processos de software. Há um grupo responsável por estabelecer e documentar as atividades do processo de software denominado SEPG (Software Engineering Process Group). Um amplo programa de treinamento corporativo deverá ser implementado para desenvolver gerentes e profissionais e capacitá-los a desempenhar melhor suas funções, empregando uma política contínua de transferência do conhecimento e adequado desenvolvimento e aprimoramento de habilidades. As organizações CMM Nível 3 conseguem gerenciar processos dinâmicos de desenvolvimento de software. A partir de um processo padrão desenvolvimento, essas organizações podem acrescentar, modificar ou eliminar atividades, dependendo das

14 14 características e riscos envolvidos no projeto, possibilitando a criação de um processo de desenvolvimento customizado a cada situação. A equipe do SEPG estabelece os pontos de processo que possibilitam a customização e estabelece os critérios de flexibilização e em quais situações serão empregadas. Um processo bem definido inclui pré-requisitos para início das fases do projeto, artefatos obrigatórios e opcionais, padrões e modelos de referência, procedimentos de execução dos trabalhos, mecanismos de verificação de documentos, artefatos de saída e critérios de finalização das etapas. Nesse nível, é possível visualizar claramente como cada projeto em execução está evoluindo. O processo de software de uma organização CMM Nível 3 pode ser entendido como padronizado e consistente porque ambas as atividades de engenharia e desenvolvimento estão estáveis e replicáveis. Todos os aspectos relativos a um produto de software como custos, atividades e funcionalidades estão sob controle e a qualidade é medida e registrada. Existe uma visão corporativa do processo de desenvolvimento, um entendimento claro sobre as atividades e responsabilidades estabelecidas neste processo de software. No terceiro nível do modelo destacam-se as seguintes características: As atividades no processo definido de projeto de software são visíveis; Os processos utilizados estão estabelecidos e padronizados em toda a organização; Como estão estáveis, os processos podem ser medidos quantitativamente; Gerentes e engenheiros entendem suas atividades e responsabilidades no processo; Gerenciamento preparado pró-ativamente para possíveis riscos; O cliente pode obter status atualizado, rapidamente e corretamente, com detalhe entre as atividades; Os processos pertencem agora a organização e não aos projetos.

15 15 Áreas chave de Processo: OPF Foco no processo da organização OPD Definição do processo da organização TP Programa de treinamento ISM Gerência Integrada de Software SPE Engenharia de Produto de Software IC Coordenação entre grupos PR Revisões técnicas formais Nível 4 Gerenciado Medições detalhadas do processo de software e qualidade do produto são coletadas. Ambos são quantitativamente entendidos e controlados. O gerenciamento quantitativo do processo tem o seu foco no processo e a capacidade do processo é conhecida quantitativamente. Quando o desempenho cai fora dos limites, deve-se identificar a razão e a realizar ações corretivas adequadas. Controle quantitativo no CMM significa qualquer técnica quantitativa ou baseada em métodos estatísticos. As palavras estatística e quantitativa envolvem necessariamente dados (números). Gerenciamento baseado em dados (fatos) resulta em decisões objetivas. No Nível 2, o foco da qualidade é conformidade com os requisitos, já no Nível 4, há uma ênfase na compreensão das necessidades do cliente, do usuário final e da organização. No Nível 4 dados são coletados e analisados nos diversos projetos da organização, metas mensuráveis de qualidade de produto são definidas e utilizadas.

16 16 No quarto nível do modelo destacam-se as seguintes características: Medidas de qualidade e produtividade são coletadas em todos os projetos; Gerentes possuem uma base de dados para tomadas de decisões; A habilidade de prever resultados é maior e a variabilidade do processo é menor; O cliente pode estabelecer um entendimento quantitativo da capacidade do processo e riscos antes do projeto iniciar; Áreas chave de Processo: QPM Gestão quantitativa dos processos SQM Gestão da qualidade de software Nível 5 Em Otimização Processo contínuo de melhoria é possível pela realimentação quantitativa do processo e da condução de idéias inovadoras e tecnológicas. O processo de melhoria no Nível 5 pode ser considerado como um estilo de vida da organização. Nas organizações maduras todos estão envolvidos nas atividades de melhoria. Uma das finalidades no Nível 5 é identificar a causa dos defeitos e evitar que eles aconteçam novamente. Envolve analisar defeitos que foram encontrados no passado, realizar ações específicas para evitar a ocorrência desses tipos de defeitos no futuro. No Nível 5 existe um grande foco na analise das causas, por exemplo, verifica-se porque o processo permitiu que o defeito ocorresse; o que no processo necessita ser corrigido para prevenir a ocorrência do defeito no futuro.

17 17 Existe no Nível 5 também uma preocupação com a identificação de novas tecnologias (ex. ferramentas, métodos e processos) e transferi-las para a organização de uma forma disciplinada. Envolve identificar, selecionar e avaliar novas tecnologias. Outra preocupação do Nível 5 é a de melhorar continuamente os processos de software utilizados na organização com o objetivo de melhorar a qualidade de software, aumentando a produtividade e diminuindo o ciclo de desenvolvimento do produto. No quinto nível do modelo destacam-se as seguintes características: Melhoria contínua do processo objetivando produtividade e qualidade; Gerentes são aptos a estimar e monitorar a eficácia das mudanças; Forte relação de parceria com o cliente. Áreas chave de Processo: DP Prevenção de não-conformidades TCM Gestão de Mudança Tecnológica PCM Gestão de Mudança do Processo 2.2. RUP - Rational Unified Process O padrão CMM especifica detalhadamente O QUÊ deve ser feito. O mercado muitas vezes, se perguntou COMO fazê-lo. Uma das empresas que se habilitou a responder esta questão foi a Rational Software Corporation que desenvolveu, com esta finalidade, o processo de engenharia de software Rational Unified Process (RUP). O Rational Unified Process é um processo de engenharia de software, cujas principais características são um desenvolvimento iterativo e incremental, orientado a objetos, com foco na criação de uma arquitetura robusta, análise de riscos, e a utilização de casos de uso para o desenvolvimento. O RUP foi desenvolvido para ser aplicável a uma

18 18 grande classe de projetos diferentes e pode ser considerado como um modelo genérico para processos de desenvolvimento. Isso significa que ele deve ser configurado para ser usado eficientemente [4]. Alguns conceitos do RUP definem: o ator - cujas responsabilidades e comportamentos podem ser aplicados a diversos indivíduos - a atividade, a unidade de trabalho de um determinado ator e os artefatos, que são elementos utilizados, criados ou modificados pela ação do ator durante a atividade. A atuação em uma atividade ao longo do tempo é denominada tarefa, e gera, na coletividade um workflow, isto é, uma seqüência que produz um resultado observável. Figura 2.1 A figura 2.1 mostra a arquitetura geral do RUP. O RUP tem duas dimensões: O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se desenvolve; O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lógica, por natureza.

19 19 A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado e é expressa em termos de fases, iterações e marcos. A segunda dimensão representa o aspecto estático do processo, como ele é descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do processo. O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos mais tempo com implementação. O RUP se encontra definido em quatro fases: Concepção, Elaboração, Construção e Transição, cada uma com objetivos específicos. Na fase de Concepção, deve-se estabelecer o escopo e a viabilidade econômica do projeto. Na Elaboração, o objetivo é eliminar os principais riscos e estabelecer uma arquitetura estável a partir da qual o sistema poderá evoluir. Na fase de Construção, um produto completo é desenvolvido de maneira iterativa até que esteja pronto para ser passado aos usuários, o que ocorre na fase de Transição, onde uma versão beta do sistema é disponibilizada. No final da Transição pode ser iniciado um novo ciclo de desenvolvimento para a evolução do produto, o que envolveria todas as fases novamente. Todas as fases têm ao final um marco (milestone) de verificação de quais objetivos da fase foram alcançados [4]. Estas fases geram, cada uma, artefatos e revisões nos requisitos de construção do software. Dentre os vários workflows do modelo RUP, tem destaque o de Gerência de Configuração e Mudança, representante da KPA de SCM, que mantém a integridade dos artefatos do projeto. Este workflow, por si próprio, gera como artefatos o plano de Gerência de Configuração e as solicitações de alterações, além de atas de reuniões sobre a infraestrutura do projeto. Conforme observado na figura 2.1, este processo é continuo desde o inicio do projeto, com um crescimento constante das atividades.

20 20 3. SCM SOFTWARE CONFIGURATION MANAGER 3.1. Conceito A área chave SCM Software Configuration Manager (Gerência de Configuração e Mudança) é a disciplina que gerencia e controla a evolução de um software através, basicamente, de controle formal de versões e solicitações de mudança. Esta área chave permite que gerentes, analistas, programadores, testadores e usuários entendam o sistema não apenas em seu estado atual, mas também em seus estados anteriores e, devido às mudanças em curso, em um estado futuro. A adoção de SCM por uma empresa envolve custos e benefícios que devem ser considerados. Os principais benefícios decorrentes da aplicação estão entre a facilidades para acomodar mudanças, o maior controle sobre os produtos, a economia de tempo de desenvolvimento, a facilidades na geração de versões diferentes de um mesmo produto de software (customização), a manutenção de históricos de produtos e a facilidades de se voltar a situações anteriores. Os principais custos, por outro lado, são o treinamento e os investimentos para a implementação, que englobam recursos humanos e computacionais. Entre os conceitos fundamentais de SCM está o conceito de Itens de Configuração, que pode ser definido como 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 [2]. Outro importante conceito é o de baseline (Configurações-Base). Por baseline, entende-se um conjunto bem definido de Itens de Configuração que representam um estágio do desenvolvimento, que é passível de modificações apenas mediante um mecanismo formal de alterações[1]. Portanto, se podem medir as quatro atividades principais de SCM como sendo: Identificação de Itens de Configuração

21 21 Controle de configuração das baselines Administração de estado das baselines (processo formal de mudanças) Auditagem desta configuração Todas essas atividades levam a um objetivo final, o controle de versões, que engloba a automatização do rastreamento de arquivos, a prevenção de conflitos entre desenvolvedores, permitindo o desenvolvimento paralelo, a recuperação de versões prévias para manutenção ou upgrade e a agregação de novos módulos, funcionalidades ou requisitos Metas (Goals) Meta 1 Meta 2 Meta 3 Meta 4 As atividades de Garantia da Qualidade de Software são planejadas. A aderência dos produtos de software e das atividades aos padrões, aos procedimentos e aos requisitos estabelecidos é verificada objetivamente. As atividades e os resultados das atividades de Garantia da Qualidade de Software são informados às pessoas e aos grupos afetados. As questões de não conformidade, que não podem ser resolvidas internamente ao projeto, são levadas ao conhecimento da gerência superior Atividades Atividade 1 É elaborado um plano de GCS para o projeto de software, de acordo com procedimentos documentados.

22 22 Atividade 2 Atividade 3 Atividade 4 Atividade 5 Atividade 6 Atividade 7 Atividade 8 Atividade 9 Atividade 10 Um plano de GCS documentado e aprovado é utilizado como base para a realização das atividades de GCS. Um sistema de biblioteca para gerência de configuração é estabelecido como repositório para as configurações básicas (baselines) de software. Os produtos de trabalho de software a serem colocados sob Gerência de configuração são identificados. As solicitações de alterações e relatórios de problemas para todos os itens/unidades de configuração são iniciados, revisados, aprovados e encaminhados de acordo com um procedimento documentado. As alterações das configurações básicas (baselines) são controladas de acordo com um procedimento documentado. Os produtos são criados a partir da biblioteca de configuração básica do software (baseline) e suas versões são controladas de acordo com um procedimento documentado. A situação dos itens/unidades de configuração é registrada de acordo com um procedimento documentado. Os relatórios padrão que documentam as atividades da GCS e o conteúdo da configuração básica (baseline) do software são desenvolvidos e disponibilizados para as pessoas e para os grupos afetados. As auditorias na configuração básica (baseline) do software são conduzidas de acordo com um procedimento documentado.

23 Artefatos Considera-se artefato todo conjunto de informações produzidas, modificadas ou utilizadas por um processo. Um artefato pode ser um modelo, um componente de um modelo ou um documento. Um artefato pode conter outros artefatos. Serão apresentados a seguir os artefatos gerados durante o processo de Gerência de Configuração Plano de Gerência de Configuração O Plano de Gerência de Configuração deve descrever todas as atividades relacionadas à gerência de configuração e controle de mudança do projeto a serem realizados ao longo do ciclo de vida do produto. Deve relacionar as responsabilidades dos membros da equipe do projeto e recursos necessários de hardware, software e humanos Itens de Configuração (ICs) São considerados ICs todos os elementos necessários para o desenvolvimento e geração dos produtos de software, conforme lista abaixo. Códigos fonte do projeto Documentos de especificação de requisitos Documentos de análise e projeto Documentos de testes Manuais do produto de software Os ICs com características diferentes dos critérios para seleção, descritos acima, podem ser considerados como IC do projeto usando os seguintes critérios : O item é entregue ao cliente e faz parte do pacote de software do projeto. O item é essencial para a geração do produto de software do projeto.

24 Requisição de Mudança Mudanças nos artefatos desenvolvidos podem ser solicitadas através de uma Requisição de Mudança, conforme definido explicitamente no Plano de Gerência de Configuração do projeto. Este artefato pode ser utilizado para documentar e rastrear defeitos encontrados no produto, solicitações de melhoria ou qualquer outro tipo de solicitação que demande alguma alteração nos produtos do projeto Relatório de Balanço O relatório de balanço de configuração pode ser obtido visualmente através da ferramenta de gerência de configuração ou ser um documento gerado. O conteúdo mínimo do relatório de balanço de configuração das baselines é o seguinte : Nova versão da baseline Versão anterior da baseline Lista de requisitos acordados/implementados Lista de solicitações de alteração acordadas/implementadas Diferença da baseline atual em relação à anterior Release Notes O Release Notes deve ser um documento gerado e considerado parte integrante da release a ser entregue ao cliente. Devem constar na Release Notes no mínimo as seguintes informações: nome do produto versão do produto data de liberação