DEFINIÇÃO DA METODOLOGIA

Universidade Federal de Lavras Especialização em Melhoria de Processo de Software Disciplina de Gerencia de Projetos de Software Alunos: Anderson Cavalcanti de Lima, Carla Sant'Ana de C. Silva Ivan Alves da Cunha e Luiz Humberto de Faria DEFINIÇÃO DA METODOLOGIA 1. INTRODUÇÃO O propósito deste documento é dar uma visão geral dos processos que compõem o ciclo de vida do gerenciamento de um projeto. Projetos são implementados como meio de realizar o plano estratégico de uma organização. Dessa forma, os projetos devem ser iniciados a partir de uma justificativa, uma causa (demanda de mercado, necessidade do cliente, necessidade empresarial, necessidade de avanço tecnológico, necessidade social ou ação da concorrência), aderente aos documentos estratégicos do Estabelecimento. Caso seja necessário um projeto, o Cliente deve declarar um Líder de Negócio responsável por identificar o objetivo, descrever o produto a ser criado, mapear as restrições, os benefícios esperados e levantar outras informações. 1.1- Projeto (definição) Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Possui objetivos pré-definidos e é realizado dentro de parâmetros de prazo, custo e qualidade, em que qualquer variação em um desses três parâmetros influenciará o outro. Os projetos de TI visam o atendimento de novas soluções tecnológicas ou para execução de extensas mudanças em soluções já existentes. Para que uma organização exerça controle efetivo sobre a criação de novos projetos, é necessário que seja estabelecido um processo formal de autorização, onde as propostas de novos projetos são avaliadas e autorizadas pela alta gerência. Sempre obter a autorização do cliente antes de iniciar um projeto. Isso garante que apenas projetos alinhados com a requisição, capazes de serem executados pela organização demandante, serão desenvolvidos. 1.2 O que é Gerenciar um Projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender a seus objetivos. Caracteriza-se pelo planejamento, execução e controle de várias atividades integradas de forma que atinjam com êxito seus objetivos. 1.3- Ciclo de Vida do Gerenciamento de Projetos Todos os projetos, independentemente do ciclo de vida específico que percorrem e da área de aplicação, se inserem dentro do ciclo de vida do gerenciamento de projetos. Enquanto os ciclos de vida específicos dos projetos definem os produtos e entregas a serem desenvolvidas (e, justamente por isso, variam de acordo com a área de especialização), o ciclo de vida do gerenciamento de projeto é genérico e se aplica aos procedimentos que devem ser observados no desenvolvimento dos projetos. 2- REQM Gerenciamento de Requisitos 2.1- Definição

Requisitos são descrições das funções e restrições que são geradas durante o processo de engenharia de requisitos. Podem ser: Não Funcionais são as características ou atributos que as funções do produto devem contemplar (qualidade, segurança, performance, informação etc). Para que os documentos de requisitos tenham um formato uniforme de modelagem e um padrão de qualidade que permitam futuras certificações (do processo), é necessária confecção do artefato DRS - documento de requisitos de sistema (artefato obrigatório). Para agilizar o atendimento, a equipe responsável por requisitos no desenvolvimento, solicita que o DRS seja avaliado penas quando estiver com todos os itens e campos preenchidos e considerado finalizado pelo analista. 2.2- Objetivo O principal objetivo do processo de requisitos é desenvolver produtos de qualidade que satisfaçam às necessidades dos clientes dentro do prazo e do orçamento. 2.3- Atividades desta fase Observar a requisição do cliente; Elaborar uma proposta de projeto; Submeter a aprovação da alta administração; Obter a aprovação do cliente; Proposta aprovada; Confeccionar o Termo de Abertura do Projeto (TAP); Autorizar o projeto (assinatura do contrato); Planejar o desenvolvimento do projeto; Confeccionar o Desenvolvimento de Requisitos do Sistema (DRS). Para elaborar uma proposta de projeto, é realizado um planejamento preliminar do projeto, de acordo com a requisição do cliente, visando descrever o escopo, estimar a duração e o cronograma, identificar principais riscos e necessidades de contratações e aquisições, com o objetivo de fornecer ao nível executivo as informações para a correta tomada de decisão quanto o seu desenvolvimento. Após aprovação do projeto pela alta administração, devem ser elaborados os documentos denominados de Termos de Abertura do Projeto (TAP) e confeccionar o Documento de Requisitos do Sistema (DRS), os quais devem ser obrigatórios para aprovação da proposta e desenvolvimento do projeto (caso não exista na organização, o gerente da proposta deverá negociar previamente o conteúdo com a alta administração). O conteúdo da proposta poderá incluir todas ou parte das informações prestadas no ato da requisição pelo cliente. Deve ser executado um planejamento preliminar com vistas a estimar o prazo, o custo, as necessidades de aquisições de recursos humanos, qualidade, e analisar os riscos do projeto. Os resultados desses processos irão fornecer as informações para elaboração do TAP. O nível de detalhe desse planejamento dependerá das exigências do cliente e do prazo e do esforço que poderá ser despendido para elaboração da proposta, assim como da necessidade de exatidão das estimativas de prazo e custo. A modelagem de requisitos tem a finalidade

Documentar os requisitos em modelos funcionais; Definir as fronteiras do sistema (ou delimitar o sistema); Estabelecer e manter concordância com os envolvidos no projeto sobre o que o sistema deve fazer; Priorizar e refinar os requisitos selecionando os que serão entregues; Identificar os requisitos de sistema individuais, tanto de hardware quanto de software, que precisam ser testados; Oferecer aos desenvolvedores do sistema uma compreensão melhor dos requisitos do sistema; Fornecer uma base para estimar o custo e o tempo de desenvolvimento do sistema. As principais preocupações da gestão de requisitos são as seguintes: Garantir que o documento de requisitos estabeleça um entendimento comum dos requisitos acordados entre os envolvidos; Gerenciar os relacionamentos entre os requisitos; Gerenciar as dependências entre o documento de requisitos e outros documentos produzidos ao longo do processo. A equipe da Gerência de Desenvolvimento deve analisar se os requisitos estão dentro do padrão. Se necessitar de ajustes, o líder do projeto recebe uma lista de recomendações. Se estiver tudo dentro do padrão, o líder do projeto enviará o documento para apreciação formal da alta administração que dará o De acordo. Este de Acordo da alta administração é fornecido formalmente. O que não será feito Definir o que não será feito evita várias discussões futuras a respeito do entendimento do projeto. Com a definição do que não será feito, o líder limita seu trabalho, deixando claro para as partes interessadas o escopo do projeto. Note que, por definição, tudo que não está especificado na definição de requisitos do projeto, não será feito. Entretanto, quando alguma característica que normalmente faz parte de uma função não será construída, esta deve ser explicitada no DRS. 2.4 Artefatos desta fase PP (Proposta de Projeto) Nível estratégico TAP (Termo de Abertura do Projeto) Nível estratégico A Proposta de Projeto (PP) É um documento que descreve o objetivo, a necessidade de negócio, o escopo (incluindo a descrição do produto e as responsabilidades entre as partes cliente e organização), prazo, orçamento / preço, plano de comunicação e riscos do projeto. Este documento tem o objetivo de estabelecer um compromisso formal de relacionamento com o cliente que solicitou o projeto. Esta proposta é submetida à aprovação da alta administração, que irá avaliar e decidir se o projeto pode ou não ser iniciado. A avaliação realizada pela alta administração levará em conta critérios pré-estabelecidos de qualidade de proposta, para garantir que ela esteja completa, coerente e realizável. Os níveis das gerências envolvidas devem participar da avaliação. Descreve os parâmetros do sistema ou produto a ser desenvolvido. TAP Termo de Abertura do Projeto O termo de abertura do projeto é o documento no qual a organização reconhece a existência de um projeto, designa e dá autoridade ao gerente do projeto para utilizar recursos na execução do mesmo. Em muitas organizações

uma proposta de projeto autorizada por um cliente interno ou o próprio contrato substitui o TAP. O Termo de Abertura do Projeto (TAP) deve conter os seguintes tópicos: Justificativa - A justificativa do projeto deve ser descrita em função dos seguintes aspectos: Porque o projeto é necessário; Objetivos do projeto; e Benefícios para o cliente. Produtos e Serviços - Quais os produtos e serviços esperados e onde será realizada a execução do projeto; Gerente de Projeto e Nível de Autoridade Identifica o gerente do projeto e estabelece seus poderes e limitações de autoridade (alçadas) Cronograma de Marcos Apresentação das princípais datas do projeto, principalmente as relacionadas com entrega dos principais produtos e serviços, na forma de um cronograma de marcos. Participantes do Projeto Relação dos principais grupos envolvidos na execução do projeto (departamentos, equipes) Restrições relaciona as restrições que o projeto deve obedecer, geralmente são as relacionadas com os principais aspectos do gerenciamento do projeto, a saber: Limites de tempo (prazo de conclusão e entrega do produto) Limites de recursos (limites de orçamento, de recursos materiais ou humanos); Outros limites relacionados com as políticas organizacionais ou legais; Premissas São condições consideradas verdadeiras para o planejamento do projeto. Normalmente implicam em riscos para a execução do projeto, dependendo do seu grau de incerteza. Uma premissa pode ser vista com um pré-requisito para o qual se atribuiu uma data e uma quantidade específica. Exemplo: - O cliente entregará todas as especificações no dia tal; - O departamento de RH entregará dois estagiários até o dia tal; Contrato ou Proposta do Projeto O TAP deve fazer referência ao contrato ou à proposta que originou o projeto. Propósito Especifica os requisitos do sistema a ser desenvolvido, fornecendo aos desenvolvedores as informações necessárias para o projeto. Escopo Este tópico especifica a elicitação de requisitos do sistema; Requisitos Funcionais São descritos os requisitos funcionais do sistema a ser implementado. Aqueles que especificam e descrevem as funções que o produto deverá ser capaz de executar. Uma função pode ser representada por um objetivo definido ou por uma ação característica. Requisito Não Funcional Descreve os requisitos não funcionais do sistema. Os requisitos devem abordar subseções, tais como: Segurança - Descreve os requisitos associados à integridade dos dados; Performance Descreve o tempo de resposta do sistema durante o uso dos recursos; Usabilidade Descreve os requisitos não funcionais associados à facilidade de uso;

Confiabilidade Descreve os requisitos não funcionais associados à freqüência de falhas; Padrões Descreve quais os padrões e normas a serem seguidas no desenvolvimento; Hardware e Software Descreve qual hardware e software que será utilizado pelo sistema. Visão Geral do Sistema Descreve o objetivo do sistema, suas respectivas funcionalidades, qual público alvo do sistema, qual a necessidade de implementar o produto, impacto do sistema e sucesso que a solução pretende trazer; 2.5- Papeis Programador Gerente Negociador Proposta de Projeto - Negócios da empresa; Analista Programador - Confecção dos documentos; Gerente do Projeto Conferência dos documentos e Responsável técnico; Diretor da área Responsável estratégico; Presidente Patrocinador do projeto. 3. PP Planejamento de Projeto Planejamento: nesta etapa é detalhado tudo aquilo que será realizado pelo projeto para que, no final desta fase, ele esteja suficientemente detalhado para ser executado com o mínimo de dificuldades e imprevistos. O Planejamento do consiste na criação de um Plano de Gerenciamento do Projeto PGP que irá definir o caminho para que sejam alcançados os objetivos para os quais o projeto foi criado. Tudo que será executado no projeto, que tenha relevância para ser planejado, deve constar do PGP, inclusive o trabalho de gerenciamento (Planejamento, execução, controle e fechamento do projeto). O esforço de planejamento deve ser adequado à necessidade de cada projeto. Assim, quanto maior e mais complexo um projeto, maior deve ser o detalhamento e a quantidade de documentos a serem elaborados. A organização, ao implantar uma metodologia de gerenciamento de projeto, deve estabelecer, de acordo com algum critério apropriado à organização, que documentos de palnejamento devem ser emitidos pela equipe do projeto. Em geral, os objetivos, desejos e interesses são formulados anteriormente, no PP e estas premissas devem ser levados em consideração durante o planejamento. A negociação permanente entre as partes interessadas do projeto deve ser um aspecto marcante durante todo o planejamento do projeto. Um bom projeto começa pelo consenso entre todas as partes interessadas no sentido de trabalharem em prol de um objetivo comum. O planejamento do projeto é um processo contínuo que não acaba com o início da execução. É engano pensar que basta estabelecer um PGP e implementa-lo. O plano precisa ser mantido atualizado para refletir a execução do projeto e as mudanças autorizadas pois, até mesmo as orientações básicas e os objetivos, que normalmente são válidos por um tempo mais longo, podem mudar durante o projeto. É muito importante que haja acordo entre os envolvidos no projeto para que o PGP seja modificado. E, quando não se consegue este acordo, é sempre melhor aceitar os fortes interesses das principais partes interessadas. Não se deve acreditar que tudo é possível pois o planejamento

implica custos que precisam ser justificados pelos benefícios obtidos da adaptação do PGP. A equipe de planejamento do projeto deve ajustar continuamente os detalhes durante toda a execução, de modo a manter o PGP continuamente atualizado e dentro da realidade do projeto, para que o plano seja um guia para a equipe ou um veículo de comunicação entre as partes interessadas do projeto. 3.1 - Atividades Fazer estimativas Compromisso entre as partes interessadas Definir o plano de projeto Elaborar a Estrutura Analítica do Projeto (EAP) Elaborar o cronograma Calcular o custo das atividades do projeto Planejar as comunicações Planejar as aquisições Planejar as respostas aos riscos Planejar a qualidade Planejar os recursos humanos Planejar a integração Consolidar e aprovar o plano de gerenciamento do projeto Fazer estimativas Estabelecer estimativas de produtos de trabalho e atribuição de tarefas, estabelecer e manter estimativas dos atributos dos produtos de trabalho e das tarefas. Compromisso entre as partes interessadas (stakeholders)- Obter o compromisso entre as pessoas, empresas e organizações, que atuarão ou serão afetadas pelos resultados do projeto; Definir o plano de projeto São os produtos e serviços que serão entregues relacionados aos objetivos do projeto; Elaborar a Estrutura Analítica do Projeto (EAP) É uma estrutura hierárquica que pode ser representada como uma lista ou na forma gráfica. Para usar a forma gráfica, que é de melhor visualização, o gerente de projeto necessita utilizar uma ferramenta que auxilie o desenho. Porém para utilização da lista pode se utilizar o MS-Project, editor de textos ou planilha eletrônica, para representar a EAP. Pode se representar graficamente em forma de fluxo das atividades começando com o nome do projeto (ex: treinamento em gerenciamento de projeto), em seguida as fases que estabelecem o ciclo de vida do projeto (preparação do treinamento, treinamento). Porém isso não quer dizer que esta seja a única forma de decompor inicialmente o projeto. Além de ser por fases, a decomposição inicial, assim como a decomposição em qualquer nível da EAP, pode ser por subprodutos (ex: decompor uma bicicleta em suas partes principais), por localização física (ex: região nordeste, região sul etc.), e pode se acrescentar entregas aos subprocessos. Na EAP (WBS) estão estabelecidas as entregas do projeto e, no seu dicionário, estão as especificações e critérios de aceitação dessas entregas. O trabalho que não está na EAP está fora do escopo do projeto. Com relação à declaração do escopo, a EAP é freqüentemente usada para elaborar ou confirmar um

entendimento comum do escopo do projeto. Cada nível descendente representa um incremento no detalhamento da descrição dos elementos do projeto. As descrições dos componentes de trabalho são, freqüentemente, armazenadas em um dicionário EAP. Um dicionário EAP inclui, tipicamente, descrições de pacotes de trabalho, assim como outras informações de planejamento, tais como prazos, orçamentos e pessoal designado. Exemplo da representação da EAP (lista): 1- Computador 1.1 Documentação 1.2 Computador Pessoal 1.2.1 Estrutura 1.2.2 Placa Mãe 1.2.3 Disco Rígido 1.2.4 Fonte 1.2.5 Montagem 1.3 Teste de sistema 1.4 Sistema Operacional 1.5 Gerenciamento do Projeto Elaborar o cronograma Consiste em determinar o início e término das atividades do projeto. Calcular o custo das atividades do projeto E o processo que envolve desenvolver uma estimativa da duração das atividades e dos custos dos recursos necessários para a implementação das atividades do projeto. Planejar as comunicações O objetivo deste processo é planejar como deverá ser feita a geração, coleta, armazenamento e o controle das informações do projeto, bem como a sua distribuição criteriosa, por meios adequados e no momento certo, às partes interessadas do projeto. Planejar as aquisições Passa pela decisão do que, quanto, quando e como será a contratação no projeto, incluindo administração e o encerramento de contratos. O gerenciamento de aquisições do projeto também inclui a administração de qualquer contrato emitido por uma organização externa ( o comprador) que está adquirindo o projeto da organização executora e a administração de obrigações contratuais estabelecidas para equipe do projeto pelo contrato. Planejar de respostas aos riscos Identificar os riscos que podem afetar o projeto e descrever suas características e selecionar as ações a serem adotadas para reduzir as ameaças e potencializar as oportunidades que influenciam o resultado do projeto. Este processo visa garantir que os riscos serão adequadamente tratados Planejar a qualidade O objetivo deste processo é documentar as características desejadas e os métodos de medição e avaliação que serão utilizados para determinar se a qualidade dos produtos do projeto é satisfatória. Geralmente, estas características, no que se refere ao produto, são estabelecidas pelo demandante. Planejar os recursos humanos Este processo tem como objetivo identificar o perfil dos recursos necessários para o desenvolvimento do projeto, definindo a forma de contratar ou mobilizar estes recursos,a estratégia de qualificação profissional e a forma como esta equipe será gerenciada. Os patrocinadores devem prover o gerente de projeto com todo o apoio possível para que a equipe seja montada e mobilizada nos momentos adequados.

Planejar a integração Este processo tem o objetivo de planejar as ações que deverão ser desenvolvidas pelo gerente de projeto e equipe de projeto para orientar a execução do PGP. Consolidar e aprovar o plano de gerenciamento do projeto É o documento utilizdo para orientar e coordenar o trabalho a ser executado pelo projeto, integra em um único documento, de forma coerente e consistente, todo o planejamento do projeto,servido como base para a gerência do projeto. 3.2- Papeis Patrocinador Gerente do projeto Equipe de planejamento do projeto 3.3- Artefato desta fase PGP O conteúdo do PGP irá variar dependendo da área de aplicação e complexidade do projeto, da mesma forma que o PGP deve ser constantemente atualizado a realidade do projeto. A equipe de planejamento deve juntar toda documentação de planejamento em um plano e verificar a consistência entre esses documentos. Por exemplo, se alguma resposta aos riscos foi planejada, no plano de resposta aos riscos deve estar refletida na EAP. Deve ser abordada as seguintes características: Relativas ao gerenciamento do escopo; Relativos ao gerenciamento do tempo; Relativos ao gerenciamento do custo; Relativos ao gerenciamento da comunicação; Relativos ao gerenciamento de aquisições; Relativos ao gerenciamento dos riscos; Relativos ao gerenciamento da qualidade; Relativos ao gerenciamento de recursos humanos; Relativos ao gerenciamento da integração do projeto. 4- PMC Monitoração e Controle de Projeto A finalidade da monitoração e controle é oferecer visibilidade adequada no progresso real de modo que o gerente possa tomar medidas efetivas quando o desempenho se desvia significativamente do plano. A monitoração e o controle visam verificar se os objetivos do projeto estão sendo atingidos, através da monitoração e medições regulares de progresso, verificação da existência de variações em relação ao planejado, e da tomada de ações corretivas e preventivas quando necessárias. Ele deve acontecer paralelamente à execução do projeto. 4.1 - Atividades Controlar o desempenho do projeto Realizar o controle Integrado de Mudanças Monitorar os Riscos do projeto Obter a aceitação do Escopo Controlar a qualidade

Conduzir revisões de evolução Gerenciar ações corretivas Gerenciar o envolvimento das partes interessadas Gerenciar Equipe do projeto Controlar o desempenho do projeto O controle do desempenho do projeto envolve coletar e disseminar, para as partes interessadas, as informações de desempenho, incluindo como os recursos estão sendo utilizados para alcançar os objetivos do projeto e inclui relatar a situação, relatar o progresso e fazer previsões. Os relatos de desempenho fornecem informações do escopo, cronograma, custo e qualidade do projeto. Inclui verificação de quais entregas foram completamente ou parcialmente concluídos, quais custos etc. Realizar o controle Integrado de Mudanças Mudanças nos projetos ocorrem por vários motivos, que não necessariamente implicam em conseqüências negativas. O importante é gerenciar esse processo com muita atenção, pois o excesso, ou até mesmo uma única mudança não devidamente avaliada ou controlada, pode causar impacto significativo no cronograma, custo e qualidade do projeto. Monitorar e Controlar os Riscos É o processo de rastrear os riscos identificados, monitorar os riscos residuais e identifcar novos riscos, assegurando a execução do plano de resposta aos riscos e avaliando sua eficiência na redução dos mesmos. O processo registra as métricas que estão associadas com planos de contingência e é considerado um processo contínuo no ciclo de vida do projeto. Os riscos evoluem enquanto o projeto é executado, uma vez que novos riscos surgem e riscos previstos desaparecem. Obter a aceitação do Escopo Este processo tem o objetivo de obter a aceitação formal do escopo do projeto pelas partes envolvidas. Isto visa garantir que tudo foi completado correta e satisfatoriamente, com o correspondente aceite do cliente. Controlar a qualidade - Neste processo o objetivo é medir e avaliar os resultados obtidos pelo projeto (pelos seus processos de gerenciamento e realização do produto ou serviço a serem entregues ao cliente), comparando-se com os objetivos de qualidade definidos em um PGQ. Conduzir revisões de evolução - Os produtos e serviços, bem como os resultados dos processos de gerenciamento devem ser examinados com o intuito de medir suas características e avaliar se os requisitos da qualidade estão sendo atingidos e efetuar revisões com vistas a melhoria contínua. Calcular Indicadores de Qualidade - Deve se efetuar medições nos processos do projeto e devem ser utilizadas para elaborar indicadores de qualidade. Pode se utilizar gráficos de desempenho, diagrama de pareto dentre outros com objetivo de identificar desvios, análises das tendências e identificação das causa mais relevantes de problemas. Propor ações corretivas - Análise de indicadores elaborados no passo anterior irá resultar na identificação de problemas de qualidade, que serão os desvios entre os resultados obtidos com a medição e os objetivos de qualidade planejado. O passo seguinte é a análise das causas dos problemas identificados, utilizando-se para isso técnicas de análise para implementação de ações corretivas e preventivas.

Gerenciar Partes Interessadas - O Gerenciamento das partes interessadas é uma busca contínua de solução para os problemas existentes entre as mesmas, de modo a manter a harmonia da equipe e evitar interrupções indesejáveis durante o projeto. Gerenciar Equipe do projeto - Envolve o acompanhamento do desempenho dos membros da equipe, o feedback à equipe, a resolução de problemas e a coordenação de mudanças para melhorar o desempenho da equipe, manter uma equipe motivada e gerenciada é um desafio para o gerente de projeto. Os resultados do processo de monitoramento e controle devem ser incorporados no PGP para garantir que as ações acordadas sejam implementadas e monitoradas ao longo do progresso do projeto. 4.2- Papeis Patrocinador Gerente do projeto Equipe de planejamento do projeto 4.3- Artefato desta fase 5- CM Gerenciamento da Configuração A finalidade do Gerenciamento da Configuração é estabelecer e manter a integridade dos produtos de trabalho usando identificação de configuração, controle de configuração, compatibilidade dos itens de configuração e auditorias. Sob este aspecto, a Gerência de Configuração de Software (CGS) vem a definir critérios que permitam realizar tais modificações mantendo-se a consistência e a integridade do software com as especificações. Ela permite minimizar os problemas decorrentes ao processo de desenvolvimento, através de um controle sistemático sobre as modificações. Não é objetivo da GCS evitar modificações, mas permitir que elas ocorram sempre que possível, sem que hajam falhas inerentes ao processo. Entende-se como item de configuração 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 (Pressman em [PRE 92]). Em cada fase do processo de desenvolvimento, um conjunto bem definido de itens de configuração deve ser estabelecido. Tal conjunto representa um estágio do desenvolvimento, o qual é passível de modificações apenas mediante um mecanismo formal de alterações. A este conjunto é dado o nome de Baselines, ou Configurações Base do sistema. Esta fase possui três objetivos globais: 5.1 Atividades 1. Preparar plano de GCS de acordo com um procedimento documentado. Este procedimento especifica que o plano de GCS: - É desenvolvido nas fases iniciais e em paralelo como o planejamento global do projeto - É revisado pelos grupos envolvidos - É gerenciado e controlado 2. Executar atividades de GCD de acordo com o plano de GCS

3. Estabelecer um repositório para baselines 4. Identificar itens de configuração, ou seja, os artefatos de software que serão colocados sob gerência de configuração. Por exemplo: - documentação relacionada ao processo (por exemplo, planos, padrões e procedimentos) - requisitos de software - arquitetura de design de software - unidades de código de software - procedimentos de teste de software - sistema de software construído para apoiar as atividades de software - sistema de software construído para o cliente e usuário final - ferramentas de suporte (por exemplo, compiladores, bibliotecas, editores) 5. Gerenciar requisições de mudanças e relatórios de problemas para todos os itens de configuração 6. Controlar alterações nas baselines 7. Controlar a liberação de produtos 8. Registrar o estado dos itens de configuração 9. Divulgar as atividades de GCS e o conteúdo das baselines 10. Conduzir auditorias nas baselines de software 5.1.1 Estabelecer Baselines Em princípio, baselines poderiam ser estabelecidas em qualquer ponto do desenvolvimento. Entretanto, a grande vantagem do conceito está em se fazer coincidir o estabelecimento de baselines com os finais de fase do ciclo de vida do produto. Baseline é um conjunto de itens de software formalmente designados e estabelecidos num tempo determinado durante o ciclo de vida do software. Baselines representam marcos no processo de desenvolvimento: uma nova baseline é estabelecida no final de cada fase do ciclo de vida do software; Linha-base Linhas-base ou Baseline é um conjunto de configurações passadas e futuras que devem ser seguidas para se alcançar determinado objetivo. Elas podem ser simultâneas ou consecutivas: a versão 1.0 pode estar ao mesmo tempo sendo corrigida para falhas de segurança, gerando a versão 1.1 e evoluída com novas funcionalidades gerando a versão 2.0 do sistema. Nesse caso específico podemos identificar duas linhas-base simultâneas (versão 1.1 e versão 2.0) e uma linha base passada (versão 1.0). Linhas-base não são configurações fixas, mas sim toda a evolução de determinadas configurações. Todo o trabalho realizado para se chegar a versão 2.0 e todo o trabalho realizado depois em cima desta versão para se testar e corrigir problemas são parte da linha base, e não apenas a versão 2.0 em si. Exemplos de linhas-base Versão 1.0 Versão de correção de erros 1.1 Versão personalizada do sistema para o governo Baseline ajustado. Dependendo da natureza da mudança, o baseline correspondente (prazo, custo, etc) pode ser revisado e re-emitido com o objetivo de refletir a alteração aprovada e criar um novo baseline para futuras mudanças.

Criar Baseline: Para criar um baseline, o gerente do projeto deve identificar os itens de configuração e as versões destes itens que devem fazer parte do baseline além de descrever o baseline. Também devem ser descritas as diferenças entre este baseline e os anteriores. Entregar Baseline: Nesta atividade, o gerente do projeto deve em primeiro lugar selecionar o baseline a ser entregue. Tendo feito isso, o gerente deve empacotar o baseline em questão e em seguida entregá-lo ao receptor. Formalizar o BASELINE Formalizar o Baseline constitui-se em assumir as datas de início e término das atividades, e a distribuição dos recursos sejam eles quais forem presentes no Gantt Final, e os seus respectivos riscos. Este Baseline é o que deve alimentar os bancos de atividade. Além disto, deve ser usado como referência durante o desenvolvimento do projeto, em todas as reprogramações ocorridas no seu desenvolvimento. Mesmo que ocorram ajustes, atrasos a incrementos nas atividades, o Gerente do Projeto deverá procurar sempre voltar ao Baseline para o cumprimento do que foi contratado com o solicitante no que tange a prazo e a orçamento. 5.1.2 Acompanhar e controlar mudanças Um Conjunto de mudanças (do inglês: change set) é o conjunto de todas as alterações que ocorreram no sistema para atender um determinado fim, ou num determinado período de tempo. Associados com a Gerência de Mudanças, os conjuntos de mudanças mapeiam os itens que foram mudados para uma dada versão do sistema com os motivos das mudanças. Um exemplo de conjunto de mudanças: Mudanças da versão 1.0 para a versão 1.1 Item A mudou da revisão 1.0 para a revisão 1.1 Item B mudou da revisão 5.0 para a revisão 4.5 Item C foi eliminado Item D foi acrescentado na versão 5.5 Item E mudou de nome para item F. Gerência de mudanças A Gerência de mudanças é uma parte geralmente negligenciada da Gerência de configuração. Como ela não tem resultados imediatos para os desenvolvedores e engenheiro de software envolvidos no projeto, estes acabam por não perceber sua importância. Gerência de mudanças entretanto é uma parte importante da Gerência de configuração, pois é a atividade que permite se saber o motivo de uma configuração ter sido mudada para outra configuração. Esta atividade também pode ser parcialmente automatizada, e diversos sistemas de controle de versão já são integrados com sistemas de gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada mudança efetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos em sistemas de software arquivos que listam as melhorias e mudanças entre duas versões. Estes arquivos são resultado da gerência de mudanças, identificando o que mudou entre uma versão e outra. Exemplos mudança da versão 1.0 para 1.1 inclui: correção do problema nova funcionalidade de impressão de relatórios pendências para a versão 1.2: correção das mudanças impressão de relatórios

5.1.3 Estabelecer integridade São procedimentos para manter a integridade do produto de software durante todo seu ciclo de vida, através do controle sistemático de suas modificações e de seu armazenamento controlado, bem como do relato da situação do produto a todos os envolvidos no seu desenvolvimento. Estas atividades ajudam a eliminar inconsistências e redundância de trabalho, aumentando assim a qualidade do produto e a produtividade dos desenvolvedores. Estabelecer registros de Gerência de Configuração; Realizar auditorias de configuração 5.2 - Papéis Uma das principais definições da política de Gerência de Configuração de Software são os papeis a serem desempenhados. A política não determina quais pessoas desempenharão quais papeis, cabendo isso a gerência de projeto. Alguns papeis necessários numa política são: Gestor de configuração do projeto. Ele é o responsável por acompanhar as alterações dos itens de configurações de um determinado projeto. Em geral este papel cabe ao integrador. Gestor de ferramentas de Gerência de configuração. Ele é o responsável pela manutenção da infra-estrutura necessária para o bom funcionamento da Gerência de configuração no conjunto dos projetos da organização, ou no contexto do projeto, se for o caso. Em geral é uma pessoa da área de infra-estrutura com bons conhecimentos da plataforma operacional e das ferramentas usadas. Gestor de Configuração de Software, ou Responsável de Gerência de Configuração de Software. Ele é o responsável por aprovar e gerenciar as atividades relativas a Gerência de Configuração de Software, coordenar a equipe de Gerência de Configuração de Software e algumas vezes, coordenar o trabalho de integração de sistemas. Auditor de Configuração de Software. Ele é o responsável pela realização das auditorias de configuração nos projetos. Desenvolvedor. Ele é o principal usuário da Gerência de configuração de software, sendo quem produz os itens de configuração que serão gerenciados. 6- MA Medição e Análise O propósito das medições e análises é desenvolver e manter uma capacidade para realizar medições que são utilizadas para dar suporte às necessidades gerenciais de informação. Processos de medição se tornaram uma parte tão importante quanto necessária nas Organizações que desenvolvem software, pois para competir em um ambiente caracterizado por rápidas e constantes mudanças, é fundamental trabalhar de maneira produtiva, eficiente e com alto nível de qualidade. Por estes motivos, os dias de tomadas de decisão baseadas apenas em palpites terminaram, e é neste contexto que a medição se insere: a partir da existência de dados e análises históricas sobre a Organização é possível melhorar em muito o processo de tomada de decisão. 6.1 Atividades 6.1.1 - Alinhar as atividades de medidas e análises Estabelecer objetivos da medição Especificar medições

Especificar os dados a serem coletados e os procedimentos de armazenamento Especificar os procedimentos de análise As atividades e os objetivos de medidas são alinhados com as necessidades e objetivos de informação. Para atingir objetivo a equipe responsável pelas medições estabelece os objetivos de medição da Organização, e especifica as métricas e os procedimentos de coleta, armazenamento e análise de dados. Estabelecer objetivos da medição Estabelecer objetivos é desenvolver e sustentar a capacidade de medições que é utilizada para suportar as necessidades de gerenciamento de informações. A área de processo de Medições e Análises envolve especificar os objetivos de medições e análises, de forma que estes estejam alinhados com as necessidades e objetivos de informação da organização. Especificar as medidas Especificar as medidas compreende Questões de Medição que visa estabelecer questões a serem respondidas para que os objetivos de medição da Organização possam ser mensurados e Identificar Medidas que especificar medidas (métricas) para avaliar o atingimento dos objetivos definidos. Especificar Procedimentos de Análise inclui especificar como os dados de medições serão analisados e reportados e definir como os dados de medições serão obtidos e armazenados. Especificar mecanismos de coleta de dados e armazenamento, técnicas de análises e mecanismos de comunicação e de feedback Implementar a coleta, armazenagem, análise e relatórios sobre os dados com vistas a manter a integridade da informação que serão fornecidas. 6.1.2 - Fornecer os resultados das medidas Obter e fornecer os resultados das medições realizadas de acordo com as necessidades e objetivos de informação identificados pela Organização, garantindo sua integridade. Fornecer resultados objetivos que possam ser utilizados na tomada de decisões bem informadas e na tomada das ações corretivas apropriadas A integração das Analisar Dados de Medições Analisar e interpretar os dados obtidos nas medições Armazenar Dados e Resultados Gerenciar e armazenar os dados obtidos nas medições assim como as especificações das medições e os resultados de análise. Comunicar Resultados Comunicar os resultados das medições e das atividades de análise a todos os envolvidos. São fornecidos os resultados das medidas que são identificadas como necessidades e objetivos de informação Fornecimento de uma base para a incorporação das medições em outros processos no futuro (retro-alimentação). Artefato desta fase O Plano de Medição deve ser elaborado primeiramente para a Organização como um todo, e neste deverão estar definidos os objetivos corporativos de medição, as questões a serem respondidas para que se possa avaliar o atingimento destes objetivos e as medidas (métricas) propriamente ditas (assim como seus procedimentos de coleta, armazenamento e análise de dados) que serão utilizadas para responder às questões formuladas. Uma vez elaborado o Plano de Medição da Organização seus itens farão parte.

No Plano de Medição o usuário define pontos tais como o propósito das medições a serem realizadas (melhorar ou conhecer a Organização, por exemplo) e o contexto em que o Plano será elaborado inclui: Identificar os Objetivos da Organização o usuário seleciona os objetivos a serem alcançados pelas medições a serem efetuadas na Organização. Para cada objetivo identificado o usuário deve selecionar uma ou mais questões que devem ser respondidas para seu atingimento; Identificar Métricas da Organização o usuário deve selecionar uma ou mais métricas a serem utilizadas para responder a cada uma das questões previamente identificadas. Para cada métrica apresentada a ferramenta informa seus respectivos objetivos, descrições e procedimentos de coleta, armazenamento e análise. 7- RSKM Gerenciamento de Risco O propósito desta fase é identificar problemas em potencial antes de sua ocorrência de tal forma que as atividades de tratamento de risco devem ser planejadas e utilizadas quando necessário durante todo o ciclo de vida do produto ou do projeto para mitigar impactos adversos e alcançar os objetivos Atividades: Identificar os riscos Identificar as tarefas de alto risco Examine as tarefas que poderão demorar mais que o esperado, ser concluídas após as datas de término, atrasar o início ou a conclusão de outras tarefas ou atrasar a conclusão do projeto. Identificar riscos ao orçamento Exiba e gerencie as tarefas que estão ou poderão ficar acima do orçamento, bem como aquelas que possam fazer com que o projeto todo ultrapasse o orçamento. Identificar riscos ao recurso O projeto correrá riscos se você estiver usando recursos altamente especializados ou disponíveis apenas através de fornecedores limitados, se os recursos não forem usados de forma eficiente ou se estiverem trabalhando em vários projetos. Definir os seus riscos Depois de identificar os riscos potenciais, você poderá usar informações sobre riscos a fim de poder analisar o impacto caso se tornem reais. Analisar os riscos A Análise de Riscos identifica as ameaças mais prováveis de ocorrência, nalisando as vulnerabilidades encontradas na organização e possibilitando a tomada de decisão em relação aos riscos principais. Conhecendo os riscos principais pode-se tomar uma das seguintes medidas: Eliminá-los, Minimizá-los, Compartilhá-los ou Assumi-los. Conhecer e entender o relacionamento entre processos e ativos é fator de sucesso crítico e decisivo no processo de segurança da Informação. A metodologia pode ser dividida em três partes: reconhecimento (todas as informações sobre o ativo devem ser coletadas), análise (devem ser identificados os relacionamentos existentes) e classificação (baseada na verificação das ameaças, impactos, controles e riscos de cada ativo). O objetivo primário na recuperação de desastres é garantir a proteção dos ativos críticos frente a determinadas ameaças. Uma ameaça em potencial afeta diretamente aqueles ativos que estão mais expostos, e esta exposição é medida pelo grau de vulnerabilidade aquelas ameaças principais. Neste contexto, a análise de riscos entra em cena. Cada área funcional da organização deve ser analisada para determinar o risco potencial e o impacto relacionado a vários desastres ou ameaças, o que chamamos processo de análise de riscos.

As definições dos níveis de probabilidade e de impacto, as entrevistas com peritos e a avaliação da qualidade da informação disponível no projeto podem ajudar a corrigir as polarizações, que estão freqüentemente presentes nos dados usados neste processo. A análise qualitativa do risco deve ser revista durante o ciclo de vida do projeto, para ficar atualizada de acordo com as mudanças nos riscos do projeto. Mitigar os riscos É o processo de rastrear os riscos identificados, monitorar riscos residuais e até identificar novos riscos atrelados, assegurando a execução do Plano de Resposta aos Riscos e avaliando sua eficiência na redução dos mesmos. O processo registra as métricas que estão associadas com os planos de contingência e é considerado um processo contínuo no ciclo de vida do projeto. Os riscos evoluem enquanto o projeto é executado, uma vez que novos riscos previstos desaparecem. O objetivo é fornecer informações que suportam a tomada de decisão antes que eles ocorram. Comunicações para todas as partes interessadas são necessárias para avaliar periodicamente a aceitabilidade do nível de riscos no projeto. Este processo pode envolver a escolha de estratégias alternativas, a implementação de um plano de contingência ou de emergência, a tomada de ações corretivas ou o replanejamento do projeto. Inclui também, a inclusão de lições aprendidas nas bases de dados do projeto e modelos da gerência de risco para o benefício dos projetos futuros. Para controlar e gerenciar eficazmente os riscos durante o esforço de trabalho, deve ser seguido um programa pro ativo para monitorar regularmente os riscos e o status, além dos resultados das ações de acompanhamento dos riscos. A estratégia da gerência de riscos define os intervalos em que o status do risco deve ser revisado. Isto pode resultar na descoberta de novos riscos ou de novas opções de manipulação, que podem requerer o re-planejamento e a reavaliação. Em ambos os eventos, os limites de aceitação associados com o risco devem ser comparados com o status, para determinar a necessidade de execução do plano de mitigação de riscos. A prática específica de que trata esta monitoração é Implementar Planos de Mitigação de Riscos. Todas as abordagens indicam fortemente que os riscos devem ser monitorados e controlados durante todo o ciclo de vida do projeto através da reavaliação dos riscos e do acompanhamento dos indicadores. Artefatos Plano de Gerenciamento de Riscos é um artefato de saída da atividade de desenvolver o Plano de Gerenciamento de Riscos, que pertence ao fluxo de trabalho etalhado Planejamento do Projeto. Essa atividade tem como objetivo criar um plano documentado para identificação, análise e priorização dos riscos e identificar as estratégias de gerenciamento para os riscos mais relevantes do projeto. Os Papéis em um Projeto O Cliente - O cliente é o principal personagem, por ser a razão da existência do empreendimento. Dentre os critérios de sucesso de um projeto, certamente cliente satisfeito é o principal. O Gerente do Projeto - O gerente do projeto é o principal responsável pelo cumprimento da meta do projeto. Será através de sua positiva atuação que a equipe de execução conseguirá uma produtividade adequada, dentro de um ambiente de alto astral. Alta Administração - As altas administrações, tanto do cliente como do executor, são peças importantes neste cenário por possuírem uma visão macro de suas empresas

(missão, estratégia, políticas, etc). Elas participam quando do estabelecimento das metas do projeto e em momentos críticos do acompanhamento da execução do projeto. A Equipe do Projeto - Projetos podem envolver desde uma única pessoa a milhares. Podem envolver um único setor de uma empresa ou podem cruzar as fronteiras organizacionais e podem também implicar parcerias entre organizações. Fornecedores Externos - Sua importância reside no fato, muitas vezes, de serem responsáveis por parcelas significativas do projeto. Os Vizinhos da Projeto - Chama-se de vizinhos do projeto a indivíduos ou organizações não diretamente ligados ao projeto, mas cujos interesses podem ser positiva ou negativamente afetados com o resultado da execução do projeto ou do seu término com sucesso. Alguns exemplos: sindicatos, ambientalistas, políticos, imprensa, etc. Portanto, os vizinhos são todos aqueles que podem, eventualmente, influir na evolução do projeto. O gerente de projeto deve estar atento a estes personagens.