PoliticaOrg DR

POLTICA ORGANIZACIONAL
PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH
Data Responsvel Doc ID Localizao Verso do Documento
01/03/2010 Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Poltica Organizacional 3.0
Poltica Organizacional_V003
Histrico de Reviso
Revises so melhoramentos na estrutura do documento e tambm no seu contedo. O objetivo primrio desta tabela a fcil identificao da verso do documento. Toda modificao no documento deve constar nesta tabela.
Data
Verso
Autor
Danielle Noronha, Jacilane Rabelo Jacilane Rabelo
Descrio
Solicitaes de mudana ocorridas na simulao do dia 18/12/2009 Mudanas na medio do tamanho do requisitos e no processo de gerncia de requisitos e gerncia de projetos para atender as solicitaes da avaliao do MPS-BR do dia 25/02/2010.
21/12/2009 2.0 01/03/2010 3.0
Documento de Requisitos
Pgina 2 de 28
LISTA DE ABREVIATURAS E SIGLAS AAQ ALL ATR CCO CFT DIM DOA DRE Dr Activity DVT GR GP MRC - REUNIO MRT PAC PG PPR PTC ROT SRD SQA TE Ata de Acompanhamento da Qualidade Todos os Artefatos gerados at o momento Ata de Reunio Contrato Comercial Cdigo Fonte Documento de Impacto Documento de Anlise Documento de Requisitos Sistema web que controla as solicitaes realizadas pelo cliente Documento de Visita Tcnica Gerente de Requisitos Gerente de Projeto Reunio de Marco Matriz de Rastreabilidade Plano de Ao Programador Plano de Projeto Proposta Tcnica Comercial Registro de Ocorrncia de Teste Solicitao de Requisito DrActivity Garantia da Qualidade de Software Testador
Pgina 3 de 28
DEFINIO DOS ARTEFATOS
AAQ Ata de Acompanhamento da Qualidade: Esse documento auxilia na monitorao dos processos de gerncia de requisitos e gerncia de projeto fazendo a verificao dos artefatos gerados para um determinado projeto. ATR - Ata de Reunio - Documento para comprovao do processo de gerncia de requisitos e gerncia de Projeto. CCO - Contrato Comercial: Documento que contm um acordo entre cliente e empresa. Possui clausula contratuais, identificao das partes, oramento. DIM Documento de Impacto: Documento que tem por objetivo formalizar e documentar a anlise de impacto das alteraes dos requisitos no projeto. DRE Documento de Requisitos: a especificao oficial dos requisitos do sistema para todos os envolvidos no projeto. DOA - Documento de Anlise: Documento que contm as informaes pertinentes a anlise do projeto, com diagramas (quando necessrio) e registro de alteraes. Este documento ser utilizado como base para as atividades de acompanhamento, reviso, verificao a fim de manter a integridade dos dados. DVT - Documento de Visita Tcnica: Documento que relata uma visita de um tcnico no cliente. A visita pode ser para qualquer natureza de trabalho com: aceite dos requisitos, teste, homologao ou implantao. Deve ser registrada data e horrios e assinados por um representante do cliente e pelo tcnico. MRT Matriz de Rastreabilidade: Apresenta o relacionamento entre os requisitos. A matriz de rastreabilidade fornece suporte equipe para tomadas de decises, descobertas de problemas, facilita a manuteno durante o ciclo de vida do projeto, permitindo uma avaliao do impacto que uma mudana pode causar. PAC Plano de Ao: Documento que relata problemas ocorridos na reunies de acompanhamento feito pelo Gerente de Projeto e Gerente de Requisitos.
Pgina 4 de 28
PPR - Plano de Projeto: Define como o projeto executado, monitorado, controlado e encerrado. composto pelos artefatos, ferramentas, interface e ambiente tcnico, WBS, risco, custo e esforo PTC - Proposta Tcnica Comercial: Documento que contm um acordo entre cliente e empresa. Contm definio preliminar do escopo, oramento e identificao das partes ROT - Registro de Ocorrncia de Teste: Documento que registra o andamento do teste, quem executou e a data da execuo. SRD - Solicitao de Requisito DrActivity: o registro das solicitaes de requesitos feita por cliente que registrada no Dr Activity .
Pgina 5 de 28
Sumrio
1 2 3 4 5 6 7 8 9 Sobre a solicitao de servios e o Processo de Software ................................................. 8 Sobre a Gerncia de Projetos de Software........................................................................ 8 Sobre a Gerncia de Requisitos...................................................................................... 10 Sobre o Tamanho do Requisito ...................................................................................... 11 Sobre o Esforo Humano............................................................................................... 12 Sobre a Comunicao do Projeto ................................................................................... 12 Sobre os Recursos No Humanos .................................................................................. 13 Sobre a Divulgao e Institucionalizao da Poltica...................................................... 13 Sobre a Descrio das Fases do Projeto ......................................................................... 13 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.9.1 9.9.2 9.9.3 9.9.4 9.9.5 9.9.6 9.9.7 9.9.8 9.9.9 Levantamento ....................................................................................................... 13 Anlise ................................................................................................................. 14 Projeto, Implementao e Teste ............................................................................ 14 Implantao .......................................................................................................... 15 Gerncia de Requisitos ......................................................................................... 15 Controle de Mudana de Requisitos...................................................................... 16 Gerncia da Qualidade.......................................................................................... 16 Gerncia de Projeto .............................................................................................. 16 Detalhamento dos artefatos produzidos pelo processo ........................................... 17 PPR Plano de projeto................................................................................... 17 DOA Documento de Anlise........................................................................ 18 ROT - Relatrio de Ocorrncia de Testes...................................................... 18 AAQ - Ata de Acompanhamento de Qualidade............................................. 18 ATR - Ata de REUNIO................................................................................ 18 DRE - Documento de Requisitos .................................................................... 18 DVT Documento de Visita Tcnica ............................................................. 19 DIM Documento de Impacto ....................................................................... 19 PAC Plano de Ao...................................................................................... 20
ANEXO I............................................................................................................................. 21 ANEXO II ........................................................................................................................... 22 ANEXO III .......................................................................................................................... 23 ANEXO IV.......................................................................................................................... 24 ANEXO V ........................................................................................................................... 25
Documento de Requisitos Pgina 6 de 28
ANEXO VI.......................................................................................................................... 26 ANEXO VII......................................................................................................................... 27 ANEXO VIII ....................................................................................................................... 28
Pgina 7 de 28
A DR TECH SERVIOS EM SOFTWARE LTDA / DOCTOR TECH, define neste documento sua Poltica Organizacional para Desenvolvimento de Software.
1 Sobre a solicitao de servios e o Processo de Software

1.1 Todos os servios de manuteno de software devem ser registrados no sistema de Atendimento ao Usurio Dr Activity (http://www.doctortech.com.br/dractivity)( e o fluxo de atendimento s solicitaes (em anexo) devem ser obedecidos) ou atravs do Documento de Visita Tcnica (DVT). 1.2 O processo a ser seguido deve abranger as prticas de Gerncia de Projetos e Gerncia de Requisitos. Projetos considerados pequenos podem adotar processo simplificado mediante justificativa; 1.3 O processo padro e os templates de documentos a serem utilizados configuram diretrizes a serem seguidas em projetos de software e que devem ser mantidas visando melhoria contnua. 2 Sobre a Gerncia de Projetos de Software 2.1 O Gerente de Projetos o responsvel pelo projeto a partir da assinatura da Proposta Tcnica Comercial (PTC) com o cliente. 2.2 Todo projeto deve ter suas estimativas de tamanho e esforo calculadas, com base no escopo definido e nos requisitos elicitados. A viabilidade do projeto deve ser analisada antes de ser repassado ao cliente. 2.3 O Plano do Projeto (PPR) deve ser baseado nas estimativas, requisitos, restries e na Poltica Organizacional da Empresa. O projeto deve ter o comprometimento da equipe e deve ser monitorado em marcos estabelecidos. O PPR estabelece os recursos humanos e de apoio necessrios, a forma de comunicao entre os envolvidos, os artefatos a serem gerenciados, os riscos a serem monitorados, o cronograma do projeto. 2.4 O cronograma do projeto deve conter: nome da tarefa, durao, incio (planejado), fim (planejado), incio real, fim real, atividades predecessoras, nome dos recursos. Como regra default, Cada atividade possui oum atraso aceitvel para cada atividade de at 2 (dois) dias para o incio real ou trmino real (essa regra pode ser alterada em projetos especficos atravs de nota no Plano do Projeto). 2.5 Em caso de alteraes no plano haver comunicao com os envolvidos e um novo comprometimento deve ser estabelecido e registrado atravs da ATR.
Pgina 8 de 28
2.6 Para monitorar o Gerenciamento do Projeto sero realizados Acompanhamentos a cada (2) dois dias pelo Gerente de Projetos e Reunies de Marco (identificadas como MRC - REUNIO no cronograma do projeto); 2.7 No Acompanhamento sempre que for encontrado um problema, o Gerente de Projeto ir criar um plano de ao identificando qual foi o problema e quem ir resolver. 2.8 Nas reunies de Marco toda a equipe envolvida no projeto dever est presente e assinar uma Ata de Reunio confirmando a presena e o seu comprometimento com os objetivos descritos na mesma. 2.9 Na primeira Reunio de Marco obtm-se o comprometimento com o PPR e DRE. 2.10 Para garantir a qualidade dos artefatos e verificar se o processo de gerncia de projeto est sendo seguido corretamente, conforme definido no processo da empresa, em todas as reunies de marcos ser feita a Verificao dos Artefatos pelo responsvel da Qualidade do Projeto e relatados na Ata de Acompanhamento da Qualidade (AAQ), se houver problemas so registrados plano de ao e prazo para comprimento. Os problemas relatados na AAQ sero verificados na prxima reunio de marco. 2.11 Nos acompanhamentos o Gerente de Projeto para garantir o controle do projeto do incio at o fim faz : A reviso do PPR, para monitorar os riscos de prioridade alta; A verificao da implementao dos requisitos para saber se eles esto sendo implementados dentro do planejado analisando diretamente o Cronograma, CFT e MRT; A verificao do teste dos requisitos para saber se eles esto sendo implementados dentro do planejado analisando diretamente o Cronograma, ROT, MRT e o programa executvel; 2.12 Nas reunies de marco o Gerente de Projeto para garantir o controle do projeto do incio at o fim faz: A reviso do PPR, para monitorar os riscos e recursos humanos; A verificao do cronograma para saber se os requisitos esto sendo implementados e testados dentro do planejado; A verificao da viabilidade tcnica do projeto; A verificao se os scripts de mudana no banco (tabela, procedures, triggers, etc.) esto sendo armazenados; 2.13 A diretoria de alto nvel ir verificar se houve as reunies de marcos e se os objetivos descritos nos itens 2.8, 2.9, 2.10 e 2.12 foram cumpridos e ir rubricar a Ata de Reunio.
Pgina 9 de 28
3 Sobre a Gerncia de Requisitos 3.1 Os Fornecedores de Requisitos (Clientes) para o projeto devem ser identificados na Proposta Tcnica a partir do primeiro contato aps solicitao do servio no Documento de Requisitos (DRE). 3.2 Em servios de manuteno sero criados login e senha para usurios que esto autorizados para inserir solicitaes no Dr Activity. Os contratantes, responsveis ou chefias dos clientes de manuteno devem enviar um email autorizando e solicitando a criao de logins para que outros funcionrios possam enviar solicitaes atravs do Dr Activity. 3.3 Os requisitos identificados para o projeto devem ser avaliados objetivamente antes de serem apresentados aos clientes. A avaliao dos requisitos deve ser executada pelo Gerente de Projeto/Requisito juntamente com o Programador. Aps avaliao pela equipe tcnica enviado ao cliente o Documento de aceite (atravs de email ou DVT) para que ele avalie os requisitos. O andamento do projeto depende da aprovao dos requisitos pelos clientes. 3.4 Os requisitos devem ser gerenciados atravs da matriz de rastreabilidade entre os mesmos com os produtos de trabalho. 3.5 O fornecedor de requisitos dever assinar o termo de aceite atravs da DVT ou por email. 3.6 A aceitao dos requisitos pelos programadores feita na primeira reunio de marco do projeto. 3.7 Toda mudana nos requisitos deve ser gerenciada. O impacto da mudana deve ser calculado e registrado para conhecimento e aprovao do cliente. Os demais documentos do projeto devem ser revisados para manter a consistncia com os requisitos. 3.8 Para monitorar o Gerenciamento de Requisitos sero realizados Acompanhamentos a cada (2) dois dias pelo Gerente de Requisitos e Reunies de Marco (identificadas como MRC - REUNIO no cronograma do projeto); 3.9 No Acompanhamento sempre que for encontrado um problema, o Gerente de Requisitos ir criar um plano de ao identificando qual foi o problema e quem ir resolver. 3.10 Nas reunies de Marco toda a equipe envolvida no projeto dever est presente e assinar uma Ata de Reunio confirmando a presena e o seu comprometimento com os objetivos descritos na mesma. 3.11 Na primeira Reunio de Marco obtm o comprometimento com o PPR e DRE. 3.12 Revises entre requisitos e produtos de trabalho sero feitas para garantir a qualidade dos artefatos e verificar se o processo de gerncia de requisitos est sendo seguidos corretamente. Conforme definido no processo da empresa, em todas as reunies de marcos ser feita a Verificao dos Artefatos pelo responsvel da Qualidade do Projeto e relatados na Ata de Acompanhamento da
Qualidade (AAQ), se houver problemas so registrados plano de ao e prazo para comprimento. Os problemas relatados na AAQ sero verificados na prxima reunio de marco. 3.13 Nos acompanhamentos o Gerente de Requisitos para garantir consistncia entre requisitos e produtos de trabalho, ir verificar se: os requisitos esto sendo implementados analisando diretamente o CFT e MRT ; os requisitos esto sendo testados analisando diretamente o ROT, MRT e o programa executvel; h as solicitao de mudanas dos requisitos foram registradas atravs de SRD ou DVT (caso tenham havido). 3.14 Nas Reunies de Marcos o Gerente de Requisitos para garantir consistncia entre requisitos e produtos de trabalho, ir verificar se: o que foi implementado est coerente com que foi definido no DRE e DOA; o que foi testado est coerente com o que foi definido no DRE e DOA; a matriz de rastreabilidade est sendo atualizada; h solicitao de mudanas dos requisitos atravs de SRD ou DVT.
3.15 A diretoria de alto nvel ir verificar se houve as reunies de marcos e se os objetivos descritos nos itens 3.10, 3.11, 3.14 foram cumpridos e ir rubricar a Ata de Reunio. 4 Sobre o Tamanho do Requisito 4.1 Para medir o tamanho de cada requisito, os seguintes critrios so considerados na classificao de tamanho: Nmero de funes considera-se funo uma atividade do tipo: inserir, alterar, excluir, consultar, imprimir. CRUDs so cadastros que incluem: inserir, alterar, excluir e consultar; Complexidade de paginao considera-se complexidade alta de paginao quando h mais de 1000 registros de retorno e preciso separar por pginas; Complexidade de layout layouts complexos so os que exigem projeto elaborado de tela ou relatrio; Pesquisa aninhada pesquisas que envolvem vrias subpesquisas; Cadastro aninhado cadastros que envolvem vrios subcadastros; Tela para reuso telas que sero reutilizadas em diferentes funes;
4.2 As seguintes regras devem ser utilizadas para classificao de tamanho de cada requisito:
Pgina 11 de 28
Classificao do Regras de Classificao Tamanho requisitos que implementem uma funo (com layout no complexo); Simples complexidade baixa de paginao; at 2 funes (layout no complexo); Mdio-simples complexidade alta de paginao; CRUD completo ou mais de 2 funes; Mdio ou pesquisa aninhada; ou funo com layout complexo; conjunto de CRUDS; Complexo ou cadastros aninhados; e tela para reuso com layout complexo; 5 Sobre o Esforo Humano 5.1 Para medir o esforo, ser adotada a seguinte diretriz para Desenvolvimento e Teste do Requisito: Tamanho de Requisito Simples Mdio-Simples Mdio Complexo Esforo relacionado em Homem/Hora At 8 9 a 16 17 a 32 A partir de 33
Observao: Para estimar o esforo do requisito deve se considerar quantos itens das regras de classificao de tamanho foram considerados. Legenda:
Tamanho de Requisito: o requisito poder ser classificado em quatro (4) tipos: simples, mdio-simples, mdio e complexo Esforo relacionado em Homem/Hora: o tempo que o desenvolvedor ir gastar para implementar o requisito.
5.2 Alm do esforo de desenvolvimento e teste dos requisitos, deve ser estimado tambm o tempo de elaborao do DOA. O tempo de elaborao do DOA deve ser estimado com base no tempo de elaborao do documento em projetos semelhantes.
6 Sobre a Comunicao do Projeto 6.1 Toda comunicao com o cliente deve ser registrada em documentos oficiais da empresa; 6.2 Quando houver conversa com o cliente por telefone, Messenger e skype deve ser enviado um resumo da conversa por email para o cliente, solicitando que ele confirme o que est escrito, garantindo o entendimento dos requisitos pelo cliente. 6.2 Os documentos oficiais utilizadas para comunicao de todo o projeto so: ATR, Email, DVT, PAC;
Pgina 12 de 28
7 Sobre os Recursos No Humanos 7.1 Os recursos para o projeto so identificados como homem/estao de trabalho, ou seja, cada funcionrio possui seu prprio computador, sendo os mesmos utilizados dentro da empresa DrTech. Os computadores possuem sistema operacional, ferramentas de desenvolvimento, modelagem de sistemas, gerenciamento de projeto e gerenciamento de requisitos. 8 Sobre a Divulgao e Institucionalizao da Poltica A Poltica de Desenvolvimento de Software dever ser aprovada pela Direo da empresa. As condies mnimas para que a Poltica seja revisada so: - Quando o nvel de maturidade for alterado para incluir novos processos e capacidades - Quando o organograma for alterado - Quando algum dos itens que compem a Poltica Organizacional for alterado. Todos os colaboradores devem ter conhecimento da Poltica atravs de mensagem individual, disponibilizao na pgina (http://www.doctortech.com.br/) e em meio impresso. 9 Sobre a Descrio das Fases do Projeto As fases do processo definido pela DrTech sero abordadas nesse tpico. 9.1 Levantamento O levantamento, mostrado no ANEXO I, dividido em quatro etapas: Atendimento, Anlise, Proposta e Negociao. Nessa fase definido o escopo, verificado se vivel e assim registrada a aceitao do cliente. O foco a garantia que o projeto tem viabilidade tcnica e financeira. Na etapa de atendimento verificado se o projeto do tipo de Manuteno ou de Desenvolvimento. No caso de Manuteno o fluxo passa para Analisar Solicitao de Servio (Anlise) e ento verificado se a solicitao vivel (Anlise). Caso a solicitao no seja vivel o fluxo ir para Comunicar Cancelamento ao Cliente (Atendimento) e o processo finalizado. Caso a solicitao seja vivel o fluxo ir Verificar Necessidade de Proposta. Sendo a Proposta Comercial Necessria (Anlise) o fluxo vai direto para Fase de Anlise, se no for necessrio ento vai para Elaborar Proposta Comercial (Proposta) e Submeter Proposta ao cliente (Negociao). A proposta ser verificada se estiver Proposta OK (Negociao) o fluxo passa para Registrar Proposta Aceita (Negociao) finalizando a fase de Negociao iniciando a fase de Anlise. Se proposta no estiver ok ser verificado a possibilidade de alterao (Verificar Possibilidade de Alterao de
Proposta (Negociao). Se for Vivel vai para (Elaborar Proposta Comercial) seno o processo finalizado. Caso seja um projeto novo (Desenvolvimento), o fluxo passa para Atendimento ao cliente (Atendimento) e ento passa para Analisar Solicitao de Servio e executa todo o processo feito a partir dessa atividade. Os artefatos gerados nessa fase so: CCO, PTC, DVT, SRD 9.2 Anlise A anlise, mostrado no ANEXO II, dividida em duas etapas: Requisitos e Plano de Anlise. Nessa fase defini-se os requisitos e um plano detalhado dos requisitos. Gerando o DRE e PPR. Primeiro so especificados os Requisitos, e ento vai para Aprovao dos Requisitos se o requisito no for Aprovado volta para Especificar Requisitos, e repete o processo at que os requisitos sejam aprovados. Os requisitos sendo Aprovados segue para Criar a Matriz de Rastreabilidade, se Matriz Criada? O gerente juntamente com sua equipe Especifica os artefatos, ferramentas, interfaces e ambiente tcnico, Define Riscos, Estima Custo, Define Recursos, Define cronograma e Define WBS. Aps a definio dos recursos ir para Apresentar Plano de Projeto e obter Comprometimento (Plano e Anlise) e sendo Aprovado segue para a fase de Projeto, Implantao e Teste. Caso contrrio retorna para a atividade de Especificao dos artefatos e executa todo o processo destacado em amarelo. Os artefatos gerados nessa fase so: DRE, DVT, MRT, PPR, Email de Aprovao dos Requisitos.
9.3 Projeto, Implementao e Teste Esta fase, ilustrado no ANEXO III, est dividida em trs etapas: Projeto, Implementao e Teste. Nesta fase o sistema ser produzido e testado. Na etapa do Projeto, a primeira coisa a ser verificada se o Designer Necessrio?. Caso seja necessria alguma alterao no Documento de Anlise o fluxo passa para a atividade Design (projeto). Nesta fase so construdos os diagramas necessrios a critrio do Gerente do Projeto (GP) ou Programador (PG) (possveis diagramas so: caso de uso, diagrama de classe, modelo entidade e relacionamento). Em caso de desenvolvimento de novos sistemas sugere-se que sejam elaborados os diagramas de caso de uso e o modelo entidade-relacionamento. Em caso de Manuteno de sistemas ser necessrio registrar os elementos alterados, sendo armazenadas em pasta do diretrio do repositrio as novas verses (triggers, store procedures, interfaces etc) e registrar as alteraes no modelo entidade relacionamento.
Na etapa de implementao so gerados os arquivos de cdigo fonte e ento so elaborados os Testes Parciais. Caso os testes indiquem que o cdigo est pronto para Entrega executado o Teste Global, caso contrrio retorna para Implementar. Finalizando o Teste global positivamente ser Liberado para fase de implantao. Caso contrrio vai para a atividade Implementar e faz o processo descrito anteriormente. Se Design no for necessrio o fluxo passa direto para a atividade Implementar. Os artefatos gerados nessa fase so: DOA, CFT, ROT, MRT 9.4 Implantao Est dividida em trs etapas: Homologao, Validao e Concluso. O objetivo desta fase, mostrado no ANEXO IV, instalar o software no ambiente do usurio, ou seja, preparao do ambiente que vai suportar o produto no usurio final. Na etapa de Homologao realizada a Implantao Final, seguida pela Homologao Final, ou seja, validao do software por parte do cliente. Caso o Projeto seja aceito (validao), deve ser verificado se H treinamento (Concluso). Se sim ir para Realizar Treinamento (concluso) e pra Realizar o Fechamento do Projeto (Concluso) finalizando esta fase. Se o projeto no for aceito realizado o Teste de Aceitao (Validao), verificado se as Correes Aceitas (Validao). Se correes aceitas volta para homologao e faz todo o processo novamente, se no volta para Teste de Aceitao. Os artefatos gerados nessa fase so: DVT, Email de Validao do Cliente, ROT, PPR 9.5 Gerncia de Requisitos Possui apenas uma etapa: Gerncia dos Requisitos. O objetivo dessa fase gerenciar o os requisitos do projeto, mostrado no ANEXO V. O responsvel pela Gerncia de Requisitos o gerente de Requisitos. As atividades de gerencia de requisitos so: 1. O documento de requisito criado a partir do contrato e de visitas tcnicas. Em caso de manuteno o DRE obtido atravs da solicitao registrada no Dr Activity. 2. Aprovar requisito: Desenvolvedores registram em ATR o aceite do requisito. 3. Implementar Requisito: Atualizao da matriz de rastreabilidade com a referencia do CFT gerado.O GR deve verificar se o CFT gerado para o requisito 4. Recurso de requisito: Definir prazos e recursos para o desenvolvimento do requisito. 5. Designer: Criao de caso de uso e seu detalhamento (se o Gerente de Requisito achar necessrio), alteraes no banco, MER 6. O desenvolvedor implementa o requisito. 7. O desenvolvedor executa o teste do cdigo do requisito e registra na MRT.
8. O desenvolvedor realiza Teste global com todos os requisitos implementados. 9. Fase de Controle de Mudana de Requisitos, detalhado no item 9.6.. Os artefatos gerados nessa fase so: PPR, DRE, CFT, ROT, MRT
9.6 Controle de Mudana de Requisitos Possui apenas uma etapa: Controle de Mudana de Requisitos. O objetivo dessa fase controlar a mudana dos requisitos, mostrado no ANEXO VI. Primeira coisa a ser feita Obter Solicitao de Mudana. O cliente solicita por email a mudana ou o funcionrio registra no DVT. O responsvel pelo requisito e/ou gerente de requisito vo Analisar Impacto da mudana e preencher o Documento de Impacto. Se no for Aceita a Mudana ir Enviar Email da Justificativa e finaliza a fase. As mudanas sendo aceitas iro para Submeter para Aceitao do Cliente se o cliente aceitar Cliente Aceitou?vai para Incorporar Mudana, e o fluxo passa para a fase de Projeto, Implementao e Teste(onde vai ser refeitos os artefatos coma as solicitaes de mudana e buscar um novo comprometimento com a equipe tcnica.). Caso cliente no aceite as mudanas volta para Obter Solicitao de Mudana e continua o fluxo. Os artefatos gerados nessa fase so: SRD, PPR, DRE, DOA, ATR, DVT, DIM, Email de Aceitao do Cliente 9.7 Gerncia da Qualidade Possui apenas uma etapa: Gerncia de Qualidade. O objetivo dessa fase, ilustrado no ANEXO VII, garantir a consistncia dos artefatos gerados e verificar se os processos de gerncia de requisitos e gerncia de projeto esto sendo feitos. Primeiro deve ser Avaliar Artefatos de Produtos de Trabalho do Projeto em toda reunio de marco do Projeto, verifica-se todos os artefatos gerados at aquele dia (AAL). Essa verificao feita pelo responsvel pela Garantia de Qualidade do Projeto, que ir Identificar Problemas e No Conformidades, havendo No Conformidades Identificadas, ir Estabelecer Plano de Ao e Prazos na AAQ e finaliza o processo. Caso no haja No Conformidades Identificadas fase finalizada. Os artefatos gerados nessa fase so: AAQ 9.8 Gerncia de Projeto Possui apenas uma etapa: Gerncia do Projeto. O objetivo dessa fase gerenciar o plano de projeto, mostrado no ANEXO VIII.
Pgina 16 de 28
No acompanhamento o gerente de projeto deve Capturar Status do Trabalho para garantir o acompanhamento do projeto e ir Avaliar Resultado e Planejar Resoluo de Problemas (havendo defeitos deve ser registrado no PAC), se Houver Alterao ir Realizar Replanejamento corrigindo o PPR e finaliza a fase. Caso no seja necessrio Realizar Replanejamento a fase finalizada. Os artefatos gerados nessa fase so: PPR, PAC.
Nas reunies de marco o gerente de projeto deve Capturar Status do Trabalho para garantir o acompanhamento do projeto e ir Avaliar Resultado e Planejar Resoluo de Problemas (os defeitos podem ter sidos registrados em uma ATR ou em uma AAQ (pelo responsvel pela qualidade) ou por ambos), se Houver Alterao ir Realizar Replanejamento corrigindo o PPR e finaliza a fase. Caso no seja necessrio Realizar Replanejamento a fase finalizada. Os artefatos gerados nessa fase so: PPR.
9.9 Detalhamento dos artefatos produzidos pelo processo 9.9.1 PPR Plano de projeto
Deve conter as seguintes informaes: 1. 2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3. 3.1 3.2 3.3 Introduo Viso Geral do Projeto Objetivo do Projeto Escopo do Projeto Requisito do Projeto Limites do Projeto Premissas do Projeto Viabilidade do Projeto Metodologia de Desenvolvimento/Ciclo de Vida WBS Organizao do projeto Organograma Recursos Custos
Pgina 17 de 28
3.4 3.5 3.5.1 4. 5. 6. 6.1
Tamanho Interfaces Tcnicas e Organizacionais Planejamento de Comunicao Anlise de riscos Armazenamento, cpia, recuperao e preservao Cronograma Marcos do Projeto
9.9.2 DOA Documento de Anlise

Deve conter as seguintes informaes:
1 2
Introduo Analise de Mudanas
9.9.3 ROT - Relatrio de Ocorrncia de Testes

ID
Testador
Data
Rotina
Item a ser testado
Resumo
Status
9.9.4 AAQ - Ata de Acompanhamento de Qualidade Esse documento tem como objetivo fazer a verificao dos artefatos gerados para um determinado projeto. tambm verificado o andamento do projeto e feita a anlise de possveis problemas e/ou defeitos que possam ser encontrados. Essa verificao feita em toda reunio de marco do projeto.
9.9.5 ATR - Ata de REUNIO Deve conter as seguintes informaes: Data, Hora Incio, Hora Fim. Local Participantes: como Nome, Funo e Assinatura Objetivo Atribuies Observaes
9.9.6 DRE - Documento de Requisitos Deve conter as seguintes informaes:

1 Introduo 2 Definio do Problema 3 Stakeholders 3.1 Stakeholders Descries e Responsabilidades 4 Requisitos 4.1 Requisitos Funcionais 4.2 Requisitos No Funcionais 5 Viso Geral Escopo 6 Gerenciamento de Requisitos 6.1 Gerenciamento de Mudana de Requisitos 7 Aceite dos Requisitos
9.9.7 DVT Documento de Visita Tcnica Deve conter as seguintes informaes: Empresa Cliente Representante do Cliente Objetivo Data da Visita Horrio de Chegada Horrio de Sada Descrio Pendncias ou Agendamento Responsvel Dr. Tech Responsvel Cliente
9.9.8 DIM Documento de Impacto

1. Objetivo 2. Descrio da Mudana, Razo da Requisio e Responsvel pela Demanda 3. Impacto na Estimativa de Tamanho e Esforo 4. Impacto no Cdigo 5. Impacto no Banco de Dados 6. Impacto na Interface do Usurio 7. Impacto no Cronograma 8. Verso dos Documentos Base
Pgina 19 de 28
9.9.9 PAC Plano de Ao Deve conter as seguintes informaes: 1. Objetivo 2. Desvios e Aes Corretivas ID Descrio Atividades Responsvel Incio do Desvio envolvidas Fim Incio Fim Aes
Planejado Planejado Real
Real Corretivas Efetuadas
Pgina 20 de 28
ANEXO I
Pgina 21 de 28
ANEXO II
Pgina 22 de 28
ANEXO III
Pgina 23 de 28
ANEXO IV
Pgina 24 de 28
ANEXO V
Pgina 25 de 28
ANEXO VI
Pgina 26 de 28
ANEXO VII
Pgina 27 de 28
ANEXO VIII
Pgina 28 de 28

PoliticaOrg DR

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PoliticaOrg DR

Enviado por

Direitos autorais:

Formatos disponíveis

POLTICA ORGANIZACIONAL

PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH

Data Responsvel Doc ID Localizao Verso do Documento

01/03/2010 Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Poltica Organizacional 3.0

21/12/2009 2.0 01/03/2010 3.0

DEFINIO DOS ARTEFATOS

1 Sobre a solicitao de servios e o Processo de Software

3.4 3.5 3.5.1 4. 5. 6. 6.1

9.9.2 DOA Documento de Anlise

Introduo Analise de Mudanas

9.9.3 ROT - Relatrio de Ocorrncia de Testes

Item a ser testado

9.9.6 DRE - Documento de Requisitos Deve conter as seguintes informaes:

9.9.8 DIM Documento de Impacto

Planejado Planejado Real

Real Corretivas Efetuadas

Você também pode gostar