PRO_PP Processo de Planejamento do Projeto Reviso: 7 Aprovao: Daniella Gobira

1. Poltica Organizacional Estabelecer estimativas como base para executar o planejamento. Elaborar o Plano do Projeto de forma a permitir o gerenciamento do projeto para alcanar os compromissos estabelecidos com o cliente. Atualizar o Plano do Projeto sempre que houver mudanas atreladas a ele e garantir os comprometimentos dos stakeholders internos e externos. 2. Planejamento do Processo 2.1 Definio do Processo O objetivo do Processo de Planejamento do Projeto estabelecer e manter os planos que definem as atividades do projeto. Macro-atividade 1: Planejamento do Processo de Planejamento do Projeto Objetivo: Planejar o processo de Planejamento do Projeto, seguindo o estabelecido neste documento, mas especificando os stakeholders relevantes para o processo no projeto, como ocorrero as avaliaes dos artefatos do processo e os participantes, alm de estimativas de esforo para execuo das atividades do processo e respectivo cronograma. Responsvel: Gerente do Projeto. Artefato: Cronograma Inicial do Projeto na Proposta Aprovada e Anlise de Viabilidade Tcnica (RQ-7.5C). Macro-atividade 2: Planejamento do Projeto Objetivo: Estabelecer o escopo do projeto e, ento, elaborar os planos que definem as atividades do projeto. Atividade: Desenvolver Plano do Projeto y Descrio: Estabelecer e manter todos os planos que compem o Plano do Projeto(WP-PP-01), e que ser a base para a gerncia do projeto. Nesta etapa, o responsvel pelo Plano do Projeto providencia a integrao com os demais planos complementares citados nas sub-atividades a seguir, consolidando-os (planos gerados nos processos de CM, MA, PPQA e REQM).

Sub-Atividades:

y y

y y

Nome: Estabelecer ou Revisar o Escopo do Projeto Descrio: Estabelecer, a partir do Escopo do Produto (na Proposta Aprovada/Edital), as caractersticas e restries do projeto e identificar as oportunidades de reuso. Exemplos de caractersticas de projeto so: domnio de aplicao familiar e tecnologia de desenvolvimento familiar. Exemplos de restrio de projeto: restrio de cronograma e restrio de recursos. Responsvel: Gerente do Projeto. Artefato: Definio do Escopo do Projeto, no Plano do Projeto (WP-PP-01).

y y

Nome: Planejar Processo Descrio: Definir o Plano do Processo para o novo projeto, adaptando as atividades propostas no processo padro da empresa, quando necessrio, a partir do ciclo-devida definido na proposta. A justificativa de adaptao deve ser registrada.

y y

Responsvel: Gerente do Projeto. Artefato: Plano do Processo e Justificativa da Adaptao.

y y

y y

Nome: Estabelecer Estrutura Organizacional do Projeto Descrio: Realizar o planejamento da estrutura organizacional do projeto, identificando os stakeholders envolvidos, suas funes, assim como a relevncia e nvel de interao das atividades do projeto. Os Stakeholders responsveis pela elaborao dos planos so contatados por e-mail, de forma que possam iniciar as suas atividades no projeto para a reunio de Kickoff. Responsvel: Gerente do Projeto. Artefato: Estrutura Organizacional e Plano de RH.

y y

y y

Nome: Planejar Gerncia de Dados Descrio: Identificar as vrias formas de documentao necessrias para apoiar o projeto em todas as suas reas (administrativa, financeira, logstica, desenvolvimento etc.) e, para cada uma, especificar formato, mdia, pblico-alvo, forma de distribuio, alm do controle de acesso para os papis existentes na Fbrica de Software. A maioria das formas de documentao j est identificada no processo de desenvolvimento da organizao e tambm possui modelos que especificam o seu formato e contedo. Responsvel: Gerente do Projeto. Artefato: Plano de Gerncia de Dados.

y y y y y

Nome: Planejar Treinamento Descrio: Identificar os diferentes tipos de treinamento necessrios para que a equipe esteja apta a realizar as atividades requeridas pelo projeto em questo. Responsvel: Gerente do Projeto. Participantes: GRH, SEPG. Artefato: Plano de Treinamento.

y y y y

Nome: Planejar ou Revisar Recursos em Geral Descrio: : Identificar ou revisar os recursos em geral (equipamentos, materiais, infraestrutura, etc.) necessrios ao projeto. Responsvel: Gerente do Projeto. Artefato: Plano de Recursos.

y y y y

Nome: Planejar Riscos Descrio: Identificar, analisar e avaliar os riscos do projeto. Responsvel: Gerente do Projeto. Artefato: Plano de Riscos.

y y

y y

Nome: Planejar Esforo e Custo Descrio: Gerar o planejamento de esforo e custo do projeto, a partir dos valores da estimativa de esforo e custo do Projeto, contidos na Anlise de Viabilidade Tcnica, realizada no Levantamento Preliminar. Distribuir o esforo e custo estimado entre as fases do projeto. Responsvel: Gerente do Projeto. Artefato: Plano de Esforo e Custo do Projeto (RQ-7.3BO).

y y y

Nome: Estabelecer ou Revisar Cronograma Descrio: Utilizar o Cronograma da Proposta e o Plano de Esforo e Custo do Projeto para gerar o cronograma inicial do projeto. Responsvel: Gerente do Projeto.

Artefato: Calculo de Tamanho do Projeto (RQ-7.3K) e Cronograma do Projeto (WPPP-03), no Plano do Projeto.

y y

y y y

Nome: Realizar Reunio de Kick Off e Elaborar Planos Complementares Descrio: Apresentar aos envolvidos internamente (PPQA, Gerente de Configurao e Analista de Sistemas designado) a definio do escopo do produto e obter deles um comprometimento com o produto. Durante esse contato, o Gerente de Projetos apresenta o Plano do Projeto para que os responsveis pelos planos complementares elaborem seus planos e/ou atividades e informem as datas de execuo das suas atividades para que o cronograma esteja completo. Responsvel: Gerente do Projeto. Participantes: Responsveis pela Elaborao dos demais planos. Artefato: Registro de Comprometimento (WP-02) com a definio do escopo do produto, na Proposta Aprovada; Plano de Gerncia de Requisitos , Plano de Gerncia de Configurao, Plano de PPQA, Plano de Monitorao e Controle do Projeto e Plano de Medio e Anlise do Projeto, que sero consolidados no Plano do Projeto.

y y

y y y

Nome: Consolidar Plano de Projeto Descrio: Consolidar os planos gerados nesta atividade de forma a constiturem o Plano do Projeto como um todo, revisando tambm, de acordo com o Plano do Projeto, o Plano de Gerncia de Requisitos, Plano de Garantia da Qualidade do Produto e do Processo, Plano de Monitorao e Controle , Plano de Medio e Anlise e Plano de Gerncia de Configurao. Responsvel: Gerente do Projeto. Participantes: Responsveis pela Elaborao dos demais planos. Artefato: Plano do Projeto Consolidado (Plano de Riscos + Plano do Processo + Estrutura Organizacional e Plano de RH + Plano de Gerncia de Dados + Calculo de Tamanho do Projeto + Plano de Esforo e Custo do Projeto + Cronograma do Projeto + Plano de Treinamento + Plano de Recursos) e demais planos complementares.

Atividade: Obter Comprometimento com o Plano do Projeto y y Descrio: Estabelecer o comprometimento dos participantes envolvidos com o Plano do Projeto. Sub-Atividades:

y y

y y y

Nome: Avaliar o Plano do Projeto Descrio: Avaliar o Plano do Projeto e realizar as adequaes e ajustes necessrios. O objetivo da avaliao validar se os recursos planejados so suficientes e se esto disponveis, consolidando as responsabilidades e garantindo a integridade entre o Plano do Projeto, os planos complementares, artefatos e demais documentos relacionados a ele. Qualquer inadequao identificada corrigida pelo Gerente do Projeto para poder obter o comprometimento dos stakeholders com o Plano do Projeto. Responsvel: Gerente do Projeto. Participantes: Stakeholders internos. Artefatos: Plano do Projeto avaliado, Registro de Avaliao e Comprometimento com o Plano do Projeto (WP-01.1).

y y

y y

Nome: Registrar Comprometimento do Cliente com o Plano do Projeto Descrio: Obter, dos participantes envolvidos, comprometimento com o Plano do Projeto (a equipe se compromete com o Plano do Projeto integral e o cliente apenas com a sua viso do documento). Com esta atividade, o Plano do Projeto est aprovado e submetido Gerncia de Configurao. Responsvel: Gerente do Projeto. Participantes: Stakeholders Internos (Plano do Projeto), Stakeholders do Cliente (Plano do Projeto viso do cliente).

Artefatos: Plano do Projeto aprovado, Registro de Comprometimento com o Plano do Projeto e Plano do Projeto viso do cliente (WP-PP-01.1) aprovado.

y y y y

Nome: : Registrar Situao do Projeto (Milestone) Descrio: Registrar e disponibilizar a situao do projeto para os stakeholders. Caso necessrio, o Plano do Projeto refinado para a prxima fase. Responsvel: Gerente do Projeto. Participantes: Gerente da Fbrica de Software, Gerente de Sistemas, Coordenao do SEPG, Stakeholder do Cliente, representantes da GCO e Equipe da Fbrica de Software. Artefatos: E-mail de Milestone e Plano do Projeto Refinado.

3. Recursos Para executar este processo so necessrios: y Pessoal treinado conforme o item 5.

4. Responsabilidade As responsabilidades por cada atividade do processo esto identificadas no item (Definio do Processo). 5. Treinamento Para execuo deste processo os profissionais envolvidos em suas atividades so treinados em: y Gerente da Fbrica de Software: o Introduo ao CMMI; o PRO_PP Processo de Planejamento do Projeto; o IT-PRO-11 Planejamento do Projeto; Gerente do Projeto, Lderes: o Introduo ao CMMI; o PRO_PP Processo de Planejamento do Projeto; o IT-PRO-11 Planejamento do Projeto; o Ferramentas: CaMMIla (Viso de Planejamento do Projeto). Analista de Sistemas, Codificador, Homologador e Documentador: o Introduo ao CMMI; o PRO_PP - Processo de Planejamento do Projeto. Avaliadores dos Planos: o Introduo ao CMMI; o PRO_PP Processo de Planejamento do Projeto; o IT-PRO-11 Planejamento do Projeto. Grupo de Garantia da Qualidade do Produto e do Processo (PPQA): o Introduo ao CMMI; o PRO_PP Processo de Planejamento do Projeto; o IT-PRO-11 Planejamento do Projeto;

6. Stakeholders Relevantes Os stakeholders relevantes para a execuo do processo esto identificados no item 2.1 (Definio do Processo). 7. Monitorao e Controle do Processo A monitorao e controle do processo so realizados atravs de:

1. Mtricas de monitorao do processo definidas no documento de Medio e Anlise (IT-PRO-13). 2. O Gerente do Projeto avalia a adequao do processo durante a execuo do projeto. O SEPG avalia a viabilidade das sugestes / oportunidades de melhoria detectadas no decorrer de um projeto. 3. Avaliao de Encerramento do Projeto A equipe da Fbrica de Software envolvida no projeto, conduzida pelo Gerente do Projeto, avalia o processo, ao final da ltima macro-atividade, preenchendo um questionrio. Essas informaes so sintetizadas pelo Gerente do Projeto e transmitidas aos Stakeholders relevantes atravs de e-mail ou Reunio de Encerramento de Projeto. 8. Avaliao Objetiva da Aderncia ao Processo A aderncia aos processos avaliada pelo PPQA, periodicamente, conforme definido no documento de Garantia da Qualidade do Produto e do Processo (IT-PRO-6), quando avaliada a aderncia a todos os processos, utilizando checklists pr-definidos. As atividades realizadas pelo PPQA so avaliadas por auditores externos ao PPQA para se garantir a objetividade necessria, tambm utilizando checklists. 9. Reviso do Status do Processo com a Gerncia Snior A Reviso do Status do Progresso do Processo de Planejamento do Projeto ocorre conforme descrito no item 9 do Processo de Monitorao e Controle.

IT-PRO-11 Planejamento do Projeto Reviso: 10 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para atender ao Processo de Planejamento do Projeto (PRO_PP). 2. Executante da Tarefa Gerente do Projeto; Gerente Funcional; Lderes e Equipe do Projeto. 3. Documentos Complementares y y y y y y y y PRO_PD Processo de Desenvolvimento; PRO_PP Processo de Planejamento do Projeto; PQ-4.2 - Controle de Documentos e Registros da Qualidade; IT-COM-2 Levantamento Preliminar; IT-PRO-10 Controle de Mudanas; IT-PRO-14 Monitorao e Controle do Projeto; LISTA-FBRICA DE SOFTWARE Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

4. Recursos Necessrios y y CaMMIla; MS-Project.

5. Atividades Principais Descrever como realizado o planejamento do projeto e como so estabelecidos e mantidos os planos que definem as atividades do projeto.

O Plano do Projeto (WP-PP-01), seus sub-planos e os planos complementares so desenvolvidos, controlados, analisados, corrigidos, aprovados e armazenados em repositrio controlado pela ferramenta CaMMIla. O CaMMIla possui um mdulo de Planejamento do Projeto que permite otimizar as atividades de desenvolvimento dos planos e recuperao das diversas verses dos mesmos. A forma de preenchimento dos planos complementares est descrita em suas respectivas instrues de trabalho, que referenciam cada rea de Processo especfica. 5.1 Iniciar Projeto O projeto iniciado a partir do momento que o negcio fechado pela GCO, o comprometimento com o escopo do produto adquirido atravs da proposta aprovada pelo cliente ou edital para o caso de licitao. O Diretor de Tecnologia e Servios recebe da Coordenao de Medio e Contratos (CMC) a Autorizao para a Realizao de Servios (RQ7.2F). Nesse momento solicita que o repositrio do projeto seja criado e armazena a Proposta Tcnica (RQ 7.2C.4) ou Edital, Autorizao para a Realizao de Servios (RQ7.2F), Clculo de Tamanho do Projeto (RQ7.3K) e Anlise de Viabilidade Tcnica (RQ7.5C). O Ncleo de Gerncia de Projetos (NGP) avisado por e-mail sobre a disponibilizao dos registros e a partir da define quem ser o Gerente de Projeto responsvel pelo novo projeto. Assim que o Gerente de Projetos definido, acontece a reunio inicial interna, que realizada entre o Gerente Funcional, Gerente de Sistema de Informao e Gerente do Projeto. Caso o Gerente do Projeto julgue necessrio, o analista de pr-venda tambm participa dessa reunio para discutir o escopo do projeto. A partir do documento Clculo do Tamanho do Projeto, que fornece os papis necessrios para compor o projeto, o Gerente do Projeto juntamente com o Gerente Funcional faz o planejamento inicial de recursos humanos necessrios. Levantam as competncias e habilidades necessrias para a equipe a partir do Escopo da Proposta Tcnica/Edital. A disponibilidade de equipe interna para atender a demanda do novo projeto verificada nesse momento. Caso no tenha recursos internos disponveis, o Gerente Funcional sinaliza a Coordenao de Gesto de Pessoas (CGP), que baseado nas especificaes do perfil solicitado, segue o procedimento de Recrutamento, Seleo e Contratao de Profissionais (ITGRE-4). Essas informaes so registradas na memria de reunio, assim como a data limite para as novas contrataes. Uma reunio inicial com o cliente realizada com a finalidade de apresentar o Gerente do Projeto. Alm disso, a definio do escopo do produto, disponibilizada na Proposta Tcnica lida e informaes sobre os Stakeholders do cliente envolvidos no projeto so obtidas. O Gerente do Projeto apresenta a Metodologia de Desenvolvimento utilizada pela AVANSYS, ressaltando a importncia do envolvimento e comprometimento, tanto dos Stakeholders internos quanto os do cliente, com a documentao gerada para o projeto (memrias de reunio, especificao de requisitos, etc.), pois ela reflete cada item que ser implementado no Software. Durante esta reunio, os comprometimentos necessrios ao projeto j podem ser negociados com o cliente e alguns possveis riscos j comeam a ser identificados. No obrigatrio o comprometimento do cliente com os Modelos de Anlise e com o Projeto Tcnico, ficando a cargo do Gerente de Projeto, durante essa reunio documentar a opo do cliente perante esta possibilidade. Essas atividades que antecedem o incio da fase de Planejamento do Projeto tambm esto especificadas no PRO-PD na fase Entrada do Projeto Aprovado na FSW. 5.2 Planejar o Processo As informaes importantes para o Planejamento do Processo de Planejamento do Projeto encontram-se especificadas no Clculo do Tamanho do Projeto, que contm o tamanho e o custo estimados para o projeto e o percentual de esforo por fase, esse documento criado na fase de Levantamento Preliminar (IT-COM-2). 5.2.1 Criar um Projeto no CaMMIla

Para adicionar um projeto no CaMMIla, o Gerente do Projeto segue os passos especificados abaixo: 1. Acessar o sistema atravs do endereo: http://cammila.avansys.com.br 2. Aps digitar login e senha do sistema, dirija-se ao Menu Cadastro e clique em Projeto; 3. Na tela de Consulta de Projetos, clique no cone 4. Preencha os seguintes campos especificados em Cadastro de Projetos: 1. Nome do Projeto: informe o nome que o projeto adotar. Padro: <Nome do Cliente> <Nome do Projeto>. 2. Repositrio: informe o caminho para acessar o repositrio do sistema. O caminho do repositrio informado nesse campo no deve conter o incio do endereo (https://svn.avansys.com.br/). 3. Processo: escolha o processo que ser utilizado para o desenvolvimento do projeto. O modelo do ciclo de vida utilizado o especificado no plano do projeto. 4. Mtrica: escolha qual a mtrica utilizada para estimar o tamanho do projeto. 5. Status: Status do projeto em questo (No iniciado, Andamento, Finalizado, Pendente, Cancelado); 5. Clique em Salvar. OBS: Caso o cliente possua ou especifique a necessidade do seguimento de alguma metodologia diferente da utilizada pela Avansys, necessrio avaliar se h a necessidade de criar algum artefato ou parte para que o projeto permanea aderente aos processos da organizao que seguem o modelo CMMI no Nvel 2. Nesse caso, no ser necessrio seguir o processo do cliente e da empresa, mas ser preciso complementar o que faltar para atender as prticas e mant-lo aderente ao modelo. O processo a ser seguido pelo projeto - podendo ser, parte da metodologia do cliente e parte da Avansys deve estar registrado na Proposta Tcnica/Edital para que o Gerente de Projeto tenha a viso do Processo a ser seguido e para que o PPQA saiba o que verificar e como acompanhar. Caso isso ocorra, todo artefato no previsto, que no faa parte da Gerncia de Dados do Processo de Desenvolvimento padro da Avansys deve ser planejado durante o Plano do Projeto, gerado e controlado pelo Gerente de Projeto. Aps criao do projeto no CaMMIla, o Gerente de Projetos designado est apto a iniciar o Plano do Projeto. 5.3 Gerar Plano do Projeto Nesse momento o Gerente de Projeto d incio criao do Plano do Projeto seguindo todas as atividades descritas no PRO-PP. Para gerar o plano necessrio acessar o Menu Projeto opo Plano. No campo Projeto em uso selecione o projeto desejado. Quando o projeto criado, a primeira verso do plano criada automaticamente pelo sistema. Clique no cone do Plano do Projeto. 5.3.1 - Plano do Projeto Neste item informada a verso do Plano e o comentrio da verso gerada. Ao final do preenchimento do Plano o mesmo dever ser bloqueado e passa a ter suas verses controladas. Em casos de alterao em um Plano do Projeto que esteja bloqueado o campo comentrio dever ser preenchido com informaes que esclaream o que foi alterado de uma verso para outra. 5.3.2 - Definio de Escopo do Projeto Neste item preenchida a descrio do projeto a partir da proposta aprovada/edital ,com informaes como: y y Natureza do projeto (ex: desenvolvimento ou manuteno); Descrio do software a ser desenvolvido; para complementar as informaes

y y y y y y y

Tipo do software (ex: web ou cliente-servidor); Paradigma (ex: orientado a objeto ou orientado a aspectos); Linguagem de programao (ex: JAVA, ASP, .NET); Banco de dados (ex: Oracle, SQL); Sistema operacional do servidor de aplicao (ex: Linux); Sistema operacional do servidor de banco de dados (ex: Windows 2000 Server); Servidor de aplicao (ex: TOMCAT 4).

As caractersticas gerais do projeto so selecionadas dentre as opes disponibilizadas na ferramenta para complementar a etapa de definio de escopo do projeto. Essas caractersticas so definidas no cadastro de processos na opo Perguntas. 5.3.3 - Planejar o Processo A Avansys possui um processo de desenvolvimento que conduz os seus projetos, o ciclo-devida e as fases que acontecem. Desta forma, quando o Gerente do Projeto estiver criando o Plano do Projeto pode visualizar, atravs do PRO_PD - Processo de Desenvolvimento, todas as fases e atividades do processo, garantindo assim a execuo do planejamento do processo. Caso alguma fase, atividade e/ou artefato do processo definido para a empresa no seja seguida para um projeto especfico, o Gerente de Projetos antes de fazer a adaptao, verifica com o SEPG para assegurar que as adaptaes a serem realizadas so permitidas e que o projeto continuar aderente ao modelo CMMI nvel 2. Aps validao do SEPG o GP registra a justificativa para adaptaes na metodologia utilizada pela Avansys, e/ou alteraes/excluses de atividades e modelos de artefatos utilizados. A justificativa de adaptao deve ser registrada no campo especfico, na aba Plano de Projeto no CaMMIla. 5.3.4 - Estabelecer Estrutura Organizacional do Projeto Neste tpico, a estrutura organizacional e o envolvimento dos stakeholders que compem o projeto so formados. Para isso, o Gerente do Projeto verifica com o Gerente Funcional o planejamento de recursos elaborado no incio do Projeto para compor a equipe interna. Caso tenha sido necessria contratao externa, o Gerente Funcional acompanha o andamento do processo junto a CGP at que o mesmo seja concludo e a equipe do projeto esteja completa. O Gerente do Projeto informa o nome e tipo do profissional que far parte do projeto. Para isso acessa a aba RH do Plano do Projeto e adiciona todos os profissionais. Aps preenchimento das informaes solicitadas, o Gerente do Projeto clica em Salvar. Todos os profissionais que fazem parte do projeto tm que ser cadastrados, formando a estrutura organizacional, com o envolvimento dos stakeholders nas diversas atividades desempenhadas e o plano de recursos humanos do projeto. Nesse momento, o GP envia um email aos Stakeholders responsveis pela elaborao dos planos informando a data da reunio de Kick off. 5.3.5 - Gerncia de Dados O Plano de Gerncia de Dados feito durante o planejamento do processo, e traz todos os artefatos gerados para o projeto em questo e o controle de acesso para os demais papis existentes na Fbrica de Software. A localizao dos artefatos definida na lista de registro da FSW, no DOC. Os documentos gerados ao longo do projeto devem ser armazenados com a nomenclatura original, sem adicionar ao nome, o nmero da Avp, nome do cliente ou nome do projeto. Ex.: RQ-7.3K - Clculo do Tamanho do Projeto.xls. O arquivo deve ser armazenado no repositrio com esse mesmo nome, o que indica a qual projeto ele pertence o seu local de armazenamento (repositrio do projeto no SVN) e contedo (cabealho). Os nicos artefatos que contm informaes adicionais em seus ttulos so as memrias de reunies e cronogramas.

As memrias de reunies devem ser salvas com a fase e data em que ocorreram. Exemplo: RQ-7.3B - Memria de Reunio - Levantamento Preliminar - aaaammdd.doc A indicao da fase opcional. O cronograma do projeto deve ser salvo incluindo o nome do cliente e nome do projeto. Exemplo: WP-PP-03 - Cronograma do Projeto - cliente - projeto.mpp O backup dos artefatos produzidos realizado conforme rotina de backup da empresa (ITPRO-3 Backup de Arquivos). A Fbrica de Software possui ainda uma lista de registros e artefatos com a descrio de todos os artefatos, indicao do local de armazenamento, proteo, recuperao, tempo de reteno e descarte. Os modelos de registro so disponibilizados na ferramenta de armazenamento dos documentos da qualidade (http://doc.avansys.com.br). Quando o cliente solicita adaptaes nos templates, por exemplo a incluso da logomarca, as alteraes so realizadas e os modelos so disponibilizados para a equipe em um repositrio prprio. Caso seja identificada a necessidade de utilizao de artefatos do cliente, ou outros que no faam parte da Lista de Artefatos da Fbrica de Software, o plano de gerncia de dados dever ser atualizado. O Gerente do Projeto fica responsvel por obter, armazenar e gerenciar a utilizao desses artefatos. OBS: Os emails que so representativos para o projeto, devem ser armazenados no repositrio do projeto no SVN na pasta 00-Documentacao. 5.3.6 - Plano de Treinamento Nesta etapa do plano so definidos os treinamentos necessrios para realizar as fases de desenvolvimento, implantao, uso e manuteno do produto. O gerente do projeto informa os lderes de equipes sobre a tecnologia e necessidades do projeto para que os mesmos verifiquem as necessidades de treinamento de suas equipes, havendo necessidade de treinamento o Gerente Funcional comunicado para que notifique a Coordenao de Gesto de Pessoas (CGP) conforme definido no processo Qualificao de Profissionais (PQ-6.2). O Gerente Funcional repassa as informaes para o Gerente de Projeto elaborar o plano de treinamento do projeto. So informados: o tipo de treinamento (qualificao profissional ou da qualidade), data incio e fim do treinamento, a carga horria necessria, o local (se interno ou externo), o responsvel (profissional que ir ministrar o treinamento) e os profissionais que participaro do treinamento mencionado. Alm de treinamentos tcnicos, o Gerente de Projetos deve identificar tambm se h necessidade de treinamentos para os processos e instrues de trabalho para a rea de desenvolvimento definidos pela empresa. Ele consulta o SEPG com o objetivo de verificar se existe algum treinamento planejado para novos funcionrios da fbrica ou se novas revises dos documentos foram geradas para que a equipe possa atualizar os treinamentos. Caso o SEPG tenha algum treinamento programado, o GP deve planej-lo no cronograma com os recursos envolvidos. Se no houver programao de treinamento e no decorrer do projeto ocorrerem revises significativas, ou seja, que impactem nas atividades do dia-a-dia, o SEPG sinalizar o GP para que ele atualize o cronograma com o planejamento dessa atividade. Caso no seja necessria a realizao de treinamentos para a equipe, o GP clica no boto No utilizar plano de treinamento e na visualizao do documento Plano do Projeto, este item preenchido com o status de No houve necessidade de treinamento. 5.3.7. Planejar ou Revisar Recursos em Geral preenchido com informaes a respeito de recursos extras que so disponibilizados para o projeto e que no constam no item 6. RECURSOS do Processo de Desenvolvimento (PRO_PD) e que no foram levados em considerao no clculo do custo do profissional para a empresa, mas que so de importncia fundamental para a execuo do projeto. O preenchimento ocorre da seguinte forma: seleo do tipo do recurso, descrio do recurso

(finalidade da utilizao do mesmo), quantidade, data em que o recurso mencionado estar disponvel para o projeto em questo. Existem trs tipos de recursos a serem contabilizados neste tpico: 1. Recursos de hardware - Ex: Leitor tico, Impressoras especficas, Computadores adicionais e etc; 2. Recursos de software Ex: Ferramentas, Licenas de Software e de Banco de Dados e etc; 3. Outros recursos Ex: materiais especficos para o projeto que no se encaixem nos recursos de hardware e software. Os recursos de hardware e software padro para cada perfil de profissional da empresa encontram-se disponveis no documento de Hardware e Software das Estaes de Trabalho (RQ-7.3O), de responsabilidade do Suporte Tcnico Caso no seja necessrio recursos extras para o projeto, o GP clica no boto No utilizar plano de recursos, na visualizao do documento Plano do Projeto impresso, este item preenchido com o status de No houve necessidade de novos Recursos. 5.3.8. Planejar Risco Nesta etapa do plano so definidos e avaliados os riscos identificados como passveis de acontecimento no decorrer do projeto. Para isso o gerente utiliza como base a proposta tcnica, o preenchimento da definio do Escopo do Projeto, informaes levantadas na reunio inicial do cliente e avaliao das demais informaes que possui sobre o projeto. Nesse momento so informados: y y Categoria - Identificao do grupo a que pertence o Risco. Alguns riscos podem ter mais de uma categoria mas devemos utilizar a com maior relevncia; Risco - Descritivo da Fonte de Risco identificado, que pode ser interno ou externo. O cadastro dos riscos listados nesse campo feito atravs do menu Cadastro, submenu Risco; Probabilidade Atribuir valor de acordo com o provvel nvel de ocorrncia do Risco identificado: o Alta caso a probabilidade do Risco ocorrer seja superior ou igual a 70%; o Mdia - caso a probabilidade do Risco ocorrer esteja compreendida entre 69% e 30%; o Baixa - caso a probabilidade do Risco ocorrer seja inferior a 30%. Impacto Atribuir valor de acordo com o nvel de impacto, caso o Risco ocorra: o Alto caso o Risco identificado afete diretamente o andamento do projeto, chegando a incidir em atraso no cronograma ou aumento de custos ou inviabilizao de comprometimentos; o Mdio caso o Risco afete diretamente o andamento do projeto, mas possa ser resolvido sem acrscimo de tempo ou custo para o projeto; o Baixo caso o Risco no afete diretamente o andamento do projeto ou a execuo das atividades do mesmo. Grau - Identificao do Grau de Exposio do Risco, obtido por Probabilidade X Impacto, que define aes para o tratamento de cada Risco; o Baixo (Verde) - Classifico menor que 4 Podem ou no ter ao de contingncia estabelecida. Podem ser aceitos; o Mdio (Amarelo) - Classificao menor que 6. Podem ser aceitos embora devam preferencialmente ser evitados ou mitigados; o Alto (Vermelho) - Classificao acima de 6. No devem ser aceitos exceto quando no exista possibilidade de outra ao ou o custo da mesma inviabilize sua adoo. Devem ter plano de contigncia e possui acompanhamento com menor periodicidade. Responsvel - Responsvel pelo acompanhamento do Risco. O GP ser responsvel por todos os riscos do projeto, em algumas situaoes especficas este poder direcion-lo para um dos stakeholders internos ou externos; Estratgia - refere-se a maneira como o risco ser conduzido no projeto: o Aceitar o Aumentar o Compartilhar o Evitar

y y y

o Mitigar o Transferir o Explorar Gatilho - Circunstncia em que ser acionada a Ao de Resposta ao Risco. Um Gatilho pode ser por exemplo uma data, %, valor, etc. Ao - Definio de aes/atividades para mitigar o risco ou para contingncia caso o risco ocorra. Uma Ao pode ter vrias atividades/datas. Contingncia - tem o objetivo de descrever as medidas a serem tomadas pelos responsveis, incluindo a ativao de processos manuais, para fazer com que seus processos vitais voltem a funcionar plenamente, ou num estado minimamente aceitvel, o mais rpido possvel, evitando assim uma paralisao prolongada que possa gerar maiores prejuzos empresa. Data Limite - Para executar a ao de resposta ao risco, caso tenha sido disparado.

5.3.9. Planejar Esforo e Custo Com base nos valores da estimativa de esforo e custo do Projeto (na Anlise de Viabilidade Tcnica e Clculo do Tamanho do Projeto), o Gerente do Projeto elabora o Cronograma do Projeto (WP-PP-03). Nele estar a estimativa de esforo dos profissionais alocados no projeto. Nesse primeiro momento a alocao feita para os lderes das equipes que posteriormete delegaro as atividades para a equipe. O esforo multiplicado pelo custo mensal dos lderes. Caso o custo do projeto ultrapasse o valor informado no oramento do projeto (Clculo do Tamanho do Projeto RQ-7.3K) a Diretoria de Tecnologia e Servios dever ser informada. possvel que o Gerente Projetos utilize um valor de produtividade diferente do utilizado pelo Analista de Pr-Venda no Levantamento Preliminar, para isso necessrio um racional que justifique tal mudana. O mesmo vlido para alteraes na diviso do esforo pelas fases do projeto. Caso ocorram essas mudanas, o racional deve ser registrado. Quando o projeto iniciado, o Gerente do Projeto utiliza este documento como base para a monitorao e controle de esforo e custo do projeto Esse artefato armazenado no repositrio do projeto no SVN. Os custos como: viagens, licenas extras, necessidades de treinamentos, mesa, cadeira, computador, licenas padro para cada perfil, ar condicionado, luz, telefone, aluguel de sala e etc, foram padronizados e j se encontram incutidos no custo de ambiente calculado para cada profissional da Fbrica de Software. 5.3.10. Estabelecer ou Revisar Cronograma O Cronograma do Projeto (WP-PP-03) gerado no MS-Project e contm todas as datas das realizaes das atividades do projeto, incluindo o monitoramento e controle, as geraes das baselines e as datas de coleta e anlise das mtricas adotadas. Para elaborar o cronograma do projeto, o Gerente do Projeto revisa o cronograma da Proposta Tcnica considerando as seguintes premissas: 1. A mdia de horas produzidas pelos profissionais da fbrica de software de 08h00min por dia; 2. A disponibilidade da equipe tambm levada em considerao, j que o nmero de profissionais estimado na pr-venda pode no estar disponvel. 3. As datas de reviso da situao do projeto (Milestones) so planejadas para as fases de Planejamento do Projeto, Levantamento de Requisitos, Anlise de Requisitos, Projeto Tcnico do Software, Codificao e Teste Unitrio, Integrao e Teste e Encerramento do projeto. Obs: Sempre que uma fase for adiantada, sendo iniciada antes da concluso da anterior (exceto para as fase de codificao e homologao que acontecem em paralelo em um determinado momento), deve ser planejada uma atividade para anlise de impacto e retrabalho que esse trabalho em paralelo poder causar. Se houver algum impacto, o mesmo deve ser registrado no planejamento da prpria atividade e planos de aes podero ser criados, caso contrrio deve ser registrado a anlise feita na prpria tarefa e encerr-la.

Para gerar o cronograma no MS Project, o Gerente de Projeto deve serguir os seguintes passos: Acessar o DOC (http://doc.avansys.com.br) e na pgina principal, clicar em ndice, na rvore acessar o caminho: Base Conhecimento | GSI | Miscelaneas | Mapa Importao Exportao fazer o download do arquivo Mapas_CaMMMIla.mpp. Executar o arquivo Mapas_CaMMIla.mpp, o MS Project ser executado, em seguida acesse o menu Ferramentas | Organizador | Mapas, copie os arquivos CaMMIla Export e CaMMIla Import do campo Global.MPT para o campo Mapas CaMMIla.mpp, feche o project. Abrir o WP-PP-03 - Cronograma do Projeto e incluir a coluna Texto 30. Essa coluna indica as tarefas que sero exportadas para o sistema CaMMIla. O Gerente do Projeto deve incluir um s em cada tarefa que ser exportada para o CaMMIla.

Na coluna Nome dos Recursos deve ser informado o login de rede do profissional responsvel pela tarefa. O profissional deve estar includo no Plano de RH do projeto. Caso o profissional no esteja no plano de RH o CaMMIla far a importao das tarefas porm o campo que indica o responsvel pela tarefa ficar em branco e o Gerente do Projeto dever fazer manualmente a incluso do responsvel em cada uma das tarefas. Quando o cronograma estiver completo, com todas as informaes pertinentes, feita a importao do mesmo no CaMMIla, alimentando o sistema com as tarefas e suas datas planejadas. Antes da importao, ainda no MS Project, o Gerente do Projeto salva o arquivo como .TXT, nesse momento o Assistente para exportao ser aberto. Siga as instrues conforme mostrado nas figuras abaixo:

y y

Clicar na opo Avanar Selecionar a opo Usar mapa existente e em seguida clicar na opo Avanar Selecionar a opo CaMMIla Export e em seguida a opo Concluir

O arquivo salvo no formato .txt contm as informaes que sero levadas para o sistema CaMMIla. Para fazer a importao deste arquivo no CaMMIla, o Gerente de Projetos acessa o menu Cadastro opo Importao de Tarefa, no combo localizado no topo da pgina o GP seleciona o projeto desejado. Observao: O plano do Projeto deve estar bloqueado antes que a importao seja feita. Na tela de importao o GP clica no boto Pesquisar e localiza o arquivo .txt gerado atravs do MS Project, em seguida clica no boto Importar. Aps a realizao da importao, os stakeholders utilizam o CaMMIla como guia de suas tarefas. A visualizao das mesmas pode ser feita de duas formas: atravs da pgina inicial do CaMMIla, onde apenas as tarefas e sub-tarefas do usurio logado so exibidas ou, no menu Projeto opo Tarefa onde todas as tarefas do cronograma so exibidas. Depois de importar as tarefas, o CaMMIla envia um e-mail para todos os profissionais responsveis pelas tarefas importadas. Os lderes das equipes de Anlise, Projeto Tcnico, Codificao e Testes devem criar as subtarefas para suas equipes, para isso seguir o documento Como Utilizar o Mdulo de Tarefas do CaMMIla. 5.3.11. Realizar Reunio de Kick off e Elaborar Planos Complementares Aps a elaborao do Plano do Projeto, o Gerente de Projetos est apto a realizar a reunio de lanamento do projeto (reunio de Kick off) que tem como participantes os stakeholders internos relevantes ao Projeto: o responsvel por MA, o Gerente do Projeto responsvel por PP

e PMC, o Analista de Sistemas responsvel pela Gerncia de Requisitos, o Gerente de Configurao e o PPQA. Durante essa reunio, os Planos Complementares ao Plano do Projeto so elaborados para que seja possvel a consolidao do mesmo, ou seja, os Planos de Gerncia de Requisitos, Gerncia de Configurao, PPQA, Medio e Anlise e Monitorao e Controle so desenvolvidos durante a reunio, afinando as datas que j so levadas como sugesto (exceto para o Gerente de Configurao) e o envolvimento dos stakeholders em cada atividade definida. Aps a consolidao do Plano do Projeto, o mesmo avaliado quanto viabilidade do cronograma e cumprimento das tarefas. Alm disso, realizada a consolidao das responsabilidades evitando possveis inconsistncias e realizando os ajustes necessrios. Para isso, os stakeholders internos relevantes preenchem o Registro de Avaliao e Comprometimento com o Plano do Projeto (WP-01.1) e neste mesmo documento, o Gerente do Projeto se encarrega de obter o comprometimento de todos com o que foi definido no Plano do Projeto. Essa reunio documentada em Memria de Reunio. 5.3.12. Consolidar Plano de Projeto O Plano consolidado aps a reunio de Kick off quando o Gerente de Projeto ter todos os planos complementares que compor o Plano do Projeto. feito a reviso do Plano de Gerncia de Requisitos (WP-REQM-01), Plano de Garantia da Qualidade do Produto e do Processo (WP-PPQA-01), Plano de Monitorao e Controle (WP-PMC-04), Plano de Medio e Anlise (WP-MA-01) e Plano de Gerncia de Configurao (WP-CM-01). 5.4 Avaliar o Plano do Projeto Durante todo o processo de desenvolvimento, o Plano do Projeto pode ser alterado, pois durante as atividades de Monitorar Andamento do Projeto (realizadas conforme IT-PRO-14 Monitorao e Controle do Projeto), as informaes planejadas (contidas no Plano do Projeto) so comparadas com o progresso e desempenho real do projeto, possibilitando assim o refinamento do documento para a prxima macro-atividade. Contudo, aps os comprometimentos com o plano obtido atravs do Registro de Avaliao e Comprometimento com o Plano do Projeto, o mesmo bloqueado pelo Gerente do Projeto, dando um clique no boto , que est na opo Plano do Projeto. Com este bloqueio, o Gerente do Projeto garante que a verso bloqueada no pode ser mais alterada, apenas versionada (se necessrio). Para que uma nova verso do Plano do Projeto seja criada, o Gerente do Projeto desbloqueia o artefato em questo e justifica no CaMMIla o motivo da necessidade de criar uma nova verso do mesmo. Essa atitude referencia o Controle de Mudana (IT-PRO-10) realizado nos Planos. O Gerente do projeto valida se o que tem para ser entregue est de acordo com os recursos que tem disponvel para a entrega, rev o planejamento do cronograma, e alocao e desempenho dos profissionais, se necessrio inserir novos recursos no projeto ou balancear com perfis juniores, pleno e snior. Sendo necessrio contratao de novos recursos o RH acionado e o fluxo ocorre de acordo com o procedimento descrito em Estabelecer Estrutura Organizacional do Projeto. Isso feito antes da prxima atividade Registrar comprometimento com o Plano do Projeto, onde Plano considerado Aprovado e submetido Gerncia de Configurao aps ter sido bloqueado pelo GP. 5.5 Registrar Comprometimento com o Plano do Projeto Existem dois tipos de comprometimento com o Plano do Projeto: o comprometimento interno obtido junto aos envolvidos internamente e o comprometimento com os stakeholders do cliente. O comprometimento interno obtido aps a reunio de Kickoff conforme descrito nessa atividade. Para obteno do comprometimento dos stakeholders do cliente, o Gerente do Projeto cria o Plano do Projeto Viso do Cliente (WP-PP-01.1) para que os mesmos possam se comprometer sem ter acesso s informaes confidenciais da empresa ou irrelevantes para o cliente, que se encontram na verso integral do documento.

OBS: A equipe se compromete com o Plano de Projeto integral e o cliente apenas com a sua viso do documento. Toda vez que o Plano do Projeto for atualizado, o Gerente do Projeto encaminha um e-mail para os stakeholders internos que participaram da reunio de Kick Off, informando as atualizaes realizadas. Caso haja alguma discordncia em relao s atualizaes feitas, os envolvidos sinalizam para o Gerente do Projeto para que haja um consenso. Caso as alteraes interfiram nos tpicos que compem o Plano do Projeto viso do cliente, o Gerente do Projeto solicita um novo comprometimento do cliente atravs da nova verso do documento. Caso um profissional seja incorporado equipe do projeto (leve em considerao apenas os papis envolvidos na reunio de Kick Off), o mesmo dever se comprometer com o Plano do Projeto atravs do preenchimento do Registro de Comprometimento com o Plano do Projeto (WP-02). Os comprometimentos de todos os envolvidos com as suas tarefas so realizados atravs da indicao de comprometimento no corpo da tarefa, no CaMMIla. 5.6 Registrar Situao do Projeto (Milestone) Conforme definido no Processo de Desenvolvimento e especificado no cronograma, ao final de cada macro-atividade enviado um e-mail pelo gerente de Projeto com a situao do projeto para todos os stakeholders relevantes do Projeto incluindo o Gerente da Fbrica de Software. O objetivo do Milestone preparar os envolvidos para o incio da prxima macroatividade do projeto, de forma que a data no necessariamente coincide com a data final da macro-atividade anterior. Sendo necessrio o Plano do Projeto refinado para a prxima atividade. 5.7 Monitorao e Controle do Processo A Monitorao e Controle do processo de Planejamento do Projeto realizada: y % de Desvios por PA

O PPQA, durante as suas avaliaes, utiliza o Checklist para Auditoria de Aderncia e Adequao a processos e registra no mesmo os desvios identificados. As informaes dos desvios identificados para os projetos servem para atualizar o Relatrio de Acompanhamento. Durante a Reunio com a Gerncia de Sistemas de Informao, o PPQA reporta todas as questes relevantes identificadas durante a sua avaliao, inclusive o percentual de desvios identificados por PA. Nesta reunio so registradas, inclusive, as anlises a respeito dos percentuais. y Alm disso, existe o trabalho de melhoria de processos realizado pelo SEPG.

Antes da sua reunio mensal do SEPG, a Coordenao do SEPG solicita que o o PPQA envie por e-mail as informaes da mtrica acima mencionada, com o intuito de consolid-las. As informaes relativas s no-conformidades da PA de PPQA so levadas em considerao nesta consolidao feita pelo SEPG. Durante essa reunio, as informaes e anlises tratadas em conjunto so registradas. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado com a anlise das mtricas. Caso sugestes / oportunidades de melhorias sejam identificadas, a equipe do projeto cadastra as mesmas no CaMMIla para anlise do SEPG. 5.8 Comunicao do Status do Projeto Quinzenalmente, o Gerente do Projeto reporta todos os assuntos relevantes detectados em cada projeto ao Gerente de Sistemas de Informao, em reunio formal, da qual gerada a Memria de Reunio com a Gerncia de Sistemas de Informao(WP-05), contendo as informaes relevantes da anlise feita nos projetos, a situao pertinente a cada um e os planos de ao abertos para resoluo de questes identificadas durante a reunio. O Gerente de Projetos leva as informaes do Registro de Monitorao e Controle para a reunio, com um parecer prvio dos assuntos que sero tratados e registrados na Memria de Reunio com a Gerncia de Sistemas de Informao, que conter a anlise conjunta dos itens

abordados. Caso necessrio, um Plano de Ao (WP-PMC-03) gerado para solucionar algum problema detectado durante o andamento dos Projetos.

PRO_REQM Processo de Gerncia de Requisitos Reviso: 7 Aprovao: Daniella Gobira

1. Poltica Organizacional Manter os requisitos atualizados e com os devidos comprometimentos durante todo o projeto. Manter um sincronismo entre os requisitos, unidades codificadas e demais artefatos atravs da matriz de rastreabilidade, de forma a evitar possveis inconsistncias entre eles. As solicitaes de mudanas so registradas, analisadas e rastreadas. 2. Planejamento do Processo 2.1 Definio do Processo O objetivo do Processo de Gerncia de Requisitos gerenciar os requisitos dos produtos do projeto e componentes do produto e identificar inconsistncias entre estes requisitos, os planos do projeto e os produtos de trabalho. Macro-atividade 1: Planejamento do Processo de Gerncia de Requisitos Objetivo: Planejar o processo de Gerncia de Requisitos, seguindo o estabelecido neste documento. Atividade: Gerar Plano de Gerncia de Requisitos y y y Descrio: Definir as dimenses da matriz e as atividades dentro do cronograma. Responsvel: Gerente de Requisitos. Artefato: Plano de Gerncia de Requisitos, no CaMMIla.

Macro-atividade 2: Anlise dos Requisitos do Software Objetivo: Analisar a totalidade dos requisitos do software a ser desenvolvido (requisitos funcionais e requisitos no funcionais). Novos fornecedores e avaliadores de requisitos podem ser identificados durante a execuo desta atividade. Atividade: Elicitar Requisitos y Descrio: Elicitar os requisitos funcionais e no funcionais utilizando, para isto, tcnicas como entrevistas e encontros facilitados. Se pertinente (caso j no tenha sido iniciado), deve-se iniciar o Glossrio do Projeto. Responsveis: Analista de Sistemas. Participantes: Fornecedores de Requisitos. Artefatos: Memria de Reunio (RQ-7.3B) e Glossrio do Projeto (WP-REQM-03).

y y y

Atividade: Especificar Requisitos y y y Descrio: : Identificar e documentar requisitos funcionais e no funcionais. A forma de apresentar os requisitos depende do mtodo de desenvolvimento escolhido. Responsveis: Analista de Sistemas. Artefato: Especificao de Requisitos do Software (WP-REQM-05) ou Documento de Descrio de Requisitos (WP-REQM-07).

Atividade: Criar Matriz de Rastreabilidade y Descrio: Preencher o 1 nvel da Matriz de Rastreabilidade, especificando os artefatos iniciais.

y y

Responsveis: Analista de Sistemas. Artefato: Matriz de Rastreabilidade (WP-REQM-06).

Atividade: Recalcular Tamanho e Custo do Projeto y Descrio: Baseado na Especificao de Requisitos do Software, recalcular o Tamanho e Custo do Projeto, utilizando tcnica NESMA de clculo por ponto de funo. Responsveis: Analista de Sistemas. Artefato: Clculo de Tamanho do Projeto.

y y

Atividade: Obter Comprometimento com os Requisitos do Software y Descrio: Avaliar os requisitos do software segundo os critrios estabelecidos na ITPRO-12. Obter, dos stakeholders do Cliente, comprometimento com os requisitos do software. Com esta atividade, a Especificao de Requisitos do Software est aprovada e sujeita Gerncia de Configurao. Responsvel: Analista de Sistemas (Peer Review). Participantes: Gerente de Requisitos, Gerente do Projeto e stakeholders do Cliente. Artefatos: Registro de Avaliao e Comprometimento com a Especificao de Requisitos do Software (WP-01.2), Registro de Comprometimento do Cliente com a Especificao de Requisitos do Software (WP-02).

y y y

Macro-atividade 3: Gerar Modelo de Anlise Objetivo: Gerar o Modelo de Anlise, baseando-se nos requisitos especificados. Atividade: Desenvolver o Modelo de Anlise do Software y y y Descrio: Desenvolver e documentar o modelo de anlise do software. Responsveis: Analista de Sistemas. Artefatos: Modelos de Anlise (Caso de Uso, Descritivo de Caso de Uso, Prottipos, Diagrama de Atividades, Diagrama de Estado, Diagrama de Seqncia e Colaborao e Diagrama de Objetos) e Memria de Reunio.

Atividade: Atualizar Matriz de Rastreabilidade y Descrio: Preencher o nvel seguinte da Matriz de Rastreabilidade, identificando os artefatos produzidos nesta atividade e seus relacionamentos com os artefatos produzidos na atividade anterior (dependncias, derivaes etc.). Responsveis: Analista de Sistemas. Artefatos: Matriz de Rastreabilidade Atualizada.

y y

Atividade: Recalcular Tamanho do Projeto y Descrio: A partir da Especificao de Requisitos do Software e dos Modelos de Anlise, recalcular o Tamanho do Projeto, utilizando tcnica detalhada de clculo por ponto de funo. Responsveis: Gerente de Requisitos. Participantes: Gerente de Projetos. Artefatos: Clculo de Tamanho do Projeto.

y y y

Atividade: Obter Comprometimento com o Modelo de Anlise y Descrio: Avaliar e obter comprometimento com o modelo de Anlise.

Sub-atividades: y y y Nome: Avaliar o Modelo de Anlise Descrio: Avaliar os Modelos de Anlise segundo os critrios estabelecidos no ITPRO-12. Responsvel: Analista de Sistemas (Peer Review).

y y

Participantes: Gerente de Requisitos e Gerente do Projeto. Artefatos: Modelos de Anlise Avaliados, Registro de Avaliao e Comprometimento com os Modelos de Anlise (WP-01.3) Nome: Registrar Comprometimento com o Modelo de Anlise. Descrio: Obter, dos participantes envolvidos, comprometimento com o Modelo de Anlise. Responsvel: Gerente de Requisitos e Gerente do Projeto. Participantes: Stakeholders do Cliente quando necessrio. Artefatos: Registro de Comprometimento com os Modelos de Anlise.

y y y y y

Atividade: Reunio de Passagem y y Nome: Realizar Reunio de Passagem. Descrio: Contextualizar os envolvidos no projeto sobre os requisitos e diagramas gerados, a fim de facilitar o desenvolvimento das fases seguintes e equalizar o entendimento e expectativas do cliente quanto aplicao. Responsvel: Analista de Sistemas. Participantes: Lderes de Projeto, Codificao e Teste, ou outros profissionais por eles indicado. Artefatos: Memria de Reunio.

y y y

Macro-atividade 4: Gerar Projeto Tcnico Objetivo: Gerar o Projeto Tcnico, baseando-se nos requisitos especificados e nos Modelos de Anlise. Atividade: Desenvolver o Projeto Tcnico do Software y y y Descrio: Desenvolver e documentar o projeto da base de dados e os de aplicao e interface, se necessrio. Responsveis: Projetista. Artefatos: Projeto Tcnico do Software (DER (Fsico), Diagrama de Classe, Diagrama de Componentes Distribudos, Diagrama de Distribuio dos Objetos), Documento de Arquitetura (WP-16).

Atividade: Atualizar Matriz de Rastreabilidade y Descrio: Preencher o nvel seguinte da Matriz de Rastreabilidade, identificando os artefatos produzidos nesta atividade e seus relacionamentos com os artefatos produzidos na atividade anterior (dependncias, derivaes etc.). Responsveis: Projetista. Artefatos: Matriz de Rastreabilidade Atualizada.

y y

Atividade: Obter Comprometimento com o Projeto Tcnico de Software y Descrio: Avaliar e obter comprometimento com o Projeto Tcnico.

Sub-atividades: y y y y y Nome: Avaliar o Projeto Tcnico Descrio: Avaliar o Projeto Tcnico de Software segundo os critrios estabelecidos na IT-PRO-12. Responsvel: Analista de Sistemas (Peer Review). Participantes: Gerente de Requisitos e Gerente do Projeto. Artefatos: Projeto Tcnico de Software Avaliado, Registro de Avaliao e Comprometimento com o Projeto Tcnico do Software (WP-01.4). Nome: Registrar Comprometimento com o Projeto Tcnico de Software. Descrio: Obter, dos participantes envolvidos, comprometimento com o Projeto Tcnico. Responsvel: Gerente de Requisitos e Gerente do Projeto.

y y y

y y

Participantes: Stakeholders do Cliente quando necessrio. Artefatos: Registro de Comprometimento com o Projeto Tcnico do Software.

Atividade: Reunio de Passagem y y Nome: Realizar Reunio de Passagem. Descrio: Apresentar para a equipe de desenvolvimento os artefatos gerados na fase de projeto tcnico e tirar possveis dvidas quanto ao entendimento da aplicao e dos artefatos. Responsvel: Projetista. Participantes: Lder de Codificao, ou outro profissional por ele indicado. Artefatos: Memria de Reunio.

y y y

Macro-atividade 5: Gerncia de Requisitos Objetivo: Garantir que, na medida em que os requisitos evoluam, os envolvidos estejam comprometidos com os requisitos atuais e os planos, artefatos de trabalho e comprometimentos estejam consistentes com os requisitos. Atividade: Controlar Mudanas nos Requisitos y y y y Descrio: Documentar as solicitaes de mudana nos requisitos aprovados, incluindo o registro de uma justificativa. Responsvel: Gerente do Projeto. Participantes: Stakeholders internos. Artefatos: Solicitao de Mudana (WP-15), Definio do Escopo do Produto, Especificao de Requisitos do Software, Registro de Comprometimento.

Atividade: Identificar Inconsistncias entre Requisitos e Artefatos y y y y Descrio: Identificar as inconsistncias entre os requisitos especificados e os planos do projeto e artefatos produzidos. Responsvel: Gerente do Projeto e Gerente de Requisitos. Participantes: Stakeholders internos . Artefato: Registros de Avaliao dos Artefatos.

3. Recursos Para executar este processo so necessrios: y y Pessoal treinado conforme o item 5. Ferramentas: MS-Word, SVN (Subversion), CaMMIla (Gerenciador de Projetos de Sistema), AvanDOC (ferramenta de gerenciamento de arquivos), AvanEAD (ferramenta de ensino distncia).

4. Responsabilidade As responsabilidades por cada atividade do processo esto identificadas no item 2.1 deste documento (Definio do Processo). 5. Treinamento Para execuo deste processo os profissionais envolvidos em suas atividades so treinados em: y Gerente da Fbrica de Software: o Introduo ao CMMI; o PRO_REQM Processo de Gerncia de Requisitos; o IT-PRO-10 Controle de Mudanas; o IT-PRO-12 Gerncia de Requisitos; o Ferramenta: CaMMIla (Viso de Gerncia de Requisitos).

Gerente do Projeto: o Introduo ao CMMI; o PRO_REQM Processo de Gerncia de Requisitos; o IT-PRO-10 Controle de Mudanas; o IT-PRO-12 Gerncia de Requisitos; o Ferramenta: CaMMIla (Viso de Gerncia de Requisitos). Lderes e Gerente de Requisitos: o Introduo ao CMMI; o PRO_REQM Processo de Gerncia de Requisitos; o IT-PRO-10 Controle de Mudanas; o IT-PRO-12 Gerncia de Requisitos; o Ferramenta: CaMMIla (Viso de Gerncia de Requisitos). Analista de Sistemas, Desenvolvedor, Homologador e Documentador: o Introduo ao CMMI; o PRO_REQM Processo de Gerncia de Requisitos. Grupo de Garantia da Qualidade do Produto e do Processo (PPQA): o Introduo ao CMMI; o PRO_REQM Processo de Gerncia de Requisitos; o IT-PRO-10 Controle de Mudanas; o IT-PRO-12 Gerncia de Requisitos; o Ferramenta: CaMMIla (Viso de Gerncia de Requisitos).

6. Gerncia de Configurao Todos os produtos deste processo esto sob Gerncia de Configurao. 7. Stakeholders Relevantes Os stakeholders relevantes para a execuo do processo esto identificados no item 2.1 (Definio do Processo). 8. Monitorao e Controle do Processo A monitorao e controle do processo realizada: (i) Mtricas de monitorao do processo esto definidas no documento de Medio e Anlise (IT-PRO-13). (ii) Avaliao do Gerente do Projeto O Gerente do Projeto avalia a adequao do processo durante a execuo do projeto. O SEPG avalia a viabilidade das sugestes / oportunidades de melhoria detectadas no decorrer de um projeto. (iii) Avaliao de Encerramento do Projeto A equipe da Fbrica de Software envolvida no projeto, conduzida pelo Gerente do Projeto, avalia o processo na avaliao de encerramento do desenvolvimento, ao final da ltima macro-atividade. Essas informaes so sintetizadas pelo Gerente do Projeto e transmitidas aos Stakeholders relevantes atravs de e-mail ou Reunio de Encerramento de Projeto. 9. Avaliao Objetiva da Aderncia ao Processo A aderncia aos processos avaliada pelo PPQA, periodicamente, conforme definido no documento de Garantia da Qualidade do Produto e do Processo (IT-PRO-6), quando avaliada a aderncia a todos os processos, utilizando checklists pr-definidos. As atividades realizadas pelo PPQA so avaliadas por auditores externos ao PPQA para se garantir a objetividade necessria, tambm utilizando checklists. 10. Reviso do Status do Processo com a Gerncia de Snior

A Reviso do Status do Progresso do Processo de Gerncia de Requisitos ocorre conforme descrito no item 9 do Processo de Monitorao e Controle.

IT-PRO-10 - Controle de Mudanas Reviso: 11 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para realizar a anlise, avaliao e controle das mudanas solicitadas durante o projeto. 2. Executante da Tarefa Gerente de Configurao, Gerente do Projeto, Gerente de Requisitos e Comit de Controle de Mudana. 3. Documentos Complementares y y y y y y PRO_PD Processo de Desenvolvimento; PRO_CM Processo de Gerncia de Configurao; PRO_REQM - Processo de Gerncia de Requisitos; IT-PRO-09 Gerncia de Configurao; LISTA-FBRICA DE SOFTWARE Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

4. Recursos Necessrios y y Sistema de Gerenciamento de Projeto CaMMIla; Ferramenta para Gerncia de Configurao TortoiseSVN (front-end) e Subversion.

5. Atividades Principais O objetivo desta instruo de trabalho assegurar que os custos e os benefcios das mudanas sejam adequadamente analisados e que estas mudanas ocorram com o devido controle e rastreabilidade. A finalidade do gerenciamento das mudanas no projeto proteger a viabilidade da definio do escopo e os requerimentos de negcio que constam na Proposta Tcnica (RQ-7.3C). 5.1 Solicitao de Mudana Sempre que exista a necessidade de alterar um artefato que faa parte de uma baseline aprovada, necessrio que seja aberta uma Solicitao de Mudana (WP-15) no CaMMIla. Para preencher a Solicitao de Mudana no CaMMIla, o usurio clica na Guia Projeto em uso <Nome do Projeto>, acessa o menu Projeto opo Solicitao de Mudana e ento registra a mudana desejada informando os seguintes campos: y y y Fase - campo onde esto disponveis as fases do projeto(Anlise, Codificao, Projeto Tcnico, Requisito, Teste); Baseline - campo onde esto disponveis as baselines geradas. As baselines carregadas nesse campo so de acordo com a fase escolhida no campo Fase; Tipo - campo onde o usurio determina o tipo da solicitao de mudana: 1. Ao Corretiva: Quando identificado um problema em uma baseline aprovada; 2. Ao Preventiva: Quando os profissionais responsveis pelos artefatos de uma baseline aprovada identificam um problema; 3. Reparo de Defeitos :Quando o cliente identifica um problema em uma baseline j aprovada; 4. Requisito: Quando uma mudana solicitada em requisitos de uma baseline aprovada;

y y y y

Emergencial* - Utilizado quando a solicitao de mudana tem carter emergencial, ser executada e os registros sero feitos posteriormente; Descrio - descrio da mudana a ser implementada; Justificativa justificativa da necessidade da mudana a ser implementada; Benefcios benefcios para o sistema ou para a organizao cliente com a implementao da mudana.

Sempre que uma Solicitao de Mudana aberta no CaMMIla, o sistema envia um e-mail informativo para o Gerente do Projeto, Gerente de Configurao, PPQA e Gerente de Requisitos informando o tipo de solicitao, o nome do solicitante, a data da solicitao, a descrio, a justificativa e os benefcios que essa mudana trar. Para visualizar as Solicitaes de Mudana abertas no CaMMIla, basta acessar a Guia Projeto em uso <Nome do Projeto>, selecionar o menu Projeto opo Solicitao de Mudana. * Uma Solicitao de Mudana ser do tipo Emergencial apenas quando houver uma exigncia documentada pelo cliente ou em caso de fatos que violem diretamente o edital. Nesse caso o Gerente do Projeto cria uma atividade para o responsvel pela execuo da mudana, posteriormente a anlise de impacto da mudana feita e documentada seguindo o fluxo normal de mudana. 5.2 Possveis Mudanas O Gerente de Requisitos do projeto, aps ser sinalizado via e-mail da abertura de uma nova Solicitao de Mudana, identifica na Guia Possveis Mudanas os artefatos que efetivamente sero impactados pela mudana solicitada e para isso, a Matriz de Rastreabilidade e suas varincias (Mat. Artefato X Requisito e Mat. Cdigo X Requisito) so consultadas. Caso o mesmo identifique que a Solicitao de Mudana envolve mudanas em cdigo, o Lder de Codificao acionado para participar da anlise dessa mudana. O Gerente de Requisitos registra a anlise sobre a mudana, sugerindo uma estimativa de esforo(registrando o racional utilizado) e informa quais os artefatos sero impactados. Uma vez que os artefatos impactados foram identificados e o esforo estimado o Gerente do Projeto j possui respaldo de conduzir a sua anlise a respeito da mudana solicitada, contabilizando o custo estimado. Vale ressaltar que essa solicitao de mudana poder impactar diretamente no Planejamento do Projeto e, sendo a solicitao de mudana aprovada, o Gerente do Projeto realiza um replanejamento. 5.3 Anlise da Mudana Aps o recebimento do e-mail que sinaliza que o Gerente de Requisitos j realizou a anlise da Solicitao de Mudana aberta, o Gerente do Projeto acessa a Guia Anlise e preenche os seguintes campos: y y y Data data em que o gerente de projeto est analisando a solicitao de mudana em questo; Esforo Estimado quanto em esforo vai ser necessrio para implementar a mudana; Custo Estimado quanto vai custar a implementao da mudana para o projeto.

Com base na anlise realizada, o Gerente de projeto avalia o impacto da solicitao preenchendo os campos restantes: y y y y y Escopo caso haja impacto no escopo, preciso relatar o impacto do escopo. Prazo caso haja impacto no prazo, preciso relatar o impacto do prazo. Custo caso haja impacto no custo, preciso relatar o impacto do custo. Qualidade caso haja impacto na qualidade, preciso relatar o impacto da qualidade. Prioridade de acordo com a anlise realizada, o Gerente do Projeto determina a prioridade de realizao da mudana: 1. Alta 2. Mdia

3. Baixa y Parecer com base na anlise realizada, o Gerente do Projeto determina o seu parecer de acordo com os seguintes critrios: 1. Aprovada caso a mudana seja considerada vlida e vivel para o projeto e no afete o custo, o prazo ou a qualidade do projeto. 2. Cancelada caso seja identificado que a mudana no faz mais sentido de ser realizada. Vale a pena lembrar que algumas solicitaes de mudanas podem ocorrer em virtude de erros de compreenso e no de defeitos do sistema. Nestes casos, se a anlise constatar que a solicitao invlida, duplicada ou que j tenha sido considerada, a solicitao deve ser cancelada e o devido comentrio registrado. 3. No Aprovada caso a mudana seja considerada invlida ou invivel para o projeto. 4. Comit caso a mudana seja considerada vlida e vivel para o projeto e afete significativamente no custo, no prazo ou na qualidade do projeto. 5. Suspensa caso a mudana contenha algo que esteja pendente e impea a finalizao do projeto. Comentrio consta o comentrio do Gerente de Projeto durante a anlise.

Caso a mudana solicitada oferea riscos ao andamento do projeto ou signifique aumento de custo extrapolando o oramento (Plano de Esforo e Custo, no Plano do Projeto), uma reunio marcada com o Comit de Controle de Mudana (CCM) para que ocorra uma anlise mais aprofundada desta mudana e da viabilidade da mesma para o projeto e para o cliente. Desta forma, fica determinado que o Gerente do Projeto s pode tomar a deciso de acatar ou no uma mudana solicitada, se isso no for implicar no andamento do projeto ou se a margem de custo da solicitao de mudana no ultrapassar em 10% o custo mensal do projeto. O CCM composto pelo Gerente do Projeto, Gerente de Configurao, Gerente de Requisitos e Profissional Responsvel pelo Negcio. Aps anlise da solicitao de mudana pelo CCM, o Gerente do Projeto envia um email para o cliente informando o impacto da mudana e solicita a aprovao do mesmo. O Gerente de Projeto registra no CaMMIla, na Guia Projeto <nome do projeto>, menu Projeto opo Solicitao de Mudana, guia Comit: a data da anlise, os participantes da anlise, o parecer do Comit, e a justificativa do parecer do Comit. Caso a solicitao de mudana seja aprovada, o Gerente do Projeto envia um email ao Gerente de Configurao para liberao da baseline. Para que, o gerente de configurao depois da concluso da solicitao possa auditar a baseline, ele deve verificar na solicitao de mudana os arquivos identificados pelo Gerente de Requisitos que podero sofrer alteraes. O gerente do projeto abre uma tarefa* para o profissional responsvel e o mesmo j est apto a baixar do repositrio a baseline liberada: <https://svn.avansys.com.br/<nucleo.cliente.projeto>/branches/<fase>/<numero da baseline> e fazer a modificao. Os comentrios feitos no momento dos commits devem identificar o nmero da solicitao de mudana ao qual esto associados, conforme definido no Manual de Utilizao do Subversion (MUS). * Quando a mudana for considerada retrabalho, a tarefa ser aberta j identificada como retrabalho. Assim que a tarefa finalizada, o responsvel pela alterao notifica o Gerente de Projeto. Nesse momento ele deve enviar um e-mail ao Gerente de Configurao solicitando a gerao da reviso da baseline. O Gerente de Configurao realiza uma auditoria para verificar se os arquivos que foram modificados esto de acordo com os arquivos mencionados na Solicitao de Mudana como os requeridos para sofrer alterao. Caso no detecte problemas durante a auditoria, o Gerente de Configurao gera uma nova reviso da baseline. Porm, se encontrar problemas, o Gerente de Configurao age conforme documentado no item 5.4.1 da IT-PRO-9 Gerncia de Configurao. O Gerente de Requisitos encerra a Solicitao de Mudana. Para isso, escolhe o projeto na Guia Projeto em uso <Nome do Projeto>, acessa o menu Projeto, opo Solicitao de Mudana e clica no boto Fechar da Solicitao de Mudana.

Nesse momento, o CaMMIla dispara o e-mail informando que a Solicitao de Mudana foi finalizada. 5.4 Registro da Mudana Para identificar o que foi alterado de uma verso para outra o Gerente Configurao seleciona as baselines (anterior e alterada) e utiliza a opo Compare URLs do TortoiseSVN. O sistema ir listar tudo que foi alterado de uma verso para outra.

IT-PRO-12 - Gerncia de Requisitos Reviso: 8 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para atender ao Processo de Gerncia de Requisitos (PRO_REQM). 2. Executante da Tarefa y y y y Analistas de Sistemas; Projetistas; Gerente de Requisitos; Gerente de Projetos.

3. Documentos Complementares y y y y y y y PRO_PD Processo de Desenvolvimento; PRO_REQM Processo de Gerncia de Requisitos; IT-COM-2 Levantamento Preliminar; IT-PRO-10 Controle de Mudanas; IT-PRO-11 Planejamento do Projeto; LISTA-FBRICA DE SOFTWARE Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

4. Recursos Necessrios y y y CaMMIla Gerenciador de Projetos de Sistema; Subversion Sistema de Controle de Verso; Avansys Redmine;

5. Atividades Principais Descrever como so realizados o levantamento de dados, a anlise e a gerncia de requisitos e a identificao de inconsistncias entre os artefatos, planos e requisitos. Os requisitos solicitados so especificados e controlados pela ferramenta CaMMIla em conjunto com o SVN. A aprovao dos mesmos feita pelo avaliador de requisitos atravs do Registro de Comprometimento com a Especificao de Requisitos que assinada e armazenada no repositrio SVN. Durante o Levantamento Preliminar, requisitos iniciais so identificados e especificados, e realizado um estudo preliminar atravs da Anlise de Viabilidade Tcnica (RQ-7.5C) (conforme definido na IT-COM-2 Levantamento Preliminar). 5.1 Planejar o Processo No planejamento do processo definido como ocorrero as avaliaes dos artefatos do processo, os participantes, os nveis da Matriz de Rastreabilidade (WP-REQM-06) adotados no projeto e as datas que ocorrero essas atividades.

5.1.1 Gerar Plano de Gerncia de Requisitos Durante a fase de Planejamento do Projeto, o Gerente de Projetos apresenta o Plano do Projeto (WP-PP-01) e o Cronograma do Projeto (WP-PP-03) ao Gerente de Requisitos na reunio de Kick Off, conforme definido no documento de Planejamento do Projeto (IT-PRO-11). Neste instante, o Gerente de Requisitos planeja as suas atividades, criando o Plano de Gerncia de Requisitos (WP-REQM-01) que faz parte do Plano do Projeto. Para isso necessario acessar o projeto no CaMMIla e atravs da Guia Projeto, na opo Plano deve-se acessar a aba Requisitos para preencher as Dimenses da Matriz. 1.Dimenses da Matriz possvel realizar o rastreamento do requisito desde sua origem at o produto (outros requisitos, artefatos, cdigo) derivado e vice-versa. Para garantir que cada requisito seja rastreado, independentemente do seu nvel, gerada uma Matriz de Rastreabilidade que possui nveis ou dimenses para cada tipo de requisito. Estas dimenses sofrem cruzamentos que indicam as derivaes e dependncias dos requisitos. Para que a Matriz seja gerada, neste item so identificadas as dimenses que sero cadastradas na Matriz. Os requisitos so classificados em dois tipos: y y Funcional; No Funcional;

Cada tipo possui dimenses prprias, tais como: 5.2 Especificao dos Requisitos de Software 5.2.1 Elicitar Requisitos Esta etapa caracterizada pela realizao de reunies com os stakeholders , que foram indicados pelo cliente como os fornecedores de requisitos na reunio inicial conduzida pelo Gerente do Projeto. Durante essas reunies so coletados e analisados detalhadamente pelo Analista de Sistemas os requisitos funcionais (cadastros bsicos, funcionalidades, casos de uso e relatrios do sistema) e requisitos no-funcionais (requisitos de qualidade, de interface, tecnolgicos, legais, de proteo e segurana, de bases de dados, de instalao, do usurio para execuo, operao e manuteno). As Memrias de Reunies (RQ-7.3) geradas e validadas durante o levantamento so utilizadas para a elaborao da Especificao de Requisitos do Software (WP-REQM-05).Os requisitos so criados e atualizados, sempre que necessrio, pelos Analistas de Sistemas. Nesta fase recomenda-se, caso necessrio, iniciar a elaborao do Glossrio do Projeto. Esse Glossrio composto por termos especficos da rea a que se destina o projeto, com a finalidade de favorecer e nivelar o entendimento de todos. 5.2.1.1 Glossrio do Projeto Para utilizar o Glossrio num determinado projeto, deve-se verificar a existncia desse tipo de artefato cadastrado no CaMMIla, acessando a guia Cadastro a opo Tipo de Artefato.Caso no exista Glossrio na lista dos artefatos deve-se criar clicando na opo Novo e preencher os campos: Fase: campo onde esto disponveis as fases do projeto (Anlise, Codificao, Projeto Tcnico, Requisito, Teste); Sigla: campo para cadastro da sigla do novo artefato;
2

Descrio: descrio do novo artefato cadastrado.

Para o cadastro dos termos especficos do projeto necessrio acessar a guia Projeto e na opo Artefato preencher os campos: Tipo de Artefato: selecionar o tipo Glossrio; Nome: campo para cadastro do termo especfico do projeto; Descrio: significado do termo informado no campo anterior; Artefatos Afetados: campo para seleo dos artefatos que sero impactados pelo novo cadastro; Aps todo cadastro deve-se clicar no boto Salvar.

5.2.2 Especificar Requisitos O Analista de Sistemas identifica e documenta requisitos funcionais, e outros requisitos no funcionais (requisitos de interface, tecnolgicos, legais, de proteo e segurana, de bases de dados, de instalao, do usurio para execuo, operao e manuteno) no documento de Especificao de Requisitos (WP-REQM-05) ou Documento de Descrio de Requisitos - DDR (WP-REQM-07). Para o cadastro no CaMMIla, os requisitos previamente cadastrados so utilizados. Para isso ele acessa o projeto desejado na Guia Projeto, no item Artefato e no boto Novo cadastra os Requisitos de maneira similar ao informado no item 5.2.2.1(Glossrio do Projeto). A medida que os artefatos so cadastrados, o analista de sistemas j indica atravs do campo artefatos afetados a rastreabilidade dos artefatos, gerando assim a matriz de rastreabilidade do sistema.

5.2.3 Matriz de Rastreabilidade A Matriz de Rastreabilidade criada no momento em que os artefatos do sistema so cadastrados no CaMMIla. Para visualiz-la, necessrio acessar o menu Projeto, opo Matriz. Sero exibidos dois quadros, um com os requisitos e artefatos cadastrados e o outro onde estaro os itens selecionados para visualizao da Matriz. Aps selecionar os itens no quadro esquerdo deve-se clicar na opo Copiar para enviar os mesmos para o quadro do lado direito. Depois de selecionar todos os itens para visualizao da matriz, deve-se clicar no boto Gerar. medida que novos requisitos de outras dimenses so identificados, ou quando surgem alteraes nos relacionamentos, a Matriz atualizada atravs da atualizao do artefato. 5.2.4 Recalcular Tamanho e Custo do Projeto A partir da Especificao de Requisitos do Software, recalcular o Tamanho e Custo do Projeto, utilizando tcnica NESMA de clculo por ponto de funo. Nesse momento o Gerente de Requisitos atualiza a planilha Clculo de Tamanho do Projeto (RQ7.3K) com informaes relevantes, obtidas durante reunies com os fornecedores de requisitos. A partir do resultado do recalculo, o Gerente de Projeto dever fazer uma anlise e verificar se o esforo e custo obtidos se desviaram significativamente dos valores obtidos no Levantamento Preliminar, ou seja, se algum arquivo lgico interno ou arquivo de interface externa foi acrescentado. Em caso positivo o Planejamento do Projeto dever ser revisto (gerar nova

verso do Plano de Esforo e Custo, replanejar o cronograma gerando nova verso do plano) e os envolvidos informados para que os comprometimentos com as alteraes sejam adquiridos. O clculo do tamanho do projeto feito seguindo as normas do IFPUG International Function Point Users Group, que tem como aceitvel uma diferena de at 20% entre o tamanho do projeto calculado na pr-venda (dedutiva) e o clculo depois da fase de requisitos (detalhada). Essa diferena se d devido maturidade dos requisitos que maior aps a elicitao dos requisitos. 5.2.5 Obter Comprometimento com os Requisitos Especificados 5.2.5.1 Avaliar Requisitos (Peer Review) realizada uma Avaliao entre Analistas de Sistemas, do mesmo projeto ou projetos diferentes, segundo os seguintes critrios: clareza, completude, ausncia de ambiguidade, consistncia interna, identificao nica, rastreabilidade com os requisitos, consistncia com Escopo e Componentes do Sistema, viabilidade (de implementao, operao e manuteno). Caso os requisitos no estejam de acordo com os critrios estabelecidos, o Analista de Sistemas responsvel executa as correes necessrias. Critrios para execuo desta atividade: y y y y As datas das avaliaes constam no Cronograma do Projeto; As avaliaes s podem ser executadas por analistas e que no tenham sido os criadores do artefato em questo; O Gerente Funcional que designa os pares, de acordo com a disponibilidade de cada Analista; As aes referentes aos critrios avaliados so descritas na coluna Esboo do Plano de Ao, enquanto que as outras aes (no relacionadas aos critrios prestabelecidos) so identificadas na rea reservada no final do prprio Registro de Avaliao; Como em todas as atividades do Processo de Desenvolvimento, o esforo gasto durante a avaliao e correes/alteraes executadas registrado no CaMMIla.

Para os casos em que no foram identificados problemas no documento, o Analista responsvel pelo peer-review armazena o Registro de Avaliao e Comprometimento correspondente. Porm, caso seja identificada alguma inconsistncia entre os artefatos e os requisitos e/ou Escopo do Produto, o Analista de Sistemas responsvel pela realizao do peer-review registra os problemas identificados no Registro de Avaliao e Comprometimento, armazena e informa ao lder de anlise que abre uma tarefa para o Analista de Sistemas executar as correes. Essa correo considerada como retrabalho para as atividades. Aps a reviso do artefato, uma nova avaliao realizada, seguindo os mesmos critrios anteriormente estabelecidos. Havendo necessidade, uma reunio presencial marcada entre os Analistas envolvidos (responsvel pelo peer-review e responsvel pelo projeto em questo) e o Gerente Funcional, com o intuito de resolver conflitos de entendimento e fechar o artefato em questo. 5.2.5.2 Registrar Comprometimento com os Requisitos do Software Os participantes envolvidos, devem se comprometer com os requisitos do software. O Analista de Sistemas (peer-review) se compromete atravs do Registro de avaliao e comprometimento com a especificao de requisitos de software. Os demais integrantes da equipe se comprometem a partir das tarefas abertas no CaMMIla. Com esta atividade, a Especificao de Requisitos do Software est aprovada e sujeita Gerncia de Configurao. A obteno do Comprometimento do Cliente com a Especificao de Requisitos ocorre da seguinte forma:

A Especificao de Requisitos enviada ao cliente. Aps aprovao o cliente assina o Registro de Comprometimento (WP-02) se comprometendo com a verso da especificao enviada. Alguns editais exigem que a baseline da fase seja enviada para aprovao do cliente, dessa forma o comprometimento feito com todos os artefatos enviados e no somente com a Especificao de Requisitos.

Obs: As observaes so enviadas por e-mail ou registradas no prprio documento e levadas para considerao do Analista de Sistemas. Os possveis ajustes so feitos e um novo documento/baseline gerado(a). 5.3 Gerar Modelos de Anlise Esta etapa caracterizada pela criao dos Modelos de Anlise, baseando-se nos requisitos especificados anteriormente utilizando ferramenta de apoio (quando necessrio). Reunies podem ser realizadas para esclarecer algum aspecto do modelo. So elaborados os modelos definidos na Proposta Tcnica/Edital e aqueles que so relevantes para a equipe da AVANSYS, mesmo no tendo sido solicitados pelo cliente. Neste ltimo caso, os modelos elaborados so considerados artefatos internos, no sendo divulgados para o cliente. Seguem exemplos de modelos que compem as atividades de anlise: Modelos de Anlise y y y Caso de Uso; Diagrama de Atividades; Diagrama de Estado;

5.3.1 Atualizar Matriz de Rastreabilidade Aps a criao da Matriz de Rastreabilidade no CaMMIla, o Gerente de Requisitos acompanha a rastreabilidade bidirecional dos artefatos. Ou seja, atravs de um requisito especificado no sistema, pode-se chegar aos artefatos que foram gerados a partir dele e acessando um artefato especfico, pode-se identificar quais os requisitos que levaram criao do mesmo, garantindo assim que o conceito de rastreabilidade bidirecional seja empregado. Desta forma, torna-se mais fcil para o Gerente de Requisitos identificar o impacto das mudanas solicitadas para o projeto. Deve-se preencher o 2 nvel da Matriz de Rastreabilidade, identificando os artefatos produzidos na atividade de Modelo de Anlise e seus relacionamentos com os artefatos produzidos na atividade anterior (dependncias, derivaes, etc.). Para isso, os artefatos produzidos devem ser cadastrados no CaMMIla, e a medida que forem cadastrados o analista de sistemas/projetista informa quais so os artefatos relacionados. 5.3.2 Recalcular Tamanho e Custo do Projeto A partir dos Modelos de Anlise, recalcular o Tamanho e Custo do Projeto, utilizando tcnica de contagem detalhada de ponto de funo. Nesse momento o Gerente de Requisitos atualiza a planilha Clculo de Tamanho do Projeto (RQ7.3K) com informaes relevantes identificadas durante a fase de anlise do projeto. A partir do resultado do recalculo, o Gerente de Projeto dever fazer uma anlise e verificar se o esforo e custo obtidos se desviaram significativamente dos valores obtidos no Levantamento Preliminar, ou seja, se algum arquivo lgico interno ou arquivo de interface externa foi acrescentado. Em caso positivo o Planejamento do Projeto dever ser revisto (gerar nova verso do Plano de Esforo e Custo, replanejar o cronograma gerando nova verso do plano)e os envolvidos informados para que os comprometimentos com as alteraes sejam adquiridos. O clculo do tamanho do projeto feito seguindo as normas do IFPUG International Function Point Users Group, que tem como aceitvel uma diferena de at 20% entre o tamanho do projeto calculado na pr-venda (dedutiva) e o clculo depois da fase de requisitos (detalhada). Essa diferena se d devido maturidade dos requisitos que maior aps a anlise dos requisitos.

5.3.3 Avaliar Modelos de Anlise (Peer Review) realizada uma Avaliao entre Analistas de Sistemas, do mesmo projeto ou projetos diferentes, segundo os seguintes critrios: clareza, completude, ausncia de ambiguidade, consistncia interna, identificao nica, rastreabilidade com os requisitos, consistncia com Escopo e Componentes do Sistema, viabilidade (de implementao, operao e manuteno). Caso os modelos de anlise no estejam de acordo com os critrios estabelecidos, o Analista de Sistemas responsvel executa as correes necessrias. Critrios para execuo desta atividade: y y y y As datas das avaliaes constam no Cronograma do Projeto; As avaliaes s podem ser executadas por analistas e que no tenham sido os criadores do artefato em questo; O Gerente Funcional que designa os pares, de acordo com a disponibilidade de cada Analista; As aes referentes aos critrios avaliados so descritas na coluna Esboo do Plano de Ao, enquanto que as outras aes (no relacionadas aos critrios prestabelecidos) so identificadas na rea reservada no final do prprio Registro de Avaliao; Como em todas as atividades do Processo de Desenvolvimento, o esforo gasto durante a avaliao e correes/alteraes executadas registrado no CaMMIla.

Para os casos em que no foram identificados problemas no documento, o Analista responsvel pelo peer-review armazena o Registro de Avaliao e Comprometimento correspondente. Porm, caso seja identificada alguma inconsistncia entre os artefatos e os requisitos e/ou Escopo do Produto, o Analista de Sistemas responsvel pela realizao do peer-review registra os problemas identificados no Registro de Avaliao e Comprometimento, armazena e informa ao lder de anlise que abre uma tarefa para o Analista de Sistemas executar as correes. Essa correo considerada como retrabalho para as atividades. Aps a reviso do artefato, uma nova avaliao realizada, seguindo os mesmos critrios anteriormente estabelecidos. Havendo necessidade, uma reunio presencial marcada entre os Analistas envolvidos (responsvel pelo peer-review e responsvel pelo projeto em questo) e o Gerente Funcional, com o intuito de resolver conflitos de entendimento e fechar o artefato em questo. 5.3.4 Reunio de Passagem realizada uma reunio entre o Analista de Sistemas responsvel pela anlise do projeto, os lderes de projeto, codificao e teste ou algum profissional por eles indicado. Nessa reunio o Analista de Sistemas contextualiza os profissionais a respeito dos requisitos do sistema. Quando necessrio apresenta diagramas para facilitar o entendimento dos participantes. Uma nova reunio de passagem acontece ao final da fase de projeto tcnico, quando o Projetista apresenta ao Lder de Codificao, ou outro profissional por ele indicado, os artefatos gerados a fim de equalizar o entendimento e facilitar o desenvolvimento da aplicao. As reunies devem ser registradas em Memrias de Reunio e divulgadas para os demais integrantes do projeto. Dvidas posteriores devero ser registradas atravs da ferramenta Avansys Redmine. 5.4 Desenvolver o Projeto Tcnico de software Esta etapa caracterizada pela criao do Projeto Tcnico de Software, baseando-se nos requisitos especificados. O projeto da aplicao tem como objetivo mapear os Modelos de Anlise numa arquitetura tcnica e descrever cada componente de software. O Projeto de Interface envolve as interfaces externas e entre os componentes do software e possibilita a codificao sem necessidade de informao adicional. O Projeto da Base de Dados tem como objetivo mapear o Modelo de Anlise, em particular, o modelo conceitual dos dados, em um conjunto de elementos reconhecidos pelo SGBD utilizado, permitindo armazenamento e recuperao eficiente de informaes.

O Projeto Tcnico de Software composto de: y y y y DER (Fsico); Diagrama de Classe; Diagrama de Sequncia e Colaborao; Diagrama de Objetos.

No obrigatrio o comprometimento do cliente com os Modelos de Anlise e com o Projeto Tcnico, ficando a cargo do Gerente de Projetos, durante a reunio inicial com os Stakeholders do cliente, documentar a opo do cliente perante esta possibilidade. 5.4.1 Atualizar Matriz de Rastreabilidade Deve-se preencher o prximo nvel da Matriz de Rastreabilidade, identificando os artefatos produzidos na atividade de Projeto Tcnico e seus relacionamentos com os artefatos produzidos na atividade anterior (dependncias, derivaes, etc.). Para isso, os artefatos produzidos devem ser cadastrados no CaMMIla, e a medida que forem cadastrados o analista de sistemas/projetista informa quais so os artefatos relacionados. 5.4.2 Avaliar Projeto Tcnico (Peer Review) realizada uma Avaliao entre Analistas de Sistemas, do mesmo projeto ou projetos diferentes, segundo os seguintes critrios: clareza, completude, ausncia de ambiguidade, consistncia interna, identificao nica, rastreabilidade com os requisitos, consistncia com Escopo e Componentes do Sistema, viabilidade (de implementao, operao e manuteno). Caso o projeto tcnico no esteja de acordo com os critrios estabelecidos, o Analista de Sistemas responsvel executa as correes necessrias. Critrios para execuo desta atividade: y y y y As datas das avaliaes constam no Cronograma do Projeto; As avaliaes s podem ser executadas por analistas e que no tenham sido os criadores do artefato em questo; O Gerente Funcional que designa os pares, de acordo com a disponibilidade de cada Analista; As aes referentes aos critrios avaliados so descritas na coluna Esboo do Plano de Ao, enquanto que as outras aes (no relacionadas aos critrios prestabelecidos) so identificadas na rea reservada no final do prprio Registro de Avaliao; Como em todas as atividades do Processo de Desenvolvimento, o esforo gasto durante a avaliao e correes/alteraes executadas registrado no CaMMIla.

Para os casos em que no foram identificados problemas no documento, o Analista responsvel pelo peer-review armazena o Registro de Avaliao e Comprometimento correspondente. Porm, caso seja identificada alguma inconsistncia entre os artefatos e os requisitos e/ou Escopo do Produto, o Analista de Sistemas responsvel pela realizao do peer-review registra os problemas identificados no Registro de Avaliao e Comprometimento, armazena e informa ao lder de anlise que abre uma tarefa para o Analista de Sistemas executar as correes. Essa correo considerada como retrabalho para as atividades. Aps a reviso do artefato, uma nova avaliao realizada, seguindo os mesmos critrios anteriormente estabelecidos. Havendo necessidade, uma reunio presencial marcada entre os Analistas envolvidos (responsvel pelo peer-review e responsvel pelo projeto em questo) e o Gerente Funcional, com o intuito de resolver conflitos de entendimento e fechar o artefato em questo. 5.5 Atualizar Matriz de Rastreabilidade de Cdigo Essa atualizao da Matriz ocorre aps a atividade Codificar e Testar Unidades na fase de Codificao e Testes de Unidade, do Processo de Desenvolvimento.

Deve-se preencher o prximo nvel da Matriz de Rastreabilidade, identificando os artefatos produzidos nesta atividade e seus relacionamentos com os artefatos produzidos na atividade anterior (dependncias, derivaes etc.). 5.6 Gerncia de Requisitos 5.6.1 Controlar Mudanas nos Requisitos Toda a solicitao de mudana em requisitos aprovados deve ser documentada, incluindo registro de justificativa (raciocnio embutido). Para cada requisito modificado, avaliar o impacto em planos, artefatos e comprometimentos dos envolvidos com a nova especificao de requisitos. Esta atividade executada de acordo com o documento de Controle de Mudanas (IT-PRO-10), Gerncia de Configurao (IT-PRO-09) e Processo de Gerncia de Configurao (PRO-CM). 5.6.2 Identificar Inconsistncias entre Requisitos e Artefatos Avaliaes so realizadas nos artefatos gerados pelo Processo de Desenvolvimento (PRO_PD), no intuito de identificar inconsistncias entre requisitos e artefatos. Estas avaliaes so documentadas nos Registros de Avaliao e Comprometimento com cada artefato mencionado. Caso seja necessrio, as avaliaes so encaminhadas para o profissional responsvel pela correo dos artefatos. Esta atividade executada ao longo do projeto, a partir das avaliaes dos artefatos produzidos nas macro-atividades. Na atividade Avaliar os Requisitos, Modelo de Anlise e Projeto Tcnico, deve ser avaliada a consistncia com o escopo e componentes do sistema e a consistncia com os requisitos do software. Obs: O cliente dar o aceite final do sistema aps a fase de homologao do projeto, em que ele valida as funcionalidades do software a partir dos mdulos especificados na proposta tcnica. Ele utiliza como critrio de aceite o resultado dos testes realizados durante a homologao interna, onde verificado o atendimento dos requisitos especificados. Para isso utilizado o documento Relatrio de Teste de Qualificao de Software (WP-12.1). 5.7 Monitorao e Controle do Processo A monitorao e controle do processo de Gerncia de Requisitos realizada: y 1) % de Desvios por PA

O PPQA, durante as suas avaliaes, utiliza o Checklist para Auditoria de Aderncia e Adequao a processos e registra no mesmo os desvios identificados. As informaes dos desvios identificados para os projetos servem para atualizar o Relatrio de Acompanhamento. Durante a Reunio com a Gerncia de Sistema de Informao, o PPQA reporta todas as questes relevantes identificadas durante a sua avaliao, inclusive o percentual de desvios identificados por PA. Nesta reunio so registradas, inclusive, as anlises a respeito dos percentuais. y 2) Alm disso, existe o trabalho de melhoria de processos realizado pelo SEPG.

Antes da sua reunio mensal do SEPG, a Coordenao do SEPG solicita que o PPQA envie por e-mail a informao da mtrica 1 acima mencionada. As informaes relativas s noconformidades da PA de PPQA so levadas em considerao nesta consolidao feita pelo SEPG. Durante essa reunio, as informaes e anlises tratadas em conjunto so registradas. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado com a anlise das mtricas. 5.8 Comunicao do Status dos Projetos O Gerente da Fbrica acompanha a execuo das atividades do Gerente de Requisitos atravs da ferramenta CaMMIla. Sempre que necessrio, o Gerente da Fbrica abre uma tarefa na prpria ferramenta para que ocorra uma reunio com o Analista de Sistemas com o intuito de tratar os problemas detectados durante o levantamento de dados, comprometimentos

adquiridos junto ao cliente, criao dos modelos de anlise e planos de ao abertos para resoluo de questes identificadas durante a reunio. As informaes colhidas durante essa reunio so registradas na descrio da tarefa aberta, servindo de registro para a execuo da atividade. Caso necessrio, um Plano de Ao (WP-PMC-03) gerado para solucionar algum problema detectado durante a reunio acima mencionada ou durante o andamento dos Projetos. Desta forma, mensalmente, na reunio de reporte do Gerente da Fbrica com a Gerncia de Sistema de Informao, as informaes relevantes so tratadas e documentadas na Memria de Reunio com a Gerncia de Sistema de Informao (WP-05).

y y

1 rea de Processo 2 Stakeholder um indivduo ou um grupo afetado pelo resultado ou responsabilizado por um produto/artefato. Pode incluir membros da equipe do projeto, cliente, usurios finais. Um stakeholder relevante aquele identificado para envolvimento numa atividade especificada e que est includo no plano.

PRO_CM Processo de Gerncia de Configurao Reviso: 8 Aprovao: Daniella Gobira

1. Poltica Organizacional Garantir a integridade das baselines geradas e a disponibilizao da verso solicitada dos itens de configurao. Garantir a Gerncia de dados e o rastreamento das solicitaes de mudanas. 2. Planejamento do Processo 2.1 Definio do Processo O objetivo do Processo de Gerncia de Configurao assegurar a integridade dos artefatos de trabalho ao longo de todo o ciclo de vida do projeto, o que envolve estabelecer as baselines do produto, identificar os itens de configurao que comporo as baselines, controlar as mudanas dos itens de configurao e garantir a integridade das baselines, alm de fornecer a situao e os dados da configurao atual. Macro-atividade 1: Planejamento da Gerncia de Configurao Objetivo: Planejar o processo de Gerncia de Configurao, seguindo o estabelecido neste documento.

y y

y y y

Atividade: Planejar Gerncia de Configurao e Baseline. Descrio: Planejar as datas em que o Gerente de Configurao deve realizar as auditorias e gerar as baselines. Identificar as baselines que sero criadas e os itens de configurao que comporo cada baseline, de forma a garantir a contnua evoluo dos itens de configurao. Nesta atividade, definido tambm o momento de criao de cada baseline. A nomenclatura utilizada para denominar as baselines dever seguir o padro definido no documento de Gerncia de Configurao (IT-PRO-09). Responsvel: Gerente do Projeto. Participantes: Gerente de Configurao. Artefato: Plano de Gerncia de Configurao.

y y

y y

Atividade: Estabelecer Sistema de Gerncia de Configurao e de Controle de Mudana. Descrio: Identificar o Sistema de Gerncia de Configurao e de Controle de Mudanas a ser utilizado no projeto, o que significa escolher entre as opes fornecidas na empresa, identificando mdia de armazenamento, procedimentos e ferramentas. Caso necessrio, identificar os sistemas considerando os tipos especficos de itens de configurao (cdigo e documentos). Responsvel: Gerente de Configurao. Artefato: Identificao do Sistema de Gerncia de Configurao e do Sistema de Controle de Mudanas.

Macro-atividade 2: Gerncia de Baselines Objetivo: Liberar baselines para uso interno ou para entrega ao cliente.

y y

y y

Atividade: Auditar as Baselines. Descrio: Auditar para verificar a integridade dos itens de configurao presentes na baseline. Antes da criao da baseline, o Gerente de Configurao registra as informaes da auditoria no Registro de Auditoria de Baseline (WP-CM-02). Responsvel: Gerente de Configurao. Artefato: Baseline Auditada, Registro de Auditoria de Baselines (WP-CM-02).

y y y y

Atividade: Gerar Baseline. Descrio: Aps a execuo da auditoria pelo Gerente de Configurao, caso o mesmo no detecte problemas durante a execuo da mesma, a baseline gerada. Responsvel: Gerente de Configurao. Artefato: Baseline gerada, e-mail aos stakeholders envolvidos.

y y

y y

Atividade: Liberar Baseline. Descrio: Aps a gerao da baseline, as alteraes que sejam necessrias devero ser registradas em uma solicitao de mudana. Sendo a solicitao aceita, o Gerente de Configurao dever liberar a baseline para alterao. Essa atividade descrita na IT-PRO-10 Controle de Mudana. Responsvel: Gerente de Configurao. Artefato: Registro de Liberao da Baseline (WP-CM-03).

Macro-atividade 3: Controle de Mudanas Objetivo: Controlar as mudanas que ocorrem nos itens de configurao. Antes de modificar um item de configurao, necessrio obter a aprovao da Solicitao de Mudana (WP-15). Tambm necessrio que a mudana efetuada seja aprovada antes que seja disponibilizada a nova verso do item que a contm.

y y

y y

Atividade: Solicitar Mudana. Descrio: Preencher a Solicitao de Mudana em um item de configurao, estabelecendo o tipo de mudana, justificando a necessidade e explicitando as suas implicaes (benefcios e impacto em planos e artefatos). Responsveis: Stakeholders. Artefato: Solicitao de Mudana (WP-15).

y y

y y y

Atividade: Analisar Impactos das Possveis Mudanas. Descrio: Analisar as solicitaes de mudana, revisando as implicaes com base na Matriz de Rastreabilidade (WP-REQM-06) e a sua consistncia com todos os requisitos. Responsveis: Gerente de Requisitos Participante: Lder de Codificao Artefato: Registro da anlise sobre o impacto das mudanas e estimativa de esforo.

y y

y y y

Atividade: Analisar Solicitao de Mudana. Descrio: Com base nas informaes repassadas pelo Gerente de Requisitos, o Gerente de Projeto faz a anlise e informa o custo da mudana a partir do esforo informado pelo Gerente de Requisitos. A Solicitao de Mudana atualizada e pode ser aprovada, postergada, no aprovada ou aguardando anlise do Comit de Controle de Mudanas. Responsveis: Gerente de Projeto Participantes: Comit de Mudana (se necessrio). Artefato: Solicitao de Mudana analisada.

y y

y y

Atividade: Implementar Mudana. Descrio: Implementar a mudana nos itens de configurao depois que a Solicitao de Mudana tenha sido aprovada. Aps concluso da implementao, ela submetida para reviso pelos responsveis pela aprovao das mudanas nos itens de configurao em questo. Responsveis: Stakeholder Responsvel. Artefatos: Itens de configurao modificados.

y y

y y

Atividade: Verificar Itens de Configurao Modificados Descrio: Acessar os itens de configurao que foram modificados e analisar as mudanas efetuadas para assegurar que as mudanas no causaram efeitos indesejados. A anlise deve ser sempre realizada tendo como base a Matriz de Rastreabilidade. Caso a alterao seja aprovada, gerada uma nova verso para o item de configurao contendo a mudana efetuada, que includa no Sistema de Gerncia de Configurao. Responsveis: Responsveis pela Anlise da Mudana. Artefato: Nova verso do item de configurao.

3. Recursos Para executar este processo so necessrios: y y Pessoal treinado conforme o item 5. Ferramentas: MS-Word, MS-Excel, Subversion, CaMMIla (Gerenciador de Projetos de Sistema), DOC (ferramenta de gerenciamento de arquivos), EAD (ferramenta de ensino distncia).

OBS: A prtica SP 1.2 est sendo atendida por ferramentas e procedimentos que sero utilizados por toda a empresa, no havendo diferena entre projetos. Neste item, so identificadas as ferramentas. 4. Responsabilidade As responsabilidades por cada atividade do processo esto identificadas no item 2.1 deste documento (Definio do Processo). 5. Treinamento

Para execuo destes processos os profissionais envolvidos em suas atividades devem ser treinados em: y Gerente da Fbrica de Software: o Introduo ao CMMI; o PRO_CM Processo de Gerncia de Configurao; o IT-PRO-9 Gerncia de Configurao; o Ferramentas: CaMMIla (Viso de Gerncia de Configurao) e Subversion. Gerente do Projeto: o Introduo ao CMMI; o PRO_CM Processo de Gerncia de Configurao; o IT-PRO-9 Gerncia de Configurao; o Ferramentas: CaMMIla (Viso de Gerncia de Configurao) e Subversion. Analista de Sistemas, Desenvolvedor, Homologador e Documentador: o Introduo ao CMMI; o PRO_CM Processo de Gerncia de Configurao; o Ferramentas: Subversion. Gerente de Configurao: o Introduo ao CMMI; o PRO_CM Processo de Gerncia de Configurao; o IT-PRO-6 Garantia da Qualidade do Produto e do Processo; o IT-PRO-9 Gerncia de Configurao; o IT-PRO-10 Controle de Mudana; o IT-PRO-11 Planejamento do Projeto; o IT-PRO-12 Gerncia de Requisitos; o IT-PRO-13 Medio e Anlise; o IT-PRO-14 Monitorao e Controle do Projeto; o Ferramentas: CaMMIla (Viso de Gerncia de Configurao) e Subversion; Grupo de Garantia da Qualidade do Produto e do Processo (PPQA): o Introduo ao CMMI; o PRO_CM Processo de Gerncia de Configurao; o IT-PRO-09 Gerncia de Configurao; o Ferramenta: CaMMIla (Viso de Gerncia de Configurao).

6. Stakeholders Relevantes Os stakeholders relevantes para a execuo do processo esto identificados no item 2.1 (Definio do Processo). 7. Monitorao e Controle do Processo A monitorao e controle do processo realizada; 1. Mtricas de monitorao do processo definidas no documento de Medio e Anlise (IT-PRO-13); 2. Avaliao do Gerente do Projeto: O Gerente do Projeto avalia a adequao do processo durante a execuo do projeto.O SEPG avalia a viabilidade das sugestes / oportunidades de melhoria detectadas no decorrer de um projeto 3. Avaliao de Encerramento do Projeto: A equipe da Fbrica de Software envolvida no projeto, conduzida pelo Gerente do Projeto, avalia o processo na avaliao de encerramento do desenvolvimento, ao final da ltima macro-atividade, preenchendo um questionrio. Essas informaes so sintetizadas pelo Gerente do Projeto e transmitidas aos Stakeholders relevantes atravs de e-mail ou Reunio de Encerramento de Projeto. 8. Avaliao Objetiva da Aderncia ao Processo A aderncia aos processos avaliada pelo PPQA, periodicamente, conforme definido no plano do projeto, quando avaliada a aderncia a todos os processos, utilizando checklists pr-

definidos. As atividades realizadas pelo PPQA so avaliadas por auditores externos ao PPQA para se garantir a objetividade necessria, tambm utilizando checklists. 9. Reviso do Status do Processo com a Gerncia Snior A Reviso do Status do Progresso do Processo de Gerncia de Configurao ocorre conforme descrito no item 9 do Processo de Monitorao e Controle.

IT-PRO-9 - Gerncia de Configurao Reviso: 9 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para atender ao Processo de Gerncia de Configurao (PRO_CM). 2. Executante da Tarefa Gerente de Configurao, Gerente de Projeto e equipe do projeto, quando necessrio. 3. Documentos Complementares y y y y y y PRO_PD Processo de Desenvolvimento; PRO_CM Processo de Gerncia de Configurao; IT-PRO-10 Controle de Mudana; IT-PRO-11 Planejamento do Projeto; LISTA-FBRICA DE SOFTWARE Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

4. Recursos Necessrios y y CaMMIla Ferramenta que apia a Gesto dos Projetos; Ferramenta para Gerncia de Configurao TortoiseSVN (front-end) e Subversion.

5. Atividades Principais Descrever como realizado o controle da criao, alteraes e liberao dos itens de configurao, respectivas baselines e suas verses ao longo do desenvolvimento do software. Os itens de configurao so identificados, analisados, corrigidos, aprovados e armazenados no repositrio SVN. Desta forma, garante a concluso, consistncia e correo dos itens, controlando o armazenamento, manipulao e distribuio dos itens de configurao. 5.1 Planejamento das Atividades da Gerncia de Configurao Atravs de e-mail enviado, o Gerente do Projeto convoca o Gerente de Configurao para a reunio de KickOff e apresenta o Plano do Projeto (WP-PP-01), conforme definido no documento de Planejamento do Projeto (IT-PRO-11). 5.1.1 Gerar Plano de Gerncia de Configurao Para gerar o Plano, durante a reunio de Kick Off, o Gerente do Projeto informa as datas que o Gerente de Configurao deve realizar as auditorias e gerar as Baselines. Essas datas so acordadas com os participantes da reunio e ajustadas no Cronograma do Projeto, caso necessrio. Aps a realizao do upload do Cronograma do Projeto (criado no Project) no CaMMIla, as tarefas podem ser visualizadas na prpria ferramenta, na guia Projeto,na opo Tarefa. Para compor o plano com os itens de configurao de cada baseline, o Gerente do Projeto clica na Guia Projeto do CaMMIla , escolhe a opo Plano e preenche a aba Gerncia de

Configurao. Para isso o critrio para identificar itens de configurao, definido no item 5.2 deste documento, levado em considerao. 5.2 Identificao dos Itens de Configurao Item de configurao tudo que compe a Gerncia de Dados do Projeto. A Avansys versiona e controla os itens de Configurao, atravs da ferramenta Subversion, que manipulada atravs do front-end TortoiseSVN. Todos os itens de configurao esto sob controle de mudana, sendo que alguns deles passam por um processo formal para serem modificados, so eles: artefatos que esto contidos em baselines aprovadas. Todos os outros artefatos que esto armazenados no repositrio esto sob processo de controle informal de mudana esses so itens de configurao que no causam impacto no produto final, ou seja, no interferem no custo e prazo do projeto e por isso no necessitam de um controle formal de mudana, ex: Memria de Reunio, Registros de Avaliao de Peer-review. O plano de baseline indica quais baselines sero geradas ao longo do processo de desenvolvimento e quais artefatos as comporo. Os itens de configurao gerados e controle de acesso a cada um deles, encontram-se descritos no Plano de Gerncia de Dados. Os papis da Fbrica de Software que possuem permisso de editar os documentos so os responsveis pelos mesmos. O armazenamento dos itens de configurao definido na Lista de Registros e Artefatos da FSW. 5.3 Identificao da Baseline A AVANSYS adotou o seguinte critrio para definio de uma baseline: A baseline composta por itens de configurao que serviro de base para a prxima fase do projeto e necessitem de um controle formal de mudanas, ou seja, uma Solicitao de Mudana encaminhada ao Gerente do Projeto via CaMMIla, conforme especificado no documento de Controle de Mudana (IT-PRO-10). Baselines que so geradas e ainda dependem de aprovao por parte do cliente ainda no esto sob controle formal de mudana e podem ser alteradas apenas com o registro do que foi alterado de uma verso para outra. A partir do momento que a baseline aprovada, ela passa a estar sob controle formal de mudana, sendo necessrio uma Solicitao de Mudana para qualquer alterao. As baselines so identificadas seguindo o esquema de identificao a seguir: 1. Mtodos de Identificao - O objetivo deste esquema padronizar a nomenclatura de identificao das baselines, favorecendo o trabalho do Gerente de Configurao, alm de permitir maior controle e organizao das baselines. 2. Nomenclatura Adotada para baselines - As baselines so criadas seguindo o padro de nomenclatura: X.Y.Z.beta'n' , onde: Mudana na estrutura da aplicao Adio de novas funcionalidades Melhoria desenvolvida ou correo de bugs/erros Indica que a baseline ainda no foi aprovada pelo cliente. 'n' nmero sequencial que beta'n' indica a verso da baseline beta X Y Z y y y y Todos os nmeros so incrementais A mudana X mandatria e caso essa ocorra os demais nmeros ficam em ZERO. A mudana do Y implica em zerar o Z. Quando a baseline aprovada pelo cliente a sigla beta'n' deve ser retirada.

Exemplo: y No caso de correo de problemas a baseline sai da verso 1.3.7 para 1.3.8

y y

No caso de adio de funcionalidades (independente de correo de problemas) a baseline sai da verso 1.3.8 para 1.4.0 Caso mude a arquitetura, ou uma reengenharia do projeto, a baseline sai da verso 1.4.7 para 2.0.0

Observaes: y y As baselines no possuem prazo fixo de criao, podendo mudar de acordo com a necessidade do projeto. Havendo necessidade de gerar uma baseline extra (fora do que foi especificado no Cronograma do Projeto), o Gerente Funcional solicita ao Gerente de Configurao, informando o tipo da baseline que dever ser gerada, a data de gerao e o contedo da mesma. A Verso/Reviso, nada tem a ver com a verso final do produto de software.

5.3.1 Baseline Intermediria Baselines so consideradas intermedirias quando ainda no foram aprovadas pelo cliente. Nesse caso, quando o cliente solicita correes nos artefatos no necessrio o registro de uma solicitao de mudana, o controle do que foi alterado de uma verso para outra atravs do comentrio no momento do commit que deve descrever o que foi alterado. No caso de adiantamento de fases, a fase adiantada deve trabalhar em cima de uma baseline intermediria, que pode conter todos os documentos da fase anterior ou apenas os que j foram concludos e avaliados em peer-review. Nesse caso, quando uma nova baseline for disponibilizada, seja ela intermediria ou final, a anlise de impacto do adiantamento de fase ser com base no histrico de comentrios do commit que deve informar todas as alteraes que aconteceram de uma baseline para outra. Quando uma ou mais atividades precisarem ser refeitas por causa de mudanas em cima de baselines intermedirias, as horas gastas no devero ser contabilizadas como retrabalho. 5.4 Gerncia de Baselines e Itens de Configurao no CaMMIla As baselines so auditadas e geradas pelos lderes das fases de requisitos, anlise, projeto, codificao e teste, que neste momento assumem o papel de gerentes de configurao. Para gerar as baselines, o Gerente de Configurao acompanha a tarefa do Projeto no CaMMIla e, nas datas especificadas confirma a viabilidade da gerao das mesmas. Caso as condies dos itens de configurao sejam favorveis, a baseline gerada. Porm, caso o Gerente de Configurao detecte que no h condies de gerar a baseline na data estabelecida, o mesmo replaneja as datas juntamente com o Gerente do Projeto. 5.4.1 Cadastro e Auditorias de Baselines Conforme definido no Cronograma de CM, o Gerente de Configurao realiza as auditorias das baselines antes da gerao das mesmas para verificar a integridade dos itens de configurao. Para isso o Gerente de Configurao acessa o CaMMIla, na guia Projeto na opo Baseline, escolhe o projeto na opo Projeto em Uso e cadastra uma nova baseline, informando o nmero da mesma. Seleciona a fase que pertence a baseline, que pode ser de anlise, codificao, projeto tcnico, requisito ou teste e no campo comentrio informa o nmero da baseline que serviu como base para elaborao da baseline que est sendo gerada. Aps realizar o cadastro, salva os dados atravs do boto Salvar. Em seguida o Gerente de Configurao realiza a auditoria da baseline que feita por amostra de contedo. Antes da criao da baseline, o Gerente de Configurao registra as informaes da auditoria no CaMMIla. Para a auditoria da baseline de cdigo o GC verifica pelo menos um cdigo fonte alterado/criado por cada um dos codificadores do projeto, em sistemas divididos em mdulos o critrio seguido para cada um dos mdulos do sistema. Para responder algumas perguntas da auditoria da baseline, o Gerente de Configurao verifica a Gerncia de Dados. Sempre que o Gerente do Projeto, durante a Monitorao e

Controle dos Projetos, detecte que h necessidade de atualizar a Gerncia de Dados para representar a realidade do projeto, ele informa ao Gerente de Configurao. Alguns itens que so verificados na auditoria das baselines so: y y Garantir que as alteraes em relao baseline anterior foram documentadas; Garantir que os itens de configurao que vo compor a baseline e a sua nomenclatura correspondem ao que est descrito no Plano de Gerncia de Dados e Plano de Configurao; Garantir que a verso dos itens de configurao includos na Baseline realmente corresponde verso aprovada no momento da sua criao; Garantir que a nomenclatura da baseline est apropriada; Garantir no fechamento de uma nova baseline, que apenas os artefatos impactados tenham sofrido alteraes.

y y y

Com a baseline cadastrada e auditada, o Gerente de Configurao define se aprova ou no a criao da baseline. Caso no seja aprovada, o Gerente de Configurao cria um Plano de Ao para resolver todas as pendncias detectadas e acompanha a soluo dos problemas. A baseline s gerada caso a auditoria seja aprovada. Para os casos em que as pendncias no sejam resolvidas no prazo especificado, o Gerente de Configurao aciona o PPQA por e-mail, informando o acontecido e os problemas detectados, para que o mesmo se encarregue de gerar um desvio. Desta forma, o acompanhamento ocorre por parte do PPQA e do Gerente de Configurao. Para registrar a Auditoria no CaMMIla necessrio clicar na opo Auditar da baseline cadastrada. necessrio informar o parecer da Auditoria selecionando uma das opes: Aprovada ou Reprovada e descrever as observaes necessrias no campo Comentrio. Aps o cadastro necessrio Salvar. Aps executar as auditorias e no detectar problemas, o Gerente de Configurao gera as baselines conforme descrito no item 5.4.2. 5.4.2 Gerar Baselines Ao Salvar os dados da Auditoria o campo Status alterado para Auditada. Se o parecer da auditoria for Reprovada o boto Gerar Baseline no ser exibido. Aps a aprovao possvel clicar no boto Gerar Baseline para gerar a mesma.

Aps a gerao de uma baseline, o CaMMIla notifica por e-mail todos os envolvidos a respeito da criao. Os profissionais utilizam o TortoiseSVN (cliente do Subversion) para baixar uma baseline liberada e fazer as modificaes necessrias. Aps modificado, os profissionais enviam as alteraes feitas na baseline para o solicitante da mudana avaliar e para que a nova reviso seja gerada. 5.4.3 Controle de Verses Todos os artefatos utilizados pelo projeto e submetidos s alteraes so versionados automaticamente pela ferramenta Subversion. O repositrio do projeto no Subversion possui a estrutura trunk, branches e tags e cada pasta possui as fases do processo de desenvolvimento. trunk: Contm a verso em desenvolvimento do sistema. a partir desta verso que as baselines so geradas. OBS: O import inicial do cdigo-fonte do projeto feito neste repositrio. tags: Contm as baselines geradas. branches: Contm uma baseline liberada para modificao. As baselines ficam neste repositrio temporariamente at que a modificao seja feita e implementada.

As atualizaes dos itens de configurao no repositrio devem ocorrer diariamente para garantir o backup dos dados. Em casos onde o commit dirio no seja possvel adotaremos os seguintes prazos: 1. 1 dia til para artefatos gerais 2. 3 dias teis para memrias de reunio 3. Para artefatos do tipo cdigo fonte que estejam com erro que impacte no funcionamento da aplicao o commit no ser realizado e o lder de codificao deve ser informado para que auxilie na resoluo do problema. Logo que a situao esteja resolvida o cdigo dever ser commitado. A cada commit dado no SVN obrigado que as alteraes feitas sejam documentadas no TortoiseSVN (front-end do Subversion) como histrico de mudana. Quando um artefato tipo cdigo fonte alterado por mais de um profissional ao mesmo tempo, a ferramenta realiza um merge das alteraes e gera a nova verso. 5.4.4 Recuperao dos Itens de Configurao Aps a gerao das baselines a ferramenta CaMMIla informa via e-mail a todos os envolvidos que a mesma foi gerada com sucesso. Para baselines aprovadas, a partir desta data, as alteraes que sejam necessrias so registradas em uma Solicitao de Mudana e seguem o documento de Controle de Mudana (IT-PRO-10). 5.5 Monitorao e Controle do Processo A Monitorao e Controle da PA de Gerncia de Configurao realizada conforme especificado na IT-PRO-13 Medio e Anlise item 5.1.1.2 Mtricas de Monitorao e Controle dos Processos. Alm disso, existe o trabalho de melhoria de processos realizado pelo SEPG. Antes da sua reunio mensal do SEPG, a Coordenao do SEPG solicita que o PPQA envie por e-mail as informaes da mtrica de percentual de desvio por PA, com o intuito de consolid-las. As informaes relativas s no-conformidades da PA de PPQA so levadas em considerao nesta consolidao feita pelo SEPG. Durante essa reunio, as informaes e anlises tratadas em conjunto so registradas. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado com a anlise das mtricas. Caso sugestes / oportunidades de melhorias sejam identificadas, a equipe do projeto cadastra as mesmas no CaMMIla para anlise do SEPG. 5.6 Comunicao do Status dos Processos Mensalmente, durante a reunio de reporte do PPQA para a Gerncia de Sistema de Informao, as informaes relacionadas Gerncia de Configurao, coletadas durante as avaliaes so tratadas e documentadas na Memria de Reunio com a Gerncia de Sistema de Informao (WP-05). No decorrer da reunio, o Gerente de Sistema de Informao entra em contato com o Gerente de Configurao para tomar conhecimento sobre o andamento das atividades do Gerente de Configurao. Caso necessrio, um Plano de Ao (WP-PMC-03) gerado pelo Gerente do Projeto para solucionar algum problema detectado durante a reunio acima mencionada ou durante o andamento dos Projetos.

PRO_MA Processo de Medio e Anlise Reviso: 8 Aprovao: Daniella Gobira

1. Poltica Organizacional Coletar e analisar as mtricas de forma a verificar se os objetivos organizacionais esto sendo alcanados. Realizar aes corretivas caso os indicadores no estejam de acordo com as metas definidas. Armazenar e comunicar os resultados obtidos.

2. Planejamento do Processo 2.1 Definio do Processo O objetivo do Processo de Medio e Anlise desenvolver e implantar a capacidade de avaliao das medidas (mtricas) que serviro como importantes fontes de informao para a Gerncia da Organizao. importante ressaltar que os benefcios de realizar medies vm das decises e aes tomadas como resposta anlise dos dados e no, apenas, de se coletar dados. Macro-atividade 1: Planejamento do Processo de Medio e Anlise da Organizao Objetivo: Identificar os objetivos organizacionais de medio e anlise, ou seja, identificar quais objetivos sero medidos para todos os projetos adotados pela organizao. Os objetivos so revistos periodicamente e atualizados quando necessrio. y y y Responsvel: Gerente de Sistema de Informao. Participantes: Gerente da Fbrica de Software. Artefato: Objetivos Organizacionais identificados no documento de Medio e Anlise

(IT-PRO-13), Plano de Medio e Anlise da Fbrica de Software (WP-MA-01). Macro-atividade 2: Planejar Medio e Anlise Objetivo: Produzir o Plano de Medio e Anlise contendo as datas das atividades relacionadas ao processo de medio e anlise, assim como os responsveis por estas atividades. Os objetivos so revistos periodicamente e atualizados quando necessrio. Atividade:Alinhar Atividades de Medio e Anlise y Descrio: Identificar objetivos e prticas para medies de forma que estes estejam alinhados s necessidades e objetivos de informao da Organizao.

Sub-Atividades:

y y

y y

Nome: Identificar Objetivos de Medio Descrio: Estabelecer objetivos para medies derivados das necessidades e objetivos de informao da Organizao conforme definido no Planejamento Estratgico. Os objetivos so revistos periodicamente e atualizados quando necessrio. Responsvel:Responsvel pela Medio e Anlise. Artefato: Objetivos de Medio Identificados no documento de Medio e Anlise (ITPRO-13) e Planejamento Estratgico.

y y

y y

Nome: Identificar Questes de Medio Descrio: Estabelecer questes a serem respondidas para que os objetivos de medio da Organizao possam ser mensurados. As questes so revistas periodicamente e atualizadas quando necessrio. Responsvel: Responsvel pela Medio e Anlise. Artefato: Questes de Medio identificadas no documento de Medio e Anlise (ITPRO-13).

y y

Nome: Identificar Mtricas Descrio: Especificar medidas (mtricas) para avaliar o alcance dos objetivos definidos. So estabelecidas definies operacionais para as mtricas, isto , definies precisas e no ambguas. As mtricas so revistas periodicamente e atualizadas quando necessrio.

y y

Responsvel: Responsvel pela Medio e Anlise. Artefato: Plano de Medio e Anlise do Projeto (WP-MA-04), Mtricas identificadas no documento de Medio e Anlise (IT-PRO-13).

y y y y

Nome: Especificar Procedimentos de Coleta e Armazenamento Descrio: Especificar como os dados de medies sero obtidos e armazenados. Responsvel: Responsvel pela Medio e Anlise. Artefato: Procedimentos de Coleta e de Armazenamento identificados no documento de Medio e Anlise (IT-PRO-13).

y y

y y

Nome: Especificar Procedimentos de Anlise Descrio: Especificar como os dados de medies sero analisados e reportados. Deve-se cuidar para que a anlise esteja explicitamente relacionada aos objetivos de medio documentados e que a apresentao dos resultados seja clara para a audincia qual os resultados se destinam. Sempre que necessrio o contedo e formato da anlise e dos relatrios so revistos. Esta reviso baseada em uma anlise da utilidade dos dados e na realizao das atividades de medio e anlise. Responsvel: Responsvel pela Medio e Anlise. Artefato: Procedimentos de Anlise identificados no documento de Medio e Anlise (IT-PRO-13).

Macro-atividade 3: Fornecer Resultados das Medies Objetivo: Obter e fornecer os resultados das medies realizadas de acordo com as necessidades e objetivos de informao identificados pela organizao. Atividade: Coletar Dados de Medies y y y y Descrio: Obter os dados das medies de acordo com os procedimentos especificados para coleta, garantindo sua integridade. Responsvel: Responsvel pela Medio e Anlise. Participantes: Stakeholders Responsveis. Artefato: Medidas Coletadas.

Atividade: Analisar Dados de Medies y y y Descrio: Analisar e interpretar os dados obtidos nas medies conforme procedimento de anlise definido. Responsvel: Responsvel pela Medio e Anlise. Artefato: Relatrio de Resultados de Medio e Anlise do Projeto (WP-MA-05) e Relatrio de Resultados de Medio e Anlise da Fbrica de Software (WP-MA-02).

Atividade:Armazenar Dados e Resultados y Descrio: Gerenciar e armazenar os dados obtidos nas medies, assim como a especificao das medies e os resultados de anlise. Armazenar informaes relacionadas, de forma a fornecer um contexto para interpretao dos dados e da anlise realizada. Garantir a disponibilizao dos dados, informaes e anlises apenas aos usurios adequados. Garantir o uso adequado das informaes e dados armazenados. Responsvel: Responsvel pela Medio e Anlise. Artefato: Relatrio de Resultados de Medio e Anlise do Projeto (WP-MA-05) e Relatrio de Resultados de Medio e Anlise da Fbrica de Software (WP-MA-02).

y y

Atividade: Comunicar Resultados

y y y

Descrio: Comunicar os resultados das medies e das atividades de anlise aos envolvidos. Procura-se meios de garantir que os destinatrios entendam os resultados e sua relao com os objetivos e necessidades de informao. Responsvel: Responsvel pela Medio e Anlise. Participantes: Gerente de Sistema de Informao e Gerente da Fbrica de Software. Artefato: Relatrio de Resultados de Medio e Anlise do Projeto (WP-MA-05) e Relatrio de Resultados de Medio e Anlise da Fbrica de Software (WP-MA-02).

3. Recursos Para executar este processo so necessrios: y y Pessoal treinado conforme o item 5; Ferramentas: MS-Word, MS-Excel, CaMMIla(Gerenciador de Projetos de Sistema), AvanDOC (ferramenta de gerenciamento de arquivos), AvanEAD (ferramenta de ensino distncia).

4. Responsabilidade As responsabilidades por cada atividade do processo esto identificadas no item 2.1 deste documento (Definio do Processo). 5. Treinamento Para execuo deste processo os profissionais envolvidos em suas atividades sero treinados em: y Gerente da Fbrica de Software: o Introduo ao CMMI; o PRO_MA Processo de Medio e Anlise; o IT-PRO-13 Medio e Anlise; o Ferramenta: CaMMIla (Viso de Medio e Anlise). Gerente de Projetos: o Introduo ao CMMI; o PRO_MA Processo de Medio e Anlise; o IT-PRO-13 Medio e Anlise; Analista de Sistemas, Desenvolvedor, Homologador e Documentador: o Introduo ao CMMI; o PRO_MA Processo de Medio e Anlise; Grupo de Garantia da Qualidade do Produto e do Processo (PPQA): o Introduo ao CMMI; o PRO_MA Processo de Medio e Anlise; o IT-PRO-13 Medio e Anlise; o Ferramenta: CaMMIla (Viso de Medio e Anlise).

6. Stakeholders Relevantes Os stakeholders relevantes para a execuo do processo esto identificados no item 2.1 (Definio do Processo). 7. Monitorao e Controle do Processo A monitorao e controle do processo so realizados atravs de: 1. Mtricas de monitorao do processo esto definidas no documento de Medio e Anlise (IT-PRO-13). 2. Avaliao do Gerente de Projetos: O Gerente de Projetos avalia a adequao do processo durante a execuo do projeto. O SEPG avalia a viabilidade das sugestes / oportunidades de melhoria detectadas no decorrer de um projeto. 3. Avaliao de Encerramento do Projeto

A equipe da Fbrica de Software envolvida no projeto, conduzida pelo Gerente de Projetos, avalia o processo na avaliao de encerramento do desenvolvimento, ao final da ltima macroatividade, preenchendo um questionrio. Essas informaes so sintetizadas pelo Gerente de Projetos e transmitidas aos Stakeholders relevantes atravs de e-mail ou Reunio de Encerramento de Projeto. 8. Avaliao Objetiva da Aderncia ao Processo A aderncia aos processos avaliada pelo PPQA, periodicamente, conforme definido no documento de Garantia da Qualidade do Produto e do Processo (IT-PRO-01), quando avaliada a aderncia a todos os processos, utilizando checklists pr-definidos. As atividades realizadas pelo PPQA so avaliadas por auditores externos ao PPQA para se garantir a objetividade necessria, tambm utilizando checklists. 9. Reviso do Status do Processo com a Gerncia Snior A Reviso do Status do Progresso do Processo de Medio e Anlise ocorre conforme descrito no item 9 do Processo de Monitorao e Controle. Os responsveis pela anlise dos indicadores de Medio e Anlise da Fbrica de Software e pela anlise dos indicadores de Medio e Anlise do Projeto realizam reunies, conforme periodicidade especificada no documento de Medio e Anlise (IT-PRO-13) com o Gerente de Sistema de Informao. Essas reunies so documentadas Memria de Reunio com o Gerente de Sistema de Informao(WP-05) ou em Ata de Reunio do SEPG.

IT-PRO-13 Medio e Anlise Reviso: 12 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para atender ao Processo de Medio e Anlise (PRO_MA). 2. Executante da Tarefa Responsvel pela Medio e Anlise. 3. Documentos Complementares y y y y y y y y y y y PRO_PD Processo de Desenvolvimento; PRO_MA Processo de Medio e Anlise; PRO_PP Processo de Planejamento do Projeto; PRO_REQM Processo de Gerncia de Requisitos; PRO_PMC Processo de Monitorao e Controle do Projeto; PRO_PPQA Processo de Garantia da Qualidade do Produto e do Processo PRO_CM Processo de Gerncia de Configurao; IT-PRO-11 Planejamento do Projeto; IT-PRO-14 Monitorao e Controle dos Projetos; LISTA-FBRICA DE SOFTWARE Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

4. Recursos Necessrios 1. CaMMIla Gerenciador de Projetos de Sistema. 2. Subversion 5. Atividades Principais

Descrever como realizada a coleta e anlise das mtricas, levando em considerao os objetivos adotados pela Organizao, bem como a monitorao e controle dos processos da Fbrica de Software e a monitorao e controle dos projetos. Anualmente, as mtricas so revisadas pelo SEPG e, caso haja necessidade de ajustes, os mesmos so executados com o intuito de mant-las em conformidade com os objetivos adotados pela Organizao. 5.1 Planejamento do Processo Para o planejamento das atividades de Medio e Anlise, duas atividades so executadas: y Plano de Medio e Anlise do Projeto (WP-MA-04) um sub-plano do Plano do Projeto (WP-PP-01) que contm as mtricas que sero coletadas para o projeto e as datas de coleta e anlise das mesmas. Plano de Medio e Anlise da Fbrica de Software (WP-MA-01) Plano contendo as datas de realizao das coletas, armazenamento, pr-anlise e anlise conjunta com a GSI das mtricas consolidadas dos projetos finalizados, com o objetivo de complementar o Relatrio de Resultados de Medio e Anlise da Fbrica de Software (WP-MA-02).

No CaMMIla necessrio preencher o Plano de MA com as Mtricas adotadas para o projeto, o cronograma deve prever as atividades de medio e anlise. 5.1.1 Plano de Medio e Anlise do Projeto Para gerar o Plano de Medio e Anlise do Projeto, o Gerente do Projeto, durante a reunio de Kick Off, informa as datas em que ele coleta e analisa as mtricas do projeto. Essas datas so acordadas com os participantes da reunio e ajustadas no Cronograma do Projeto. O Plano de Medio e Anlise do Projeto visualizado no CaMMIla e no Cronograma do Projeto e segue os itens 5.1.1.1 e 5.1.1.2 deste documento. Aps a realizao da atividade de coleta e anlise das mtricas de MA para o projeto, cadastradas no CaMMIla, o profissional responsvel pela medio armazena as informaes coletadas e registra sua pr-anlise no Relatrio de Resultados de Medio e Anlise do Projeto. Durante as reunies de reporte com a GSI e DTS, essas medidas so avaliadas e, nesse momento, registrada a anlise conjunta das informaes apresentadas na Memria de Reunio. 5.1.1.1 Mtricas Adotadas nos Projetos Objetivo Organizacional: Maximizar a Produtividade Objetivo Medio Questo Medio Nome Mtrica Descrio Mtrica Entidade Medida Frmula Unidade Medida Coleta de de de da da Medir a produtividade da equipe por projeto Qual a produtividade da equipe do projeto? Produtividade Medir a produtividade da equipe ao final de cada projeto. ( ) Processo ( ) Projeto (x)Pessoas ( ) Produto ( ) Outros Produtividade = Esforo real do projeto/Tamanho real do projeto. Onde Esforo real do projeto = somatrio do nmero de horas empregado durante todo o projeto. Tamanho real do projeto = nmero de pontos por funo do produto ao final do projeto. H/PF Fonte 1. Esforo Real do Projeto Relatrio do CaMMIla - Localizao:

Anlise

http://cammila.avansys.com.br 2. Tamanho Real do Projeto - RQ7.3K Clculo do Tamanho do Projeto atualizado aps anlise de requisitos. Localizao: https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/04analise/RQ-7.3K - Clculo do Tamanho do Projeto Periodicidade Final do Projeto Responsvel Gerente da Fbrica WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle Sincronismo Tecnologia utilizada (Java ou PHP) Fazer com que a a produtividade do projeto seja igual ou melhor do que produtividade estimada. A produtividade estabelecida Meta no Clculo de Tamanho do Projeto, realizado durante o Levantamento Preliminar. < do que a meta estabelecida, identificar causas, documentar como lies aprendidas para prximos projetos.OBS: Caso tornese frequente para os projetos da Fbrica de Software o no Aes cumprimento da meta estabelecida, um Plano de Ao dever ser aberto para tratar deste assunto a nvel organizacional. Sugesto de Aes: revisar as metas estabelecidas. Periodicidade Ao final do projeto Responsvel Gerente da Fbrica WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. 1 reunio de reporte, aps encerramento do projeto. WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto, aba Produtividade. Reunio Gerente da Fbrica e Gerente de Sistemas. RQ-7.3B - Memria de Reunio. ltima auditoria de PPQA do projeto. PPQA. Como o Relatrio de Resultado de Medio e Anlise do Projeto (WP-MA-05) j possui as frmulas de clculo da produtividade, para garantir a integridade das informaes, deve-se verificar se os dados informados na planilha esto corretos, ou seja, verificar no local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento.

Comunicao Periodicidade e Reporte Apresentao Forma Stakeholder(s) Sada Verificao de Integridade Periodicidade Stakeholder(s)

Critrio

Objetivo Organizacional: Minimizar o Retrabalho Objetivo Medio Questo Medio Nome Mtrica Descrio Mtrica Entidade Medida de Medir o esforo gasto com retrabalho.

de Qual o percentual de esforo em retrabalho com relao ao esforo do projeto? da Percentual de Retrabalho da Medir o esforo em retrabalho at o momento da monitorao. ( ) Processo ( ) Projeto (x)Pessoas ( ) Produto ( ) Outros

Frmula

Percentual de Retrabalho = (Esforo em retrabalho*100)/Esforo do projeto at o momento da monitorao. Onde Esforo em retrabalho = somatrio do nmero de hora empregada em retrabalho durante o projeto. Esforo do projeto at o momento da monitorao = somatrio do nmero de horas empregadas durante o projeto at o momento da monitorao. de % Esforo do Projeto, Esforo em Retrabalho Relatrios do CaMMIla. Localizao: http://cammila.avansys.com.br Periodicidade Durante as monitoraes e controle formais. Responsvel Gerente da Fbrica. WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. As informaes coletadas devem ser consideradas at o dia Sincronismo anterior coleta. (Dia-1) Fazer com que, o esforo em retrabalho no ultrapasse 10% Meta do esforo total do projeto at o momento da monitorao. At 10% de retrabalho aceitvel, pois est dentro da meta estabelecida. > 10% de retrabalho Identificar causas e gerar Aes Plano de Ao (WP-PMC-03) em nvel organizacional. Periodicidade Durante as monitoraes e controle formais. Responsvel Gerente da Fbrica WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. Fonte Mensal. WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto, aba Retrabalho. Reunio Gerente da Fbrica e Gerente de Sistemas. RQ-7.3B - Memria de Reunio. Nas auditorias de PPQA, conforme plano de PPQA. PPQA. Como o Relatrio de Resultado de Medio e Anlise do Projeto (WP-MA-05) j possui as frmulas de clculo do % de esforo em retrabalho, para garantir a integridade das informaes, deve-se verificar se os dados informados na planilha esto corretos, ou seja, verificar no local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento.

Unidade Medida Coleta

Anlise

Comunicao Periodicidade e Reporte Apresentao Forma Stakeholder(s) Sada Verificao de Integridade Periodicidade Stakeholder(s)

Critrio

5.1.1.2 Mtricas Adotadas para a Monitorao e Controle dos Projetos Objetivo Organizacional: Controlar Esforo Objetivo Medio Questo Medio Nome de Medir a dedicao gasta da equipe em relao a planejada at o momento da Monitorao e Controle do Projeto. de Qual a dedicao gasta da equipe no projeto at a data de Monitorao e Controle do Projeto? da Percentual de dedicao gasto no projeto em relao ao percentual planejado.

Mtrica Descrio da Medir o percentual de dedicao gasto em relao ao planejado at o Mtrica momento da Monitorao e Controle do Projeto. Entidade ( ) Processo ( ) Projeto (x)Pessoas ( ) Produto ( ) Outros Medida Frmula (Esforo gasto at o momento)*100/(Esforo planejado at o momento). Unidade de % Medida Esforo Planejado do Projeto, Esforo Atual do Projeto Coleta Fonte Relatrios do CaMMIla. Localizao: http://cammila.avansys.com.br Conforme definido no Plano de Monitorao e Controle do Projeto. Localizao: http://cammila.avansys.com.br / Projeto Periodicidade <nome do projeto> / Plano / Plano de PMC. Responsvel Gerente da Fbrica. WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto.Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. As informaes coletadas devem ser consideradas at o dia Sincronismo anterior coleta. (Dia-1) Fazer com que o esforo gasto no projeto no ultrapasse Anlise Meta 10% do esforo planejado. Caso o percentual de dedicao seja maior que o planejado, Aes o Gerente do Projeto deve gerar um Plano de Ao. Conforme definido no Plano de Monitorao e Controle do Periodicidade Projeto. Localizao: http://cammila.avansys.com.br / Projeto <nome do projeto> / Plano / Plano de PMC. Responsvel Gerente da Fbrica WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. Comunicao Periodicidade Mensal. e Reporte WP-MA-05 - Relatrio de Resultados de Medio e Anlise Apresentao do Projeto, aba Esforo. Forma Reunio Stakeholder(s) Gerente da Fbrica e Gerente de Sistemas. Sada RQ-7.3B - Memria de Reunio. Verificao de Periodicidade Nas auditorias de PPQA, conforme plano de PPQA. Integridade Stakeholder(s) PPQA. Como o Relatrio de Resultado de Medio e Anlise do Projeto (WP-MA-05) j possui as frmulas de clculo do % de dedicao gasto em relao ao planejado, para garantir a integridade das informaes, deve-se verificar se os dados informados na planilha esto corretos, ou seja, verificar no Critrio local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento. Objetivo Organizacional: Controlar o Custo Objetivo Medio de Medir o percentual de custo gasto em relao ao planejado at o momento da Monitorao e Controle do Projeto.

Questo de Qual o percentual do custo gasto em relao ao planejado at o momento da Medio Monitorao e Controle do Projeto? Nome da Percentual do Custo gasto em relao ao planejado. Mtrica Descrio da Medir o percentual do custo gasto em relao ao planejado at o momento da Mtrica Monitorao e Controle do Projeto. Entidade ( ) Processo (x) Projeto (x)Pessoas ( ) Produto ( ) Outros Medida (Custo Total Gasto)/(Custo Total Planejado) Onde: 1.Custo Total Gasto = do custo de cada profissional alocado no projeto. 2. Custo de Cada Frmula Profissional = custo da hora do profissional para a empresa * horas trabalhadas no projeto 3. Custo da Hora do Profissional para Empresa = (Custo Mensal com Salrio + Custo Mensal Administrativo)/Horas do Ms. Unidade de % Medida Custo Mensal do Profissional para a Empresa Repassado aos Gerentes de Projeto mensalmente pela Coleta Fonte Diretoria de Tecnologia e Servios. Horas Trabalhadas no Projeto - Relatrio no CaMMIla. Conforme definido no Plano de Monitorao e Controle do Projeto (WP-PMC-04). Localizao: Periodicidade http://cammila.avansys.com.br / Projeto <nome do projeto> / Plano / Plano de PMC. Responsvel Gerente do Projeto. WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. As informaes coletadas devem ser consideradas at o dia Sincronismo anterior coleta. (Dia-1). Fazer com que o Custo Total Gasto seja menor ou igual ao Anlise Meta Custo Total Planejado. Caso o Custo Total Gasto seja maior que o Planejado, o comit deve ser acionado. O comit nesse caso formado Aes pelo Gerente do Projeto, Gerente da Fbrica e Gerente de Sistemas. Conforme definido no Plano de Monitorao e Controle do Periodicidade Projeto. Localizao: http://cammila.avansys.com.br / Projeto <nome do projeto> / Plano / Plano de PMC. Responsvel Gerente do projeto WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. Comunicao Periodicidade Mensal. e Reporte WP-MA-05 - Relatrio de Resultados de Medio e Anlise Apresentao do Projeto, aba Custo. Forma Reunio Gerente do Projeto, Gerente de Sistemas, Diretoria de Stakeholder(s) Tecnologia e Servios. Sada RQ-7.3B - Memria de Reunio. Verificao de Periodicidade Nas auditorias de PPQA, conforme plano de PPQA. Integridade Stakeholder(s) PPQA. Como o Relatrio de Resultado de Medio e Anlise do Critrio Projeto (WP-MA-05) j possui as frmulas de clculo do % de custo gasto em relao ao planejado, para garantir a

integridade das informaes, deve-se verificar se os dados informados na planilha esto corretos, ou seja, verificar no local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento. Objetivo Organizacional: Cumprir Prazos Objetivo Medio Questo Medio Nome Mtrica Descrio Mtrica Entidade Medida Frmula Unidade Medida de Medir o percentual de execuo realizado em relao ao planejado, por fase, at a data de Monitorao e Controle do Projeto.(cronograma). de Qual o percentual de execuo realizado em relao ao planejado, por fase, at a data de Monitorao e Controle do Projeto? da Percentual de execuo realizado em relao ao planejado, por fase. da Medir o percentual de execuo realizado em relao ao planejado, por fase, at a data de Monitorao e Controle do Projeto. ( ) Processo (x) Projeto ( )Pessoas ( ) Produto ( ) Outros (% Executado da Fase)/(% Planejado para Execuo da Fase). de % WP-PP-03 - Cronograma do Projeto no MS Project. Onde Executado da Fase = Valor apresentado na coluna % CaMMIla no agrupamento de cada fase. Planejado para Execuo da Fase = Valor apresentado na coluna % concluda no agrupamento de cada fase. O Gerente do Projeto deve utilizar a opo Atualizar como agendado do MS Project para obter a informao do % Planejado para Fonte execuo da fase at o momento, os valores de % esperado para cada fase devem ser transportados para o Registro de Monitorao do CaMMIla. Em seguida o Gerente de Projeto copia todos os valores da coluna % CaMMIla para a coluna % Concludo e verifica o % executado de cada fase, esse % deve ser transportado para o Registro de Monitorao do CaMMIla. Conforme definido no Plano de Monitorao e Controle do Periodicidade Projeto. Localizao: http://cammila.avansys.com.br / Projeto <nome do projeto> / Plano / Plano de PMC. Responsvel Gerente do Projeto. 1- WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. Fazer com que o desvio de cronograma seja menor ou igual a Meta 10%. Caso o desvio seja maior que 10%, o Gerente de Projetos Aes deve gerar Plano de Ao. Conforme definido no Plano de Monitorao e Controle do Periodicidade Projeto. Localizao: http://cammila.avansys.com.br / Projeto <nome do projeto> / Plano / Plano de PMC. Responsvel Gerente do Projeto WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Armazenamento https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00documentacao/Medio e Controle. OBS: Levar em considerao a ltima verso existente. Mensal. WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto, aba prazo.

Coleta

Anlise

Comunicao Periodicidade e Reporte Apresentao

Forma Stakeholder(s) Sada Verificao de Integridade Periodicidade Stakeholder(s)

Reunio Gerente do Projeto, Diretoria de Tecnologia e Servios. RQ-7.3B - Memria de Reunio. Nas auditorias de PPQA, conforme plano de PPQA. PPQA. Como o Relatrio de Resultado de Medio e Anlise do Projeto (WP-MA-05) j possui as frmulas de clculo do % de execuo, para garantir a integridade das informaes, deve-se verificar se os dados informados na planilha esto corretos, ou seja, verificar no local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento.

Critrio

5.1.1.3 Mtricas de Monitorao e Controle dos Processos As mtricas de monitorao e controle dos processos, aps anlise durante reunio de comunicao do status dos processos, passam a ser tpicos abordados na reunio mensal que ocorre entre o SEPG. Objetivo Organizacional: Controlar a Qualidade Objetivo de Medir o percentual de desvios e no conformidades identificados por processo. Medio Questo de Qual o percentual de desvios e no conformidades identificados por Medio processos? Nome da Percentual de Desvios por PA. Mtrica Medir o percentual de desvios identificados por processos do CMMI pelo PPQA Descrio e o de no conformidades identificadas pela PPQA Externo para o caso da Mtrica exclusivo da PA de PPQA. Entidade (x) Processo ( ) Projeto ( )Pessoas ( ) Produto ( ) Outros Medida % de Desvios = (Nmero de desvios detectados na PA * 100) / Total de desvios. Onde: 1. Nmero de desvios detectados na PA = somatrio do nmero de desvios identificados para cada rea de processo ou no-conformidades, no Frmula caso da PA de PPQA. 2. Total de desvios = total de desvios de PPQA identificados at o momento da coleta + total de no-conformidades identificadas pela PPQA Externo at o momento da coleta. Unidade de % Medida 1) Nmero de desvios por PA e Total de desvios Relatrio de Acompanhamento dos Projetos (WP-PPQA-04). Localizao: https://svn.avansys.com.br/gsi.docs/processos/Acompanhamento _Projetos. 2) Nmero de No-conformidades do PPQA Coleta Fonte Relatrio de Acompanhamento das atividades do PPQA (WPPPQA-05). Localizao: https://svn.avansys.com.br/gsi.docs/processos/Acompanhamento _PPQA. 1 - Conforme definido no Plano de PPQA. Localizao: https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk02planejamento/WP-PP-03 - Cronograma do Projeto. 2 Mensal. || | |Responsvel| PPQA e PPQA Externo.|| | |Armazenamento| 1) WP-PPQA-04 - Relatrio de Acompanhamento dos Projetos. Periodicidade Localizao: https://svn.avansys.com.br/gsi.docs/processos/Acompanhamento _Projetos. 2) WP-PPQA-05 - Relatrio de Acompanhamento das atividades do PPQA. Localizao: https://svn.avansys.com.br/gsi.docs/processos/Acompanhamento _PPQA. || | |Sincronismo| No se aplica. || |Anlise |Meta| 1)

Manter uma uniformidade em relao ao percentual de desvios por PA em relao as PAs que tiveram desvios 2) Fazer com que o percentual de desvios por processo no ultrapasse a margem de 40%, pois como so 6 PAs, isso significaria que as outras variariam de 0% a 60%, sendo que em mdia ficaria 12% para cada PA. Obs: Para o caso de ser gerado at dois desvios em PAs diferentes considerar meta 1, acima disso, considerar meta 2. || | |Aes| > 40% de desvio em uma PA ou Mais de um desvio na mesma PA (para quando ocorrer desvio em apenas uma PA) Identificar causas e documentar na Memria de Reunio as decises tomadas. Recomenda-se reviso do processo da PA especfica, pois se o mesmo no est sendo seguido pode ser pelo fato de no estar adequado realidade. Caso seja necessrio, um Plano de Ao pode ser gerado. || | |Periodicidade| 1 - Conforme definido no Plano de PPQA. Localizao: https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk02planejamento/WP-PP-03 - Cronograma do Projeto. Responsvel PPQA 1) WP-PPQA-02 Checklist para Auditoria de Aderncia e Adequao ao Processo. Localizao: https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00Armazename documentacao/Garantia da Qualidade. 2) Relatrio de nto Acompanhamento dos Projetos. Localizao: https://svn.avansys.com.br/gsi.docs/processos/Acompanhamento _Projetos. Comunica o e Periodicidade Mensal. Reporte WP-PPQA-04 - Relatrio de Acompanhamento dos Projetos e Apresentao WP-PPQA-05 - Relatrio de Acompanhamento das atividades do PPQA. Forma Reunio Stakeholder(s PPQA e Gerente de Sistemas. ) Sada RQ-7.3B - Memria de Reunio. Verificao de Periodicidade 1. Mensalmente nas auditorias independentes de PPQA. Integridade Stakeholder(s PPQA e PPQA Externo. ) Como o Relatrio de Acompanhamento dos Projetos (WPPPQA-04) j possui as frmulas de clculo do % de desvios por PA, e a fonte de coleta a prpria planilha (WP-PPQA-04), para Critrio garantir a integridade das informaes, deve-se verificar se todos os desvios cadastrados esto sendo contados nos campos de somatrio. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento. OBS: Para as mtricas de CM, MA, REQM, PP e PMC so considerados os nmeros de desvios encontrados na PA durante as avaliaes realizadas pelo PPQA, enquanto que para a PA de PPQA, so considerados os nmeros de no-conformidades encontradas durante as avaliaes realizadas pela Coordenao da Qualidade. Objetivo Medio Questo Medio Nome Mtrica Descrio Mtrica de de da Medir o percentual de aderncia dos projetos. Qual o percentual de aderncia dos projetos? Percentual de aderncia por projeto.

da Medir o percentual de aderncia por projeto atravs das auditorias internas realizadas pelo PPQA.

Entidade Medida Frmula Unidade Medida Coleta de

(x) Processo (x) Projeto ( )Pessoas ( ) Produto ( ) Outros Grau de Aderncia = Nmero de Itens Conforme/Nmero de Itens Verificados Onde: 1. Nmero de Itens Conforme = Quantidade de itens marcados como conforme na planilha e 2. Nmero de Itens Verificados = Somatrio dos itens marcados como conforme e dos itens no conforme % WP-PPQA-02 Checklist para Auditoria de Aderncia e Adequao ao Processo. Localizao: Fonte https://svn.avansys.com.br/<cliente.projeto>/modulo/Docume ntacao/trunk/PPQA . Conforme definido no Plano de PPQA. Localizao: WP-PPPeriodicidade 03 - Cronograma do Projeto. Responsvel PPQA WP-PPQA-02 Checklist para Auditoria de Aderncia e Armazenament Adequao ao Processo. Localizao: o https://svn.avansys.com.br/<cliente.projeto>/modulo/Docume ntacao/trunk/PPQA . Sincronismo No se aplica. Manter a aderncia por projeto sempre > = 90% e alm disso verificar qual a variao das ltimas duas auditorias em Meta relao a atual. < 90% de aderncia em um projeto ou variao maior que 5%, recomenda-se avaliar para identificar se o problema no Aes projeto especfico ou de adaptao do processo. Caso seja necessrio, um Plano de Ao deve ser gerado. Conforme definido no Plano de PPQA. Localizao: WP-PPPeriodicidade 03 - Cronograma do Projeto. Responsvel PPQA e SEPG 1) WP-PPQA-04 Relatrio de Acompanhamento dos Projetos. Localizao: Armazenament https://svn.avansys.com.br/gsi.docs/processos/Acompanham ento_Projetos. 2) Memria de reunio do SEPG. Localizao: o https://svn.avansys.com.br/gsi.docs/processos/Memoria_Reu niao. Mensal. WP-PPQA-04 Relatrio de Acompanhamento dos Projetos. Reunio PPQA e SEPG. Memria de reunio do SEPG. Mensal. WP-PPQA-04 Relatrio de Acompanhamento dos Projetos. Reunio PPQA e Gerente de Sistemas WP-05 Memria de Reunio com o Gerente de Sistemas. 1. Mensalmente nas auditorias independentes de PPQA. 2. Nas auditorias programadas de PPQA PPQA e PPQA Externo. Como o Checklist para Auditoria de Aderncia e Adequao ao Processo (WP-PPQA-02) j possui as frmulas de clculo do grau de aderncia, e a fonte de coleta a prpria planilha (WP-PPQA-02), para garantir a integridade das informaes, deve-se verificar por amostragem se os itens conformes e no conforme esto sendo contados corretamente nos campos de somatrio. Alm disso verificar se as frmulas da

Anlise

Comunicao e Reporte - Periodicidade SEPG Apresentao Forma Stakeholder(s) Sada Comunicao e Reporte - Periodicidade GSI Apresentao Forma Stakeholder(s) Sada Verificao de Periodicidade Integridade Stakeholder(s)

Critrio

planilha esto corretas, de acordo com a frmula indicada nesse documento e se o valor obtido coerente (entre 0 e 100%). 5.1.2 Planejamento de Medio e Anlise da Fbrica de Software As datas de coleta, pr-anlise e armazenamento dos indicadores de cada projeto so planejadas no Plano de Medio e Anlise da Fbrica de Software. Aps a criao deste artefato, o mesmo adicionado ao repositrio da GSI (https://svn.avansys.com.br/gsi.docs/processos/Medicao_Analise_FSW. No esquecer que o planejamento destas datas feito levando em considerao a data do reporte mensal com a GSI. Dois Objetivos Organizacionais foram adotados na Fbrica de Software para respaldar as atividades de Medio e Anlise: Maximizar a Produtividade e Minimizar o Retrabalho. Para coletar as mtricas acima mencionadas, o Gerente do Projeto age conforme descrito no item 5.1.2.1 deste documento. A anlise conjunta com a GSI dessas mtricas trimestral,e envolve todos os projetos que foram finalizados durante esse perodo. 5.1.2.1 Mtricas Adotadas na Fbrica de Software Objetivo Organizacional: Maximizar a Produtividade Objetivo Medio Questo Medio Nome Mtrica Descrio Mtrica Entidade Medida Frmula Unidade Medida de de Medir a produtividade da equipe da Fbrica de Software.

de Qual a produtividade mdia da equipe da Fbrica de Software em projetos de desenvolvimento? da Produtividade. da Medir a mdia da produtividade da Fbrica de Software. ( ) Processo ( ) Projeto (x)Pessoas ( ) Produto ( ) Outros Produtividade da FSW = Produtividade do Projeto / Qtde de Projetos. Onde: FSW = Fbrica de Software. H/PF WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. Localizao: Fonte https://svn.avansys.com.br/<cliente.projeto>/modulo/Docum entacao/trunk/Medio e Anlise. OBS: Levar em considerao a ltima verso existente. Periodicidade Trimestral. Responsvel Gerente da Fbrica de Software. WP-MA-02 - Relatrio de Resultados de Medio e Anlise Armazenament da Fbrica de Software. Localizao: o https://svn.avansys.com.br/gsi.docs/processos/Medicao_An alise_FSW Projetos desenvolvidos com as mesmas tecnologias Sincronismo (linguagem de programao). Produzir em mdia um ponto de funo em no mximo 4 Meta horas de trabalho. > 4H/PF identificar causas e gerar Plano de Ao para os Aes prximos projetos. Periodicidade Trimestral. Responsvel Gerente da Fbrica de Software. Armazenament WP-MA-02 - Relatrio de Resultados de Medio e Anlise o da Fbrica de Software. Localizao:

Coleta

Anlise

https://svn.avansys.com.br/gsi.docs/processos/Medicao_An alise_FSW. Comunicao e Periodicidade Reporte Apresentao Trimestral.

WP-MA-02 - Relatrio de Resultados de Medio e Anlise da Fbrica de Software, aba Produtividade. Forma Reunio. Stakeholder(s) Gerente da Fbrica de Software e Gerente de Sistemas. WP-05 Memria de Reunio com o Gerente de Sistemas Sada e WP-MA-06 Base Histrica. Verificao Integridade de Periodicidade Trimestral.

Stakeholder(s) PPQA. Como o Relatrio de Resultado de Medio e Anlise do Projeto (WP-MA-05) j possui as frmulas de clculo da produtividade da equipe, para garantir a integridade das informaes, deve-se verificar se os dados informados na Critrio planilha esto corretos, ou seja, verificar no local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento. Para garantir que os dados das horas trabalhadas por atividade esto sendo alimentados pela equipe, os lderes verificam as horas registradas pelos profissionais atravs do Relatrio Horas Trabalhadas que fica no CaMMIla. Para o clculo da produtividade, o Gerente da Fbrica coleta, via CaMMIla, as horas efetivamente utilizadas com a execuo das atividades do Projeto Objetivo Organizacional: Minimizar o Retrabalho Objetivo de Medio Questo de Medio Nome da Mtrica Descrio da Mtrica Entidade Medida Frmula Unidade de Medida Medir o percentual de retrabalho da equipe da Fbrica de Software. Qual o percentual de esforo em retrabalho em relao ao esforo dos projetos de desenvolvimento finalizados na Fbrica de Software? Percentual de Retrabalho da Fbrica de Software. Medir o esforo gasto em retrabalho na Fbrica de Software. ( ) Processo ( ) Projeto (x)Pessoas ( ) Produto ( ) Outros Produtividade da FSW = Percentual em Retrabalho / Qtde de Projetos Finalizados. Onde: FSW = Fbrica de Software. % 1) Percentual em retrabalho - Relatrio de Resultados de Medio e Anlise do Projeto (WP-MA-05). Localizao: Fonte https://svn.avansys.com.br/<cliente.projeto>/modulo/Docume ntacao/trunk/Medio e Anlise. OBS: Levar em considerao a ltima verso existente. Periodicidade Trimestral Responsvel Gerente do Projeto. WP-MA-02 - Relatrio de Resultados de Medio e Anlise da Fbrica de Software. Localizao: Armazenamento https://svn.avansys.com.br/gsi.docs/processos/Medicao_Anali se_FSW. Projetos desenvolvidos com as mesmas tecnologias Sincronismo (linguagem de programao). Fazer com que a mdia do percentual de retrabalho dos Meta projetos da Fbrica de Software no ultrapasse o valor de 10%. > 10% Identificar causas e gerar plano de ao para os Aes prximos projetos. Periodicidade Trimestral.

Coleta

Anlise

Responsvel Armazenamento Comunicao Reporte e

Gerente da Fbrica de Software. WP-MA-02 - Relatrio de Resultados de Medio e Anlise da Fbrica de Software. Localizao: https://svn.avansys.com.br/gsi.docs/processos/Medicao_Anali se_FSW. Trimestral. WP-MA-02 - Relatrio de Resultados de Medio e Anlise da Fbrica de Software, aba Retrabalho. Reunio Gerente da Fbrica de Software e Gerente de Sistemas. WP-05 Memria de Reunio com o Gerente de Sistemas e WP-MA-06 Base Histrica. Trimestral. PPQA. Como o Relatrio de Resultado de Medio e Anlise do Projeto (WP-MA-05) j possui as frmulas de % de retrabalho da fbrica, para garantir a integridade das informaes, deve-se verificar se os dados informados na planilha esto corretos, ou seja, verificar no local especificado como fonte, se o valor o mesmo informado na planilha. Alm disso verificar se as frmulas da planilha esto corretas, de acordo com a frmula indicada nesse documento.

Periodicidade Apresentao Forma Stakeholder(s) Sada

Verificao Integridade

de

Periodicidade Stakeholder(s)

Critrio

OBS: Vale ressaltar que Retrabalho qualquer atividade de correo, modificao ou melhoria realizada sobre um artefato que j foi finalizado. Assim, no considerado retrabalho, por exemplo, os problemas encontrados por um programador durante o desenvolvimento de um mdulo ou funo, pois este ainda no foi validado e considerado finalizado. Assim, esforo em retrabalho o somatrio do nmero de horas empregadas em retrabalho por cada membro da equipe durante todo o projeto. Para subsidiar o clculo do retrabalho, durante o registro de execuo de uma tarefa no CaMMIla, o profissional informa ao sistema caso a mesma seja considerada retrabalho, marcando o campo especificado na tarefa que lhe foi aberta. Com base nesta informao e no total de esforo gasto no projeto, o CaMMIla apresenta o esforo em retrabalho para o projeto como todo. Para visualizar esta informao, o Gerente do Projeto acessa os relatrios do CaMMIla. Objetivo Organizacional: Controlar a Qualidade da Fbrica de Software Objetivo de Medir o percentual de aderncia da Fbrica de Software. Medio Questo de Qual o percentual de aderncia da Fbrica de Software? Medio Nome da Percentual de Aderncia da Fbrica de Software. Mtrica Descrio Medir o percentual de aderncia da fbrica de software atravs das auditorias da Mtrica internas realizadas nos projetos pelo PPQA. Entidade (x) Processo (x) Projeto ( )Pessoas ( ) Produto ( ) Outros Medida Grau de Aderncia = Somatrio dos Graus de Aderncia dos Projetos/Nmero Frmula de Projetos Unidade de % Medida WP-PPQA-02 Checklist para Auditoria de Aderncia e Coleta Fonte Adequao ao Processo. Localizao: https://svn.avansys.com.br/<nucleo.cliente.projeto>/trunk/00-

Periodicidade Responsvel Armazenament o Sincronismo Anlise Meta

Aes Periodicidade Responsvel Armazenament o Comunica o e Reporte Periodicidade - GSI Apresentao Forma Stakeholder(s) Sada Verificao de Periodicidade Integridade Stakeholder(s) Critrio

documentacao/Garantia da Qualidade/WP-PPQA-02 - Checklist para Auditoria de Aderncia e Adequao ao Processo. Mensal. SEPG WP-MA-06 - % Aderencia da Fbrica de Software. Localizao: https://svn.avansys.com.br/gsi.docs/processos/medicao_analise _fsw. No se aplica. Manter a aderncia por projeto sempre > = 90% e alm disso verificar qual a variao das ltimas duas auditorias em relao a atual. < 90% de aderncia em um projeto ou variao maior que 5%, recomenda-se avaliar para identificar se o problema no projeto especfico ou de adaptao do processo. Caso seja necessrio, um Plano de Ao deve ser gerado. Mensal. PPQA WP-MA-06 - % Aderencia da Fbrica de Software. Localizao: https://svn.avansys.com.br/gsi.docs/processos/medicao_analise _fsw. Mensal. WP-MA-06 - % Aderencia da Fbrica de Software. Reunio PPQA e Gerente de Sistemas WP-05 Memria de Reunio com o Gerente de Sistemas. 1. Mensalmente nas auditorias independentes de PPQA. PPQA Externo. Verificar se todos os projetos em andamento na fbrica de software esto listados na planilha, e se os somatrios de projetos e do grau de aderncia esto corretos.

5.2 Monitorao e Controle do Processo A Monitorao e Controle da PA de Medio e Anlise realizada: y 1) % de Desvios por PA

O PPQA, durante as suas avaliaes, utiliza o Checklist para Auditoria de Aderncia e Adequao a Processo e registra no mesmo os desvios identificados. As informaes dos desvios identificados para os projetos servem para atualizar o Relatrio de Acompanhamento. Durante a Reunio com a Gerncia de Sistemas de Informao, o PPQA reporta todas as questes relevantes identificadas durante a sua avaliao, inclusive o percentual de desvios identificados por PA. Nesta reunio so registradas, inclusive, as anlises a respeito dos percentuais. y 2) Alm disso, existe o trabalho de melhoria de processos realizado pelo SEPG.

Antes da sua reunio mensal do SEPG, a Coordenao do SEPG solicita que o Gerente do Projeto e o PPQA enviem por e-mail as informaes das mtricas 1 e 2 acima mencionadas, com o intuito de consolid-las. As informaes relativas s no-conformidades da PA de PPQA so levadas em considerao nesta consolidao feita pelo SEPG. Durante essa reunio, as informaes e anlises tratadas em conjunto so registradas. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado com a anlise das mtricas. Caso sugestes / oportunidades de melhorias sejam identificadas, a equipe do projeto cadastra as mesmas no CaMMIla para anlise do SEPG. 5.3 Comunicao do Status dos Processos

Mensalmente, o Gerente da Fbrica de Software reporta todos os assuntos relevantes detectados em cada projeto ao Gerente de Sistemas, em reunio, da qual gerada a Memria de Reunio com o Gerente de Sistemas (WP-05), contendo os indicadores, anlise dos mesmos e os planos de ao abertos para resoluo de questes identificadas durante a reunio. Caso necessrio, um Plano de Ao (WP-PMC-03) gerado para solucionar algum problema detectado durante o andamento dos Projetos.

PRO_PMC Processo de Monitorao e Controle do Projeto Reviso: 9 Aprovao: Daniella Gobira

1. Poltica Organizacional Monitorar o projeto com base no Plano do Projeto, comparando o planejado e o realizado. Caso sejam identificadas discrepncias reais ou potenciais, implantar aes corretivas e gerenci-las at a sua concluso. Alm disso, registrar e comunicar a situao do projeto, garantindo o desempenho adequado do mesmo. 2. Planejamento do Processo 2.1 Definio do Processo O objetivo do Processo de Monitorao e Controle acompanhar o andamento do projeto e adotar aes corretivas, quando necessrio, de forma que a execuo do projeto no se desvie significativamente do que foi planejado. Macro-atividade 1: Planejamento do Processo de Monitorao e Controle do Projeto Objetivo: Planejar o processo de Monitorao e Controle do Projeto, seguindo o estabelecido neste documento, mas especificando os marcos e pontos de controle no processo do projeto, como ocorrero as monitoraes e quem sero os participantes. Reunies informais para monitorao no precisam ter sido previstas nem planejadas, mas devem estar documentadas. y y Responsvel: Gerente do Projeto. Artefato: Plano de Monitorao e Controle e Plano do Projeto.

Macro-atividade 2: Monitorao do Projeto Objetivo: Acompanhar o progresso e o desempenho real do projeto, podendo ser executada de forma planejada ou informal. Caso haja um desvio significativo do Plano do Projeto, dar incio ao procedimento para aes corretivas. Atividade: Monitorar Andamento do Projeto (Real X Planejado) y Descrio: Quando executada de forma planejada, nos marcos ou pontos de controle, esta atividade consiste em acompanhar o progresso e o desempenho reais do projeto, comparando-os com o progresso e desempenho previstos no Plano do Projeto. Isto implica em monitorar as estimativas de custos, cronograma, os comprometimentos, os riscos, a gerncia de dados, o envolvimento dos stakeholders relevantes e os recursos humanos. Quando executada informalmente, em qualquer momento que o Gerente do Projeto julgue oportuno, esta atividade consiste na realizao de uma monitorao fora dos pontos pr-determinados no Plano. Caso necessrio reunio pode ser realizada, cujos resultados e decises so documentados. Responsvel: Gerente do Projeto. Participantes: Stakeholders. Artefato: Registro de Monitorao do Projeto (WP-PMC-01) - que a monitorao formal - ou Tarefa de reunio com a equipe no CaMMIla - que a monitorao informal, memria de reunio.

y y y

Atividade: Elaborar Planos de Ao

y y

Descrio: Elaborar planos de aes corretivas quando o desempenho ou os resultados do projeto desviem significativamente do planejado no Plano do Projeto. Aes corretivas podem estabelecer a necessidade de atualizao do Plano do Projeto. Responsvel: Gerente do Projeto. Artefatos: Planos de Ao (WP-PMC-03).

Atividade: Executar Planos de Ao y y y y Descrio: Os Planos de Ao elaborados so executados pelos responsveis. Responsveis: Stakeholders designados para executar os Planos de Ao Participantes: Stakeholders. Artefatos: Planos de Ao Executados, Plano do Projeto Atualizado (quando necessrio).

Atividade: Gerenciar Planos de Ao y Descrio: Garantir que as devidas aes corretivas sejam executadas, o que significa acompanhar a execuo das mesmas pelos respectivos responsveis, apontando na concluso dos planos de ao a sua efetividade e a necessidade de novas aes corretivas. Responsvel: Gerente do Projeto. Artefatos: Controle de Planos de Ao (WP-PMC-04) no CaMMIla.

y y

Atividade: Registrar Comprometimento com o Plano do Projeto y y y y Descrio: Caso necessrio, obter, dos participantes envolvidos, comprometimento com o Plano do Projeto. Responsvel: Gerente do Projeto. Participantes: Stakeholders. Artefatos: Registro de Comprometimento com o Plano do Projeto (WP-02).

Atividade: Registrar Situao do Projeto y Descrio: A situao do projeto registrada e disponibilizada para os stakeholders internos e do cliente. Quando necessrio, o Plano do Projeto refinado para a prxima macro-atividade. Responsvel: Gerente do Projeto. Artefatos: Registro de Milestone (E-mail de Milestone ou Memria de Reunio de Milestone), Plano do Projeto Refinado.

y y

3. Recursos Para executar este processo so necessrios: y y Pessoal treinado conforme o item 5. Ferramentas: MS-Word, MS-Excel, MS-Project, SVN (Subversion), CaMMIla (Gerenciador de Projetos de Sistema), AvanDOC (ferramenta de gerenciamento de arquivos), AvanEAD (ferramenta de ensino distncia).

4. Responsabilidade As responsabilidades por cada atividade do processo esto identificadas no item 2.1 deste documento (Definio do Processo). 5. Treinamento Para execuo deste processo os profissionais envolvidos em suas atividades so treinados em: y Gerente da Fbrica de Software: o Introduo ao CMMI; o PRO_PMC Processo de Monitorao e Controle;

o o y

IT-PRO-14 Monitorao e Controle do Projeto; Ferramentas: CaMMIla (Viso de Monitorao e Controle de Projetos).

Gerente do Projeto: o Introduo ao CMMI; o PRO_PMC Processo de Monitorao e Controle; o IT-PRO-14 Monitorao e Controle do Projeto; o Ferramentas: CaMMIla (Viso de Monitorao e Controle de Projetos). Analista de Sistemas, Desenvolvedor, Homologador e Documentador: o Introduo ao CMMI; o PRO_PMC Processo de Monitorao e Controle; o IT-PRO-14 Monitorao e Controle do Projeto. Grupo de Garantia da Qualidade do Produto e do Processo (PPQA): o Introduo ao CMMI; o PRO_PMC Processo de Monitorao e Controle; o IT-PRO-14 Monitorao e Controle do Projeto. o Ferramentas: CaMMIla (Viso de Monitorao e Controle de Projetos).

6. Stakeholders Relevantes Os stakeholders relevantes para a execuo do processo esto identificados no item 2.1 (Definio do Processo). 7. Monitorao e Controle do Processo A monitorao e controle do processo so realizados atravs de: y y Mtricas de monitorao do processo definidas no documento de Medio e Anlise (IT-PRO-13). Avaliao do Gerente do Projeto

O Gerente do Projeto avalia a adequao do processo durante a execuo do projeto. O SEPG avalia a viabilidade das sugestes / oportunidades de melhoria detectadas no decorrer de um projeto. y Avaliao de Encerramento do Projeto

A equipe da Fbrica de Software envolvida no projeto, conduzida pelo Gerente do Projeto, avalia o processo ao final da ltima macro-atividade, preenchendo um questionrio. Essas informaes so sintetizadas pelo Gerente do Projeto e transmitidas aos Stakeholders relevantes atravs de e-mail ou Reunio de Encerramento de Projeto. 8. Avaliao Objetiva da Aderncia ao Processo A aderncia aos processos avaliada pelo PPQA, periodicamente, conforme definido no documento de Garantia da Qualidade do Produto e do Processo (IT-PRO-6), quando avaliada a aderncia a todos os processos, utilizando checklists pr-definidos. As atividades realizadas pelo PPQA so avaliadas por auditores externos ao PPQA para se garantir a objetividade necessria, tambm utilizando checklists. 9. Reviso do Status do Processo com a Gerncia Snior Periodicamente, conforme definido no documento Garantia da Qualidade do Produto e do Processo (IT-PRO-6), os dados obtidos das avaliaes com relao aderncia e adequao do processo, nos diversos projetos, so sintetizados pelo PPQA de forma a evidenciar: y y y y Aderncia ao processo na organizao; Desvios observados no perodo; Inadequaes do processo relatadas no perodo; Aes implementadas para cada desvio;

Aes implementadas para cada inadequao.

Durante as reunies do PPQA e do Gerente de Projetos com o Gerente de Sistemas de Informao, os assuntos que forem pertinentes so tratados durante reunio presencial que ocorre mensalmente, e registradas na Memria de Reunio com o Gerente de Sistema de Informao (WP-05).

IT-PRO-14 - Monitorao e Controle Reviso: 9 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para atender ao Processo de Monitorao e Controle (PRO_PMC). 2. Executante da Tarefa Gerente do Projeto. 3. Documentos Complementares y y y y y y y PRO_PD Processo de Desenvolvimento; PRO_PMC Processo de Monitorao e Controle do Projeto; PRO_PP Processo de Planejamento do Projeto; IT-PRO-11 Planejamento do Projeto; IT-PRO-13 Medio e Anlise; LISTA-FBRICA DE SOFTWARE Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

4. Recursos Necessrios y CaMMIla Gerenciador de Projetos de Sistema.

5. Atividades Principais Descrever como so realizados a monitorao e controle das estimativas de esforo e custo, do cronograma, dos comprometimentos, dos riscos e da gerncia de dados. Os itens so planejados e monitorados atravs da ferramenta GPS. O GPS possui um mdulo de Monitorao e Controle de Projetos que respalda as atividades de acompanhamento do progresso do projeto, ajuda a identificar possveis desvios significativos e suas respectivas aes corretivas, garantindo o desempenho adequado do projeto. 5.1 Planejamento das Atividades de Monitorao e Controle Durante o Planejamento do Projeto, o Gerente do Projeto planeja suas atividades de monitorao com base no Plano do Projeto (WP-PP-01) e coloca as informaes relativas s execues das monitoraes no Cronograma do Projeto (WP-PP-03). Gerando assim o Plano de Monitorao e Controle do Projeto (WP-PMC-04). A periodicidade da monitorao deve ser pelo menos quinzenal. A Monitorao e Controle do Projeto formal so realizados conforme Plano de Monitorao e Controle, no Cronograma do Projeto. Alm disso, podem ocorrer monitoraes eventuais, quando: y y O Gerente do Projeto detectar a necessidade de monitorar o projeto fora da data prevista no seu plano; O Gerente da Fbrica de Software ou o Gerente de Sistemas solicitar ao Gerente do Projeto uma monitorao adicional no projeto.

5.1.1 Visualizar o Plano de Monitorao e Controle

Para visualizar o Plano de Monitorao e Controle no GPS, o Gerente do Projeto, acessa o projeto desejado, clica na Guia Projeto: <Nome do Projeto>, na PA Monitorao, na opo Plano de Monitorao e Controle. 5.2 Monitorar Andamento do Projeto (Real x Planejado) Ao longo da evoluo do Projeto, o Gerente do Projeto monitora e registra o desempenho real do projeto, comparando-o com o desempenho previsto no Plano do Projeto. No caso especfico da Gerncia de Dados, a monitorao feita por um conjunto de atividades desempenhadas pelo Gerente do Projeto e pelo Gerente de Configurao. Os seguintes parmetros so monitorados e registrados para controle: 1. Esforo Atravs do sistema de custo e da aba Tarefas do GPS o Gerente de Projeto acompanha e controla o esforo conforme descrito no documento de Medio e Anlise (IT-PRO-13). Essa informao armazenada no WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. 2. Cronograma Atravs da monitorao do percentual gasto nas tarefas possvel que o Gerente do Projeto tenha controle dos prazos e possa monitorar o Cronograma do Projeto. O procedimento est descrito no documento de Medio e Anlise (IT-PRO13). O registro dessa informao feito no WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. 3. Custo O Custo do projeto medido pelo percentual de utilizao do profissional alocado no projeto at o momento da monitorao, multiplicado pelo custo do profissional (valor obtido no incio do projeto pela Diretoria Executiva), conforme procedimento descrito no documento de Medio e Anlise (IT-PRO-13).O registro do resultado da monitorao, feito no WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. 4. Comprometimento o Gerente do Projeto monitora se os comprometimentos internos e externos que eram para ser obtidos at a presente data encontram-se em perfeita ordem com o estabelecido no Processo de Desenvolvimento (PRO_PD) e se h necessidade de planejar novos comprometimentos. Caso haja necessidade, um Plano de Ao pode ser criado para tratar os problemas detectados com a ausncia de comprometimentos. Essas informaes so registradas no WP-PMC-01 - Registro de Monitorao do Projeto localizado em: http://gps.avansys.com.br / Projeto <nome do projeto> / Monitorao / Registro de Monitorao/Comprometimento; 5. Riscos o Gerente do Projeto analisa a cada monitorao se houve mudana na probabilidade dos riscos em relao a monitorao anterior, verifica se o impacto continua o mesmo e analisa se outros riscos surgiram. Para os casos de ocorrncia dos riscos identificados no Plano do Projeto, o Gerente do Projeto analisa as aes de contingncia especificadas e gera um Plano de Ao. No surgimento de novos riscos no identificados anteriormente ou aumento de probabilidade e/ou impacto dos riscos j identificados, o Gerente do Projeto atualiza o Plano de Risco dentro do Plano do Projeto e se necessrio gera um Plano de Ao para tratar o risco. As informaes de monitorao so registradas no WP-PMC-01 - Registro de Monitorao do Projeto localizado em: http://gps.avansys.com.br / Projeto <nome do projeto> / Monitorao / Registro de Monitorao/Riscos 6. Gerncia de Dados Esse tpico monitorado pela integrao de duas atividades: o Durante as atividades de Monitorao e Controle do Projeto, o Gerente do Projeto registra no GPS alteraes na equipe do projeto ou na nomenclatura / armazenamento de artefatos que implique na gerncia de dados e notifica o Gerente de Configurao. O Gerente do Projeto verifica se a nomenclatura dos arquivos armazenados est condizente com o nome dos artefatos. O registro da alterao do artefato feito no repositrio do Projeto - SVN, incluindo novas verses e o registro de alteraes da equipe feito na aba Equipe excluindo ou adicionando pessoas. Caso seja necessrio a criao ou recebimento de um novo artefato no definido no Processo de Desenvolvimento padro da Avansys, o mesmo criado ou obtido e armazenado conforme planejado na lista de artefatos do prprio projeto. Durante o PMC, o gerente de projetos acompanha a criao ou recebimento desses novos artefatos conforme o previsto na Gerncia de Dados. o O Gerente de Configurao realiza a segunda atividade que seria verificar, durante as auditorias das baselines (Registro de Auditoria de Baselines (WPCM-02)), se o perfil de acesso dos profissionais est condizente com a realidade / necessidade do projeto e se os artefatos que deveriam estar na baseline esto no local prprio de armazenamento. Caso haja necessidade,

um Plano de Ao pode ser aberto pelo Gerente do Projeto para tratar as questes e problemas detectados com a Gerncia de Dados, durante a Monitorao dos Projetos ou pelo Gerente de Configurao durante a execuo das auditorias de baselines. Essas informaes so registradas no WP-PMC-01 - Registro de Monitorao do Projeto localizado em: http://gps.avansys.com.br / Projeto <nome do projeto> / Monitorao / Registro de Monitorao/Gerncia de Dados. 1. Outros Nesta aba do WP-PMC-01 - Registro de Monitorao do Projeto, o Gerente do Projeto, monitora os treinamentos e os recursos em geral. Ocorre o acompanhamento da execuo dos treinamentos identificados no Planejamento do Projeto e a necessidade de novos treinamentos para o projeto, o mesmo pensamento levado em considerao para os recursos gerais do projeto. Caso haja necessidade um Plano de Ao aberto no GPS para tratar a ausncia da execuo de algum treinamento ou a inexistncia de algum recurso planejado no planejamento do projeto. 2. Envolvimento dos Stakeholders - O acompanhamento do envolvimento dos stakeholders do projeto disponibilizado no e-mail de milestone. Caso haja necessidade um Plano de Ao aberto no GPS para tratar questes relativas ao envolvimento dos Stakeholders nas atividades do projeto, conforme o planejado na coluna Atividades da Estrutura Organizacional e Plano de RH, no Plano do Projeto. OBS1: O comprometimento do cliente com os documentos pertinentes, descritos no processo de desenvolvimento, pode ser obtido: y y y y y Atravs do envio de e-mail; Aprovao direta do documento via GPS; Registro de Comprometimento (WP-02) devidamente impresso e assinado; Documento em questo impresso e assinado; Memria de Reunio aprovada no GPS.

Os parmetros de esforo, cronograma, custo, comprometimentos, riscos, treinamentos, recursos e envolvimento dos stakeholders so monitorados nos pontos de controle estabelecidos no Cronograma do Projeto, enquanto que o parmetro de Gerncia de Dados monitorado tambm nas auditorias realizadas nas baselines. Todos os pontos de controle planejados e monitorados so devidamente registrados no Registro de Monitorao do Projeto, localizado no GPS, na Guia Projeto: <Nome do Projeto>, na PA Monitorao, na opo Registro de Monitorao. As monitoraes podem ser realizadas de maneira formal ou informal. Todas as verificaes formais so registradas no Registro de Monitorao do Projeto, localizado no GPS, na Guia Projeto: <Nome do Projeto>, na PA Monitorao, na opo Registro de Monitorao, e no WP-MA-05 - Relatrio de Resultados de Medio e Anlise do Projeto. As monitoraes informais so registradas na prpria tarefa aberta no GPS pelo Gerente do Projeto. Caso o Gerente do Projeto identifique, durante as monitoraes informais, a ocorrncia de impacto nos parmetros de projeto contidos no Plano do Projeto, as informaes relevantes so documentadas no Registro de Monitorao do Projeto. Durante a realizao das monitoraes e controle do projeto, o Gerente do Projeto rev o progresso do projeto, sua performance e questes/problemas relativos ao mesmo. Periodicamente o GP dever avaliar o indicador de desvio de prazo, esforo e custo, conforme especificado na IT-PRO-13 Medio e Anlise. Para todo desvio identificado como significativo, um plano de ao deve ser criado e acompanhado at seu fechamento. Para que esse controle seja possvel, toda a equipe do projeto lana horas diariamente e registra o progresso das atividades no GPS durante a execuo da mesma. Para isso, basta editar a tarefa em questo e preencher o campo Tempo de Execuo, registrando as horas gastas por dia com o detalhamento do que foi feito. Alm disso, o campo Feito sempre atualizado com o lanamento das horas informando o andamento da tarefa em porcentagem. Para esse registro a equipe segue o raciocnio abaixo: 0% - Atividade No Iniciada

20% - Atividade Iniciada 40% - Atividade Parcialmente Executada 60% - Parte Significativa Executada 80% - Atividade Concluda, item em Validao 100% - Atividade Concluda Obs: Esse critrio no vlido para a atividade de Gerenciar Baseline, considerando que uma atividade que ficar aberta at o final do projeto. Sendo assim, deve ser preenchido da seguinte forma: 0% - Atividade No Iniciada 40% - Atividade na fase de Anlise dos Requisitos e Projeto Tcnico do Software 60% - Atividade na fase de Codificao e Testes de Unidade 80% - Atividade na fase de Integrao e Teste de Qualificao do Software 100% - Ao final na fase de Integrao e Implantao do Sistema 5.3 Criao, Execuo e Gerenciamento dos Planos de Aes Corretivas Os registros obtidos so avaliados e comparados com o planejado. Caso o desempenho ou os resultados dos parmetros descritos no item 5.2. se desviem do Plano do Projeto, o Gerente do Projeto elabora um Plano de Ao, designa o respectivo responsvel pela soluo e gerencia a concluso do mesmo, sua efetividade e a necessidade de novos planos de ao. No GPS, existem duas formas de criar um Plano de Ao: 1) Na Guia Projeto: <Nome do Projeto>, na PA de Monitorao, na opo Registro de Monitorao, as guias de comprometimento, risco e gerncia de dados so visualizadas. Caso existam alguns desses registros de monitorao com o status em desvio, o Gerente do Projeto clica na linha com essa identificao e o sistema direciona para que um Plano de Ao possa ser criado. O sistema exibe uma listagem com os desvios detectados no registro de monitorao e permite que o Gerente do Projeto adicione um Plano de Ao para resolver o desvio assinalado na tela anterior, informando: nome do plano de ao, responsvel, status do plano de ao e os participantes na soluo do desvio detectado. Ao clicar em Salvar, o Plano de Ao entra na listagem dos Planos de Ao no GPS, na Guia Projeto: <Nome do Projeto>, no item Plano de Ao. O Gerente do Projeto pode acompanhar o andamento do desvio e, aps edit-lo, cadastrar na guia Aes, todas as aes corretivas que forem necessrias para a soluo do problema. Desta forma so criados planos de ao especficos para resolver problemas de desvios detectados durante a atividade de monitorao e controle do projeto. 2) Na Guia Projeto: <Nome do Projeto>, na opo Plano de Ao. Para as duas maneiras de criar o Plano de Ao, os seguintes campos so preenchidos: y Detalhes o Nome nome que ser dado ao Plano de Ao em questo; o Responsvel profissional responsvel pela concluso do Plano de Ao; o Status situao do Plano de Ao, podendo ser Concludo e Efetivo, Concludo e No-efetivo, Em andamento ou No iniciado;

Equipe o Escolher dentre a lista disponibilizada as pessoas responsveis pela soluo do problema identificado no Plano de Ao.

Vale lembrar que um Plano de Ao aberto para resolver um problema especfico, este problema pode estar associado necessidade de tomar uma ou vrias aes corretivas e o Plano de Ao pode ser aberto em funo de: y y y y y y y Auditoria realizada nas Baselines; Avaliaes realizadas em artefatos (peer-review); Monitorao e Controle de Projetos; Avaliao realizada pelo PPQA; Reunio entre GSI e Gerente do Projeto; Reunio entre GSI e PPQA; Reunio entre GSI e SEPG.

Portanto, aps a incluso das informaes acima mencionadas, o responsvel pelo cadastramento do Plano de Ao clica em Salvar. Aps esse cadastramento inicial, outra aba aparece para o Plano de Ao cadastrado, permitindo que as aes necessrias para a soluo do problema detectado sejam cadastradas, preenchendo: y y y y y y y Nome nome da ao a ser tomada para resolver o problema identificado; Status situao da ao, podendo ser: No iniciada, Em andamento ou Concluda. Responsvel: profissional responsvel pela ao; Data inicial data em que a ao corretiva ser iniciada; Data final data de previso para que a ao corretiva ser finalizada; Data concludo data em que a ao corretiva foi efetivamente concluda; Descrio breve descrio da ao corretiva.

Aps a incluso das informaes acima mencionadas, o responsvel pelo cadastramento do Plano de Ao clica em Salvar. Desta forma outra ao corretiva pode ser cadastrada para o mesmo problema. Sempre que um Plano de Ao detectado pela Monitorao e Controle aberto no GPS, o mesmo acompanhado pelo Gerente do Projeto at o seu fechamento. Aps a concluso do Plano de Ao, o Gerente do Projeto atualiza o registro, informando a efetividade do Plano. Caso o mesmo no tenha sido efetivo, um novo Plano de Ao criado e o campo do nome do documento preenchido, conforme padro abaixo: - Nome do Plano de Ao (X), onde X o identificador atribudo pela ferramenta ao Plano de Ao anterior que foi fechado como concludo e no-efetivo. 5.4 Registrar Comprometimento com o Plano do Projeto Quando uma ao corretiva implicar em redimensionamento dos parmetros planejados, o Plano do Projeto atualizado e os envolvidos no processo (PPQA, Gerente de Requisitos e Gerente de Configurao) so notificados via email pelo Gerente do Projeto. Sempre que o Plano do Projeto atualizado e a essa alterao envolver mudana no plano do processo a ser seguido ou alteraes no cronograma definido que envolva a participao do cliente, o Gerente do Projeto solicita um novo comprometimento dos stakeholders com o Plano do Projeto viso cliente (WP-PP-01.1).

5.5 Situao do Projeto "Milestone" De posse das informaes inerentes a cada projeto e da situao dos mesmos, o Gerente do Projeto, conforme programado na fase de Planejamento do Projeto no Cronograma do Projeto (WP-PP-03), envia um e-mail para os stakeholders relevantes conforme indicado abaixo.

1. Para a Gerncia de Sistema de Informao, Gerente da Fbrica de Software e Profissionais Responsveis pelo Negcio: o Comprometimentos at o milestone; o Situao dos riscos at o milestone; o Mudanas ocorridas no Planejamento/Impactos; o Questes/Problemas relevantes; o Planos de Ao at o milestone; o Custo (planejado X realizado); o Realizao dos Treinamentos previstos no Plano do Projeto; o Envolvimento dos Stakeholders at o milestone. o Retrabalho (no Encerramento do Projeto); o Produtividade (no Encerramento do Projeto); 1. Para a Equipe da Fbrica de Software: o Comprometimentos at o milestone; o Situao dos riscos at o milestone; o Mudanas ocorridas no Planejamento/Impactos; o Questes/Problemas relevantes; o Planos de Ao at o milestone; o Retrabalho (no Encerramento do Projeto); o Produtividade (no Encerramento do Projeto). 1. Para que o Cliente tome conhecimento quanto ao andamento do projeto, o Gerente do Projeto envia um e-mail e em seguida entra em contato com o mesmo por telefone para esclarecer possveis dvidas e garantir o recebimento do mesmo. Em todos os casos o Gerente do Projeto realiza uma anlise, mostrando a sua viso e dificuldades encontradas durante a fase finalizada. Caso algum profissional da equipe tenha questionamentos ou consideraes sobre as informaes passadas nos milestones, o mesmo deve enviar um email e caso a dvida ou problema no seja sanado uma reunio ser marcada. OBS: A atividade de Realizar Encerramento do Projeto considerada a ltima atividade do projeto com o objetivo de disponibilizar informao final sobre os parmetros do projeto, sendo considerada o ltimo milestone. Nessa atividade, o Gerente do Projeto pode apresentar o indicador real de Retrabalho e a Produtividade do projeto em questo. 5.6 Monitorao e Controle do Processo A monitorao e controle do processo de Monitorao e Controle do Projeto realizada: 1. % de Desvios por PA - O PPQA, durante as suas avaliaes, utiliza o Checklist para Auditoria de Aderncia e Adequao a processos e registra no mesmo os desvios identificados. As informaes dos desvios identificados para os projetos servem para atualizar o Relatrio de Acompanhamento. Durante a Reunio com a Gerncia de Sistema de Informao, o PPQA reporta todas as questes relevantes identificadas durante a sua avaliao, inclusive o percentual de desvios identificados por PA. Nesta reunio so registradas, inclusive, as anlises a respeito dos percentuais. O Gerente de Projetos participa desta reunio. 2. Alm disso, existe o trabalho de melhoria de processos realizado pelo SEPG. Antes da sua reunio mensal do SEPG, a Coordenao do SEPG solicita que o o PPQA envie por e-mail as informaes da mtrica acima mencionada, com o intuito de consolid-las. As informaes relativas s no-conformidades da PA de PPQA so levadas em considerao nesta consolidao feita pelo SEPG. Durante essa reunio, as informaes e anlises tratadas em conjunto so registradas. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado com a anlise das mtricas. Caso sugestes / oportunidades de melhorias sejam identificadas, a equipe do projeto cadastra as mesmas no GPS para anlise do SEPG. 5.7 Comunicao do Status dos Projetos Semanalmente o Gerente do Projeto elabora o scorecard para reportar o andamento do projeto ao Escritrio de Projetos (PMO). Nele o GP informa o acompanhamento do cronograma,

escopo e recursos do projeto, principais atividades realizadas no perodo e programadas para o prximo perodo, anlise feita dos riscos e questes relevantes, alm dos milestones prximos do vencimento ou vencidos, informando para cada um a data alvo, data revisado (se houver), data atual e status (iniciado ou no iniciado). Caso o status geral do projeto esteja classificado como vermelho ou amarelo, uma plano de ao deve ser aberto. Todas as informaes necessrias para preenchimento do scorecard so obtidas atravs da IT-PRO-13 Medio e Anlise, IT-PRO-14 Monitorao e Controle do Projeto e no Plano do Projeto (WP-PP-01). O scorecard enviado atravs de e-mail para o Escritrio de Projetos com cpia para o Gerente da Fbrica e Gerente de Sistemas. Mensalmente o Gerente do Projeto reporta todos os assuntos relevantes detectados em cada projeto ao Gerente de Sistema de Informao, em reunio formal, da qual gerada a Memria de Reunio com a Gerncia de Sistema de Informao (WP-05), contendo as informaes relevantes da anlise feita nos projetos, a situao pertinente a cada um e os planos de ao abertos para resoluo de questes identificadas durante a reunio. O Gerente de Projetos leva as informaes do Registro de Monitorao e Controle para a reunio, com um parecer prvio dos assuntos que sero tratados e registrados na Memria de Reunio com a Gerncia de Sistema de Informao, que conter a anlise conjunta dos itens abordados. Caso necessrio, um Plano de Ao (WP-PMC-03) gerado para solucionar algum problema detectado durante o andamento dos Projetos.

PRO_PPQA Processo de Garantia da Qualidade do Produto e do Processo

1. Poltica Organizacional Garantir que o processo seja seguido de acordo com os padres e procedimentos definidos pela organizao, atravs de avaliaes objetivas dos produtos e processos. Gerar desvios quando necessrio e acompanhar as suas resolues, escalonando-os quando no tratados no prazo estipulado, de forma a assegurar que o nvel gerencial apropriado resolva a questo. 2. Planejamento do Processo 2.1 Definio do Processo O objetivo do processo Garantia da Qualidade do Produto e do Processo fornecer equipe e ao Gerente de Sistemas de Informao uma viso objetiva sobre os processos e produtos do trabalho (artefatos) associados. Macro-atividade 1: Planejamento do Processo de PPQA Atividade: Gerar Plano de PPQA y y y Objetivo: Planejar o processo de Garantia de Qualidade do Produto e do Processo. Responsvel: PPQA. Artefato: Plano de PPQA e Plano de Projeto.

Atividade: Definio de Check list de Avaliao de Aderncia e Adequao aos Processos y y y Objetivo: Acessar o checklist a ser utilizado e se necessrio atualiz-lo de acordo com as necessidades do projeto. Responsvel: PPQA. Artefato: WP-PPQA-02 Checklist para Auditoria de Aderncia e Adequao a Processos, atualizado.

Macro-atividade 2: Avaliar Objetivamente os Processos Objetivo: Realizar avaliaes objetivas da aderncia e da adequao dos seguintes processos: Planejamento de Projetos, Gerncia de Requisitos, Monitorao e Controle,

Garantia da Qualidade do Produto e do Processo, Medio e Anlise e Gerncia de Configurao. Atividade: Realizar Auditoria da Aderncia aos Processos y Descrio: Realizar auditorias para avaliao objetiva da aderncia aos processos baseada em checklists. A auditoria da aderncia ao processo Garantia da Qualidade do Produto e do Processo, no que se refere s atividades est sob a responsabilidade do PPQA externo. Responsveis: PPQA, PPQA Externo. Artefatos: Checklist para Auditoria de Aderncia e Adequao a Processos (WPPPQA-02), Relatrio de Desvio (WP-PPQA-03) e Relatrio de Acompanhamento dos Projetos (WP-PPQA-04).

y y

Atividade: Identificao e Implementao de Oportunidades de Melhoria y y y Descrio: Identificar oportunidades de melhorias para os processos e avaliar sua pertinncia. Responsveis: PPQA, PPQA Externo, Equipe do Projeto, SEPG Artefatos: Oportunidades de Melhoria (WP-PPQA-06), no CaMMIla.

Atividade: Verificao de Treinamentos y y y y Descrio: Verificar ser os profissionais envolvidos no projeto esto capacitados para exercer seu papel. Responsveis: PPQA Participantes: Equipe do Projeto Artefatos: Checklist para Auditoria de Aderncia e Adequao a Processos (WPPPQA-02)

Macro-atividade 3: Avaliar Objetivamente os Produtos do Trabalho e os Servios Objetivo: Realizar avaliao nos produtos de trabalho (artefatos) identificados no Plano de Projeto de cada projeto, bem como os critrios de avaliao. As avaliaes so realizadas de acordo com o planejado. Um conjunto inicial de critrios de avaliao est definido na IT-PRO6 - Garantia da Qualidade do Produto e do Processo e no podem ser excludos da avaliao, mas outros critrios podem ser includos de forma a se garantir o alcance dos requisitos de qualidade identificados para o software. Atividade: Identificar Pontos de Controle para Garantia da Qualidade y y y Descrio: As datas em que sero realizadas atividades de avaliao dos produtos e servios so as mesmas estabelecidas no Plano de PPQA. Responsveis: PPQA. Artefatos: Plano do PPQA e Plano do Projeto.

Atividade: Realizar Avaliao dos Produtos Conforme Planejado y Descrio: Avaliar os produtos segundo os critrios pertinentes a cada um e estabelecidos no Checklist para Auditoria de Aderncia e Adequao a Processos. As avaliaes so planejadas no Plano do PPQA. Responsveis: PPQA. Artefatos: Relatrio de Desvio, Oportunidade de Melhoria (caso necessrio) e Checklist para Auditoria de Aderncia e Adequao a Processos.

y y

Macro-atividade 4: Comunicar Desvios e Garantir sua Resoluo Objetivo: Comunicar os desvios encontrados no processo aos stakeholders e garantir sua resoluo. Aps a realizao de avaliaes dos processos e anlise dos dados, o PPQA e/ou os auditores externos (quando pertinente) define(m) aes a serem implementadas para resolver os desvios ou no conformidades. O PPQA gerencia as aes corretivas garantindo a sua execuo.

Atividade: Comunicar Desvios e No-Conformidades nos Processos e Produtos e Garantir sua Resoluo y Descrio: Comunicar aos stakeholders os resultados da avaliao da aderncia aos processos e produtos, aps a sua realizao. Quando encontrado um desvio no projeto, o PPQA sugere como pode ser feita a correo, comunica o responsvel por resolv-lo e uma data para soluo do mesmo agendada. O PPQA acompanha o desvio at a resoluo do mesmo. Para garantir a resoluo de um desvio, o mesmo deve ser escalonado de acordo com os critrios definidos. Responsveis: PPQA e Auditores Externos (avaliao da aderncia do PPQA ao Processo de Garantia da Qualidade do Produto e do Processo). Participantes: Equipe do Projeto Artefatos: Checklist para Auditoria de Aderncia e Adequao a Processos, Relatrio de Desvio, Relatrio de Acompanhamento do Projeto.

y y y

Macro-atividade 5: Monitorar e Controlar os Processos Atividade: Monitorar os Processos y Descrio: A monitorao e controle dos processos realizada atravs de: 1. medidas estabelecidas para cada processo e que constam do documento de definio de cada processo; 2. avaliaes de adequao do processo realizadas durante o projeto. Responsveis: SEPG e PPQA. Participantes: Stakeholders Relevantes. Artefato: Relatrio de Resultados de Medio e Anlise do Projeto (WP-MA-05), Relatrio de Acompanhamento de Projetos (WP-PPQA-04), Memria de Reunio do SEPG (RQ-7.3AC).

y y y

Atividade: Analisar Dados y Descrio: A anlise dos dados obtidos nas atividades anteriores realizada periodicamente de acordo com o documento de Garantia da Qualidade do Produto e do Processo (IT-PRO-6). Os dados obtidos com a realizao das atividades anteriores nos diversos projetos so sintetizados, por processo, pelo PPQA de forma a evidenciar: aderncia ao processo na organizao, desvios observados no perodo, inadequaes do processo relatadas no perodo e anlise de possveis causas com aes implementadas para cada desvio. Responsveis: PPQA. Artefatos: Relatrio de Acompanhamento de Projetos.

y y

Atividade: Analisar Dados por Auditores Externos y Descrio: A anlise dos dados obtidos nas atividades anteriores, quando a avaliao realizada por avaliadores externos ao PPQA, tambm realizada de forma a se garantir a objetividade necessria. Responsveis: PPQA Externo e SEPG. Participantes: PPQA Interno. Artefatos: Relatrio de Acompanhamento das Atividades do PPQA (WP-PPQA-05).

y y y

3. Recursos Para executar este processo so necessrios: y y y y A existncia de um Grupo de Qualidade do Produto e do Processo; Pessoal treinado conforme o item 5; Auditores externos ao PPQA. Ferramentas: MS-Word, MS-Excel, SVN (Subversion), CaMMIla (Gerenciador de Projetos de Sistema), AvanDOC (ferramenta de gerenciamento de arquivos), AvanEAD (ferramenta de ensino distncia).

4. Responsabilidade

As responsabilidades por cada atividade do processo esto identificadas no item 2.1 deste documento (Definio do Processo). 5. Treinamento Para execuo deste processo os profissionais envolvidos so treinados em: y Gerente da Fbrica de Software e Gerente de Sistema de Informao: o Introduo ao CMMI; o PRO_PPQA Processo de Garantia da Qualidade do Produto e do Processo; o IT-PRO-6 Garantia da Qualidade do Produto e do Processo. Gerente de Projetos: o Introduo ao CMMI; o PRO_PPQA Processo de Garantia da Qualidade do Produto e do Processo; o IT-PRO-6 Garantia da Qualidade do Produto e do Processo. Analista de Sistemas, Desenvolvedor, Homologador e Documentador: o Introduo ao CMMI; o IT-PRO-6 Garantia da Qualidade do Produto e do Processo. Grupo de Garantia da Qualidade do Produto e do Processo (PPQA): o Introduo ao CMMI; o Treinamento de PPQA; o PRO_PPQA Processo de Garantia da Qualidade do Produto e do Processo; o PRO_PP Processo de Planejamento do Projeto; o PRO_PMC Processo de Monitorao e Controle; o PRO_CM Processo de Gerncia de Configurao; o PRO_REQM Processo de Gerncia de Requisitos; o PRO_MA Processo de Medio e Anlise. o PRO_PD Processo de Desenvolvimento. o IT-PRO-6 Garantia da Qualidade do Produto e do Processo; o IT-COM-2 Levantamento Preliminar; o IT-PRO-9 Gerncia de Configurao; o IT-PRO-10 Controle de Mudana; o IT-PRO-11 Planejamento do Projeto; o IT-PRO-12 Gerncia de Requisitos; o IT-PRO-13 Medio e Anlise; o IT-PRO-14 Monitorao e Controle do Projeto; o Ferramenta: CaMMIla (Viso do PPQA).

6. Stakeholders Relevantes Os stakeholders relevantes para a execuo do processo esto identificados no item 2.1 (Definio do Processo). 7. Monitorao e Controle do Processo A monitorao e controle deste processo so realizados atravs de: 1. Mtricas de monitorao do processo definidas no documento de Medio e Anlise (IT-PRO-13); 2. Avaliao do PPQA: O Avaliador do PPQA, com a participao do SEPG, realiza as avaliaes com o PPQA e filtra as informaes relevantes colhidas durante a avaliao, com a finalidade de subsidiar que as mesmas venham a compor a pauta da reunio mensal do SEPG. 8. Avaliao Objetiva da Aderncia ao Processo A aderncia aos processos avaliada pelo PPQA, periodicamente, conforme definido no documento de Garantia da Qualidade do Produto e do Processo (IT-PRO-6), quando avaliada a aderncia a todos os processos, utilizando checklists pr-definidos. As atividades realizadas pelo PPQA so avaliadas por auditores externos ao PPQA para se garantir a objetividade necessria, tambm utilizando checklists.

9. Reviso do Status do Processo com a Gerncia Snior A Reviso do Status do Progresso do Processo de Garantia da Qualidade do Produto e do Processo ocorre conforme descrito no item 9 do Processo de Monitorao e Controle. Alm disso, o PPQA elabora o Relatrio de Acompanhamento de Projetos (WP-PPQA-04), contendo as anlises prvias realizadas pelo PPQA que discutido com Gerente de Sistema de Informao em reunio, da qual gerada a Memria de Reunio com o Gerente de Sistema de Informao (WP-05).

IT-PRO-06 - Garantia da Qualidade do Produto e do Processo Reviso: 9 Aprovao: Daniella Gobira

1. Objetivo Descrio do procedimento para atender ao Processo da Garantia da Qualidade do Produto e do Processo (PRO_PPQA). 2. Executante da Tarefa y y y PPQA Grupo de Garantia da Qualidade do Produto e do Processo; PPQA Externo; Equipe da Fbrica de Software.

3. Documentos Complementares y y y y y y PRO_PD Processo de Desenvolvimento; PRO_PPQA Processo de Garantia da Qualidade do Produto e do Processo; IT-PRO-11 Planejamento do Projeto; IT-PRO-13 Medio e Anlise; LISTA-FSW Lista de Artefatos da Fbrica de Software; Glossrio da Qualidade de Software.

3. Recursos Necessrios CaMMIla Gerenciador de Projetos de Sistema. 5. Atividades Principais Descreve como so feitas as avaliaes de aderncia e adequao da Fbrica de Software aos processos de Planejamento do Projeto (PRO_PP), Gerncia de Requisitos (PRO_REQM), Monitorao e Controle do Projeto (PRO_PMC), Gerncia de Configurao (PRO_CM), Medio e Anlise (PRO_MA) e Processo de Desenvolvimento (PRO_PD), descrevendo tambm como o Gerente de Sistemas de Informao informado quanto eficcia dos processos. 5.1 Planejamento do Processo de PPQA No momento em que avisado por e-mail pelo Gerente de Projeto, sobre a reunio de Kick Off, com base no cronograma enviado, o PPQA planeja suas atividades sugerindo as datas em que ocorrero suas auditorias. As datas reais em que as auditorias ocorrero sero confirmadas na reunio de Kick Off. 5.1.1 Gerar Plano de PPQA Na reunio de Kick Off, o Gerente de Projetos apresenta o Plano do Projeto (WP-PP-01) e o Cronograma do Projeto (WP-PP-03) ao PPQA, conforme definido no documento de Planejamento do Projeto (IT-PRO-11). Neste instante, o PPQA apresenta a sugesto de data de suas atividades. Estas datas so acordadas com os participantes da reunio e acrescentadas ao Cronograma do Projeto.

As Avaliaes de PPQA so realizadas com uma periodicidade quinzenal ou ao final da fase, o que ocorrer primeiro. Alm disso, podem ocorrer avaliaes eventuais, quando: y y O PPQA observar a necessidade de verificar o projeto fora da data prevista no seu plano; O Gerente da Fbrica de Software, Gerente de Projetos ou Gerente de Configurao envolvidos solicitam ao PPQA uma verificao adicional no projeto.

Quando o Cronograma do Projeto sofre alterao, o PPQA informado pelo Gerente de Projetos e verifica se h necessidade de programar alguma avaliao de produto eventual. 5.1.2 Definio de Check list de Avaliao de Aderncia e Adequao aos Processos Caso o processo a ser seguido seja do cliente ou parcialmente do cliente, nesse momento o checklist de avaliao dever ser customizado para atender o novo processo. Com base nas informaes do projeto, o PPQA observa se o cliente estabeleceu algum padro para modelagem ou desenvolvimento do produto. Caso positivo, o PPQA adiciona uma coluna no Checklist do Projeto em questo chamada Padro e registra neste campo se os produtos esto seguindo os padres estabelecidos pelo Cliente. Na primeira Avaliao do Projeto, o PPQA utiliza o modelo do Checklist disponvel no DOC (WP-PPQA-02). A partir da segunda Avaliao, o PPQA atualiza o Checklist da avaliao anterior, atualizando os dados, a data e a verso do documento. Cada aba do Checklist corresponde a uma rea de Processo e existe uma aba reservada para o seguimento do PRO_PD Processo de Desenvolvimento. Alm destas, a aba Entrevistas contm questes que podem ser utilizadas em entrevistas de institucionalizao para novos integrantes da equipe. 5.2 Avaliar Objetivamente os Processos Os processos Planejamento do Projeto, Gerncia de Requisitos, Monitorao e Controle, Garantida da Qualidade do Produto e do Processo, Medio e Anlise e Gerncia de Configurao so avaliados atravs de auditorias realizadas periodicamente. 5.2.1 Realizar Auditoria da Aderncia aos Processos No dia da avaliao, programado no CaMMIla, o PPQA abre o Projeto que ser avaliado e identifica no Cronograma do Projeto quais as atividades que deveriam ter sido executadas e quais os artefatos que deveriam ter sido gerados at o momento da avaliao, bem como aqueles que esto em data prxima de elaborao. Os desvios identificados anteriormente que foram resolvidos so retirados do checklist, sendo mantido registro apenas no WP-PPQA-04 Relatrio de Acompanhamento dos Projetos, dessa forma ao final da auditoria o PPQA saber a aderncia atualizada do projeto sem os desvios que j foram corrigidos. Na avaliao do Projeto em questo o PPQA acessa todos os produtos gerados ao longo do projeto e preenche o Checklist para Auditoria de Aderncia e Adequao a Processos (WPPPQA-02), seguindo os critrios abaixo: 1. 2. 3. 4. 5. Se ele foi identificado, ou seja, se ele encontrou o artefato / produto; Se ele est armazenado no local indicado pela gerncia de dados; Se ele foi produzido a partir do modelo correto; Se ele foi produzido / preenchido com coerncia; Se h problema de integridade .

Para verificar a integridade dos dados de Medio e Anlise, o PPQA consulta os relatrios de origem dos dados no CaMMIla, conforme indicado na IT-PRO-13 Medio e Anlise e confere com o contedo preenchido no Relatrio de Resultados de Medio e Anlise do Projeto (WP-MA-02). Aps a realizao da avaliao, o PPQA registra as horas gastas com a atividade no CaMMIla e adiciona o arquivo do Checklist no repositrio do projeto avaliado. Em seguida o PPQA envia um e-mail para os stakeholders internos divulgando o resultado da avaliao realizada.

A auditoria da aderncia ao processo Garantia da Qualidade do Produto e do Processo realizada de acordo com o definido no item 5.4 Realizao de Avaliao de Aderncia e Adequao ao Processo de PPQA. As atividades monitorar processos, analisar dados e analisar dados por auditores externos so realizadas conforme item 5.5 Monitorao e Controle dos Processos, desse documento. 5.2.2 Identificao e Implementao de Oportunidades de Melhoria Durante as avaliaes, o PPQA pode identificar alguma oportunidade de melhoria para o processo. Caso isso ocorra, ele a cadastra no CaMMIla, no item Oportunidade de Melhoria. A rea de Processo a que a melhoria relacionada deve ser informada no campo Descrio. A equipe do projeto tambm tem condies de identificar oportunidades de melhoria fora dos momentos de avaliao. Neste caso, o profissional executa o mesmo procedimento indicado acima. As Oportunidades de Melhoria so avaliadas periodicamente pela Coordenao do SEPG, que tambm acompanha a implementao daquelas que so acatadas, cuidando para que todos os envolvidos sejam informados. Mensalmente, durante as reunies do SEPG, a Coordenao do SEPG reporta as Sugestes / Oportunidades de Melhoria analisadas no perodo. Caso a Coordenao do SEPG no consiga definir sobre a anlise de uma determinada Sugesto / Oportunidade de Melhoria, esta levada para ser discutida durante a reunio do SEPG. Durante a sua anlise, o SEPG classifica as oportunidades de melhoria como: y y y No-procedente: quando foi analisada pelo SEPG, mas no ser implementada; Em andamento: quando considerada procedente, mas ainda no foi implantada; Concluda: quando foi implantada.

5.2.3 Verificao de Treinamentos Durante as avaliaes, o PPQA confere tambm se os profissionais participantes do projeto esto capacitados para exercer o seu papel, atravs dos treinamentos indicados no item 5. Treinamento de cada processo. O resultado desta avaliao registrado na rea respectiva do Checklist. 5.3 Avaliar Objetivamente os Produtos do Trabalho Os produtos de trabalho (artefatos) so avaliados em conjunto com os processos, na data da avaliao programada no CaMMIla, conforme descrito no item 5.2.1 Realizar Auditoria da Aderncia aos Processos. 5.3.1 Identificar Pontos de Controle para Garantida da Qualidade Os pontos de controle de avaliao da objetividade dos produtos so os mesmos pontos definidos para avaliao da objetividade dos processos, conforme plano de PPQA. 5.3.2 Realizar Avaliao dos Produtos Conforme Planejado A realizao da avaliao dos produtos acontece em conjunto com a avaliao dos processos conforme item 5.2.1 Realizar Auditoria da Aderncia aos Processos. 5.4 Comunicar Desvios e Garantir sua Resoluo As atividades identificao, comunicao e garantia de resoluo dos desvios so executadas da mesma maneira para os produtos e processos. 5.4.1 Identificao e Resoluo de Desvios Durante a avaliao, caso o PPQA identifique problemas relacionados aos artefatos (desvios), o profissional responsvel pela produo do artefato entrevistado (presencialmente ou por

telefone), a fim de que o problema seja esclarecido e que uma sugesto de correo seja identificada. Neste caso, o PPQA preenche um Relatrio de Desvio (WP-PPQA-03) e o envia ao responsvel pela soluo, com cpia para o superior imediato, indicando um prazo para a soluo, conforme critrios a seguir estabelecidos. Neste relatrio, o PPQA sugere uma forma de correo do desvio, que pode ser acatada ou no pelo responsvel pelo relatrio. Severidade Critrios para classificao de desvios Prazo (dias teis) Quando o artefato no foi produzido ou uma atividade no foi realizada, Alta 2 comprometendo a execuo de outras atividades do projeto. Quando um artefato elaborado no est de acordo com o modelo padro Mdia 3 ou no foi preenchido/produzido com coerncia Quando o artefato no est armazenado no local indicado pela gerncia Baixa 4 de dados ou o desvio no tem maiores impactos no projeto OBS. 1: Quando pertinente, o PPQA pode estabelecer um prazo que no esteja contemplado dentre os critrios acima, desde que haja uma justificativa plausvel e esta seja registrada. OBS. 2: Quando o desvio escalonado, dado o prazo de apenas 1 (um) dia til para sua resoluo. OBS. 3: O PPQA verifica a correo do desvio 1 (um) dia aps a data de previso indicada no relatrio. 5.4.1.1 Acompanhamento dos Desvios Diariamente a partir do Relatrio de Acompanhamento dos Projetos (WP-PPQA-04) o PPQA verifica se os desvios com data de concluso para a data atual foram resolvidos. Em caso negativos os desvios devem ser escalonados seguindo a regra do item 5.4.1.3 Escalonamento dos Desvios. 5.4.1.2 Status dos Desvios Para acompanhamento dos desvios identificados, o PPQA mantm o Relatrio de Acompanhamento de Projetos (WP-PPQA-04) atualizado, segundo os seguintes critrios: y y y Pendente: quando a data de soluo prevista ainda encontra-se em aberto; Concludo: quando o mesmo foi resolvido, tendo sido ou no escalonado; Encerrado: quando for registrado, mas a correo na linha do tempo no mais possvel.

5.4.1.3 Escalonamento dos Desvios Para garantir a resoluo de um desvio, o mesmo deve ser escalonado segundo os seguintes critrios: 1. Se a data prevista para a correo do desvio no for cumprida, o desvio pendente encaminhado ao superior imediato do responsvel pelo mesmo, que passa a ser responsvel pela soluo do desvio; 2. Se este no obtiver a correo, o desvio escalonado pela segunda vez, para o prximo superior imediado, que passa a ser o responsvel pela soluo do desvio pendente; 3. Se mesmo assim no for solucionado, aberta uma No-Conformidade pertinente. OBS. 1: Quando o desvio estiver sob a responsabilidade da Gerncia de Sistemas de Informao e o mesmo no for resolvido, gerada uma No Conformidade. OBS. 2: O ltimo nvel de escalonamento dos desvios a Diretoria de Tecnologia e Servio, que j recebe o desvio como uma No-Conformidade. Tanto os Relatrios de Desvios quanto os Relatrios de Acompanhamento de Projetos ficam armazenados no repositrio. A atualizao destes documentos pode ser feita no final de uma avaliao ou durante o acompanhamento de resoluo de desvios.

No Relatrio de Acompanhamento de Projetos mantido o histrico dos desvios dos projetos encerrados at que se passe 1 (um) ano a contar da data de encerramento do mesmo. Aps este perodo, o projeto passa a ser desconsiderado nas anlises de PPQA. 5.5 Realizao de Avaliao de Aderncia e Adequao ao Processo de PPQA O PPQA avaliado mensalmente em suas atividades e no seguimento do Processo de Garantia da Qualidade do Produto e do Processo (PRO_PPQA) por um auditor externo. Desta avaliao gerado o Relatrio de Acompanhamento das Atividades do PPQA (WP-PPQA-05). Os dados obtidos so sintetizados, de forma a evidenciar: aderncia ao processo pelo PPQA, no conformidades observadas no perodo, inadequaes do processo relatadas no perodo e aes a serem implementadas para cada desvio. Os Relatrios de Acompanhamento das Atividades de PPQA ficam armazenados no repositrio. 5.6 Monitorao e Controle dos Processos Para a PA de Garantia da Qualidade do Produto e do Processo, a monitorao e controle do processo realizada: 1. % de Desvios por PA - O PPQA, durante as suas avaliaes, utiliza o Checklist para Auditoria de Aderncia e Adequao a processos e registra no mesmo os desvios identificados. As informaes dos desvios identificados para os projetos servem para atualizar o Relatrio de Acompanhamento. Durante a Reunio com a Gerncia de Sistema de Informao, o PPQA reporta todas as questes relevantes identificadas durante a sua avaliao, inclusive o percentual de desvios identificados por PA. Nesta reunio so registradas, inclusive, as anlises a respeito dos percentuais. 2. Alm disso, existe o trabalho de melhoria de processos realizado pelo SEPG. Antes da sua reunio mensal do SEPG, a Coordenao do SEPG solicita que o Gerente de Projetos e o PPQA enviem por e-mail as informaes da mtrica acima mencionada, com o intuito de consolid-la. As informaes relativas s no-conformidades da PA de PPQA so levadas em considerao nesta consolidao feita pelo SEPG. Durante essa reunio, as informaes e anlises tratadas em conjunto so registradas. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado com a anlise das mtricas. Caso sugestes / oportunidades de melhorias sejam identificadas, a equipe do projeto cadastra as mesmas no CaMMIla para anlise do SEPG. 3. Pela PPQA externo e SEPG, atravs da anlise de adequao do Processo de PPQA (PRO_PPQA) realizada mensalmente, deixando a avaliao registrada no Relatrio de Acompanhamento das Atividades do PPQA (WP-PPQA-05). Aps a realizao da atividade acima mencionada, a PPQA Externo e o SEPG filtram as informaes colhidas que so relevantes para o posicionamento do processo. Essas informaes comporo a pauta da reunio do SEPG e sero registradas em Memria de Reunio do SEPG (RQ-7.3AC). 5.7 Comunicao do Status dos Processos Mensalmente, o PPQA reporta todos os assuntos relevantes detectados em cada projeto ao Gerente de Sistemas de Informao, em reunio formal, da qual gerada a Memria de Reunio com o Gerente de Sistemas de Informao (WP-05). Antes do incio da reunio com o Gerente de Sistemas de Informao, o PPQA sintetiza as informaes do Relatrio de Acompanhamento de Projetos, gerando um parecer prvio dos assuntos. Os grficos apresentados nas reunies de reporte no contemplaro dados dos projetos finalizados, somente dos ativos. Durante a reunio, as informaes e anlises tratadas so registradas na Memria de Reunio com o Gerente de Sistemas de Informao, que contm a anlise conjunta dos itens abordados. Caso necessrio, um Plano de Ao gerado para solucionar algum problema detectado durante o andamento dos Projetos. O reporte da avaliao externa de PPQA feito ao final de cada avaliao atravs de e-mail enviado para o SEPG, Gerente de Sistemas e Diretoria de Tecnologia e Servios.