Especificação de Processo Desenvolvimento de DW

Transcrição

1 Especificação de Processo Desenvolvimento de DW Versão 1.0

2 Sumário 1. Introdução Tabela de Stakeholders Diagrama de Contexto Ciclo de Vida Iniciação Elaboração Construção Transição Fase de Iniciação Diagrama de Atividades da fase de Iniciação iteração única Tabela de Atividades da fase de Iniciação Fase de Elaboração Diagrama de Atividades da fase de Elaboração Tabela de Atividades da fase de Elaboração Fase de Construção Diagrama de Atividades da fase de Construção Tabela de Atividades da fase de Construção Fase de Transição Diagrama de Atividades da fase de Transição Tabela de Atividades da fase de Transição Tabela de Mapeamento de papéis para Pessoas/Unidades Tabela de Papéis e Competências... 42

3 1. INTRODUÇÃO O Tribunal de Contas da União TCU normatizou e implantou um processo de desenvolvimento de soluções chamado Processo de Desenvolvimento de Datawarehouse do TCU TCU-DW, baseado no Rational Unified Process RUP e no PENSO-DW, processo de desenvolvimento de DW da empresa CAST INFORMÁTICA. Este documento tem por objetivo descrever o TCU-DW, detalhando as atividades a serem realizadas em cada fase do ciclo de vida do seu processo de desenvolvimento. Além disso, informa também os responsáveis pelas atividades e os artefatos a serem produzidos. 2. TABELA DE STAKEHOLDERS Stakeholders Executores Gestor do Processo Pessoas de Referência Nomes de Pessoas Núcleo dos processos de desenvolvimento de soluções de DW Titular do SEDIN Serviço de Sistemas de Suporte a Decisão e Inteligência Eudes Cangussú Fabiana Ruas Renato Junqueira

4 3. DIAGRAMA DE CONTEXTO Requisitos e necessidades dos usuários Base de dados corporativa Desenvolvimento de Datawarehouse Sistema de Datawarehouse implantado 4. CICLO DE VIDA Os trabalhos do TCU-DW, assim como no RUP e no PENSO-DW, são realizados em fases. Em cada fase existe um conjunto de atividades que utilizam diversas disciplinas para serem realizadas. O TCU-DW utiliza praticamente todas as disciplinas preconizadas pelo RUP e pelo PENSO-DW, adaptando-as e respeitando as necessidades e particularidades do TCU. O ciclo de vida dos projetos baseados no TCU-DW possui 4 fases, com iterações bem definidas, como mostram as seções subseqüentes Iniciação Esta fase é composta por uma única iteração. Entretanto, pode ocorrer de o projeto ser extremamente complexo ou de existirem dificuldades na definição do escopo. Nestes casos, pode-se definir mais de uma iteração para esta fase, mas é necessário que seja feito um estudo junto aos envolvidos para aprovação desta situação. Nesta fase são tratadas as seguintes questões: Definição do escopo e dimensionamento do projeto, e

5 Esboço ( outline ) de todos os casos de e a definição inicial dos requisitos es do sistema. O objetivo desta fase é definir o escopo do projeto (Visão Inicial do e Plano de Gerenciamento de Riscos), verificar sua viabilidade, dimensionar o trabalho e elaborar uma arquitetura candidata Elaboração O número de iterações desta fase é diretamente proporcional à quantidade de casos de e aos riscos do projeto. Tipicamente serão definidas 1 ou 2 iterações. A proposta desta fase é eliminar os riscos do projeto e estabelecer uma arquitetura suficientemente estável que suporte a evolução do sistema. Os casos de de impacto arquitetural devem ser desenvolvidos nesta fase e o número de iterações a ser definido é proporcional à complexidade e ao número destes casos de. O RUP recomenda que ao final da Elaboração sejam refinados 80% dos casos de, mas esta não é uma determinação do TCU-DW e é uma decisão do gestor do projeto. A premissa básica é que exista equilíbrio das iterações, para que não existam iterações nem muito curtas nem muito prolongadas. Os principais objetivos da Fase de Elaboração são: Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento. Para a maioria dos projetos, ultrapassar essa marca também corresponde à transição de uma operação rápida e de baixo risco para uma operação de alto custo e alto risco com uma inércia organizacional freqüente. Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto. Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto. As atividades que compõem esta fase devem ser executadas para cada caso de previsto para ser desenvolvido durante a elaboração Construção Novamente o número de iterações está vinculado ao tamanho do projeto. Quanto maior o número de casos de a serem desenvolvidos nesta fase, maior o número de iterações. A maioria dos projetos deve ter duas iterações de Construção. A proposta desta fase é construir os casos de de tal forma que o desenvolvimento do sistema esteja finalizado ao final da fase. Os principais objetivos da Fase de Construção são: Minimizar os custos de desenvolvimento, otimizando recursos e evitando retrabalhos desnecessários. Atingir a qualidade adequada com rapidez e eficiência. Atingir as versões úteis (alfa, beta e outros releases de teste) com rapidez e eficiência.

6 Concluir a, o design, o desenvolvimento e o teste de todas as funcionalidades necessárias. Desenvolver de modo iterativo e incremental um produto completo que esteja pronto para a transição para a sua comunidade de usuários. Isso implica descrever os casos de restantes e outros requisitos, incrementar o projeto, concluir a implementação e testar o produto. Decidir se o produto, os locais e os usuários estão prontos para que o aplicativo seja implantado. Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento. Mesmo em projetos menores, normalmente há componentes que podem ser desenvolvidos um independente do outro, permitindo o paralelismo natural entre as equipes (se os recursos permitirem). O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas também aumenta a complexidade do gerenciamento de recursos e da sincronização dos fluxos de trabalho. Uma arquitetura sofisticada será essencial para atingir um paralelismo significativo. As atividades que compõem esta fase devem ser executadas para cada caso de previsto para ser desenvolvido durante a construção Transição A fase de Transição normalmente terá apenas uma iteração. Os eventuais problemas identificados durante o aceite devem, na maioria dos casos, ser resolvidos rapidamente dentro da mesma iteração. Se forem identificados problemas de tratamento demorado, deve ser definida outra iteração. A proposta desta fase é finalizar o desenvolvimento do sistema. Somente uma iteração é prevista para esta fase Os principais objetivos da Fase de Transição são: Teste beta para validar o novo sistema em confronto com as expectativas do usuário. Teste beta e operação paralela relativa a um sistema legado que está sendo substituído. Treinamento de usuários e equipe de manutenção. Atividades de ajuste, como correção de erros, melhoria no desempenho e na usabilidade. Avaliação das baselines de implantação tendo como base a visão completa e os critérios de aceitação para o produto. Obtenção de auto-suportabilidade do usuário. Obtenção do consentimento dos envolvidos de que as baselines de implantação estão completas. Obtenção do consentimento dos envolvidos de que as baselines de implantação são consistentes com os critérios de avaliação da visão.

7 5. FASE DE INICIAÇÃO 5.1. Diagrama de Atividades da fase de Iniciação iteração única

8 5.2. Tabela de Atividades da fase de Iniciação OBS : os produtos que não possuem template estao mencionados entre * ( ex: * ambiente de desenvolvimento * ). Entrada Atividade Descrição Responsável Participante Saída Normas e * autorização de início do projeto * Abre o O Gestor do deve solicitar, ao Gestor de Configuração de Software, a criação do ambiente de desenvolvimento que irá servir de apoio para o projeto. SGCS - solicitação de ambiente GCS Para tanto, deve gerar a SGCS - solicitação de ambiente GCS e encaminhá-la ao Gestor de Configuração de Software. SGCS - solicitação de ambiente GCS Prepara o Ambiente de Desenvolvi mento Com base no SGCS - solicitação de ambiente GCS, o Gestor de Configuração de Software deve: realizar o cadastramento do novo e do novo Sistema a ser desenvolvido na ferramenta para gerência de mudança, caso não tenham sido cadastrados; preparar o ambiente de desenvolvimento, criando as pastas de projeto e de sistema na ferramenta para gerência de configuração de ambiente. criar as bases nas ferramentas para gerência de requisitos, para gerência dos diagramas e modelos do sistema. Gestor de Configuração de Software * ambiente de desenvolvimento * * informativo * Após a conclusão destas tarefas, o Gestor de Configuração de Software deve responder à solicitação, informando ao Gestor do que o ambiente está configurado. Planeja a Iteração O Gestor do deve planejar todas as atividades referentes a esta iteração da Iniciação. Deve iniciar a elaboração do cronograma do projeto com estas atividades. O Gestor do deve identificar o projeto e as pessoas que dele participarão: a Equipe Técnica, o Usuário Gestor, o Representante do Usuário do Sistema, dentre outros. Ele deve elaborar uma versão preliminar do PT plano de trabalho que documente todas as informações já disponíveis acerca deste planejamento. Como essa é a primeira iteração, esta atividade é realizada dentro da própria iteração. Nas próximas iterações o planejamento é realizado ao final da iteração anterior. CR cronograma PT plano de trabalho

9 Entrada Atividade Descrição Responsável Participante Saída Normas e CR cronograma PT plano de trabalho Inicia a Iteração da Iniciação O Gestor do deve realizar reunião com a participação da Equipe Técnica e do Usuário Gestor. Nesta reunião, devem ser apresentados os objetivos da iteração, as responsabilidades dos envolvidos no projeto e as atividades que deverão ser executadas, conforme definidas no CR cronograma do. Além disto, o Gestor do também deverá apresentar a Equipe Técnica do projeto ao Usuário Gestor. Usuário Gestor Equipe Técnica Ata de reunião PT plano de trabalho CR cronograma O Gestor do deverá submeter a versão preliminar dos documentos PT plano de trabalho e CR cronograma do projeto, que contêm o planejamento da fase de Iniciação, à aprovação do Usuário Gestor. O Gestor do deve gerar a ata desta reunião.

10 Entrada Atividade Descrição Responsável Participante Saída Normas e * artefatos fornecidos pelo cliente * Analisa os Problemas e as Necessidades O Analista de Requisitos deve entender o problema do seu cliente e identificar os principais stakeholders e suas necessidades. Ele deve, sob orientação do Gestor do, elaborar o DV documento de visão do projeto. Para tanto, devem ser realizadas reuniões com o Representante dos Usuários do Sistema e com o Usuário Gestor, tendo por objetivo definir uma visão inicial do projeto de desenvolvimento. Essas entrevistas devem ser registradas no artefato EST entrevista stakeholders. Analista de Requisitos Usuário Gestor Representante dos Usuários do Sistema DV documento de visão GL glossário EST entrevista stakeholders Deve-se, nesta atividade: definir escopo e não escopo do projeto; definir os problemas a serem solucionados com o desenvolvimento do sistema de DW; delimitar o sistema, identificando, por exemplo, suas fronteiras com sistemas legados; definir os stakeholders e suas necessidades; definir as necessidades funcionais e as não funcionais dos usuários, suas prioridades, a solução atual e a solução prevista; Identificar restrições impostas ao sistema, tais como escopo da qualidade, precedência e prioridade, dentre outras. Todas estas definições devem ser registradas no DV documento de visão. Paralelamente à elaboração do DV documento de visão, o Analista de Requisitos deve identificar os termos específicos do negócio do cliente e registrá-los no artefato GL - glossário. O Gestor do deve aprovar o DV documento de visão e o GL - glossário e depois submetê-los ao Usuário Gestor para aprovação. Caso esse documento não seja aprovado, o Gestor do deve providenciar as alterações necessárias e submetê-lo novamente à aprovação do Usuário Gestor.

11 Entrada Atividade Descrição Responsável Participante Saída Normas e PT plano de trabalho Elabora Plano Inicial de Gestão de Riscos O Gestor do deve identificar, analisar e priorizar os riscos para o projeto, bem como determinar as estratégias que sejam mais adequadas para a correção e o gerenciamento destes riscos. Representante dos Usuários Usuário Gestor Equipe Técnica PGR plano de gestão de riscos Ao elaborar a versão inicial do PGR plano de gestão de riscos, ele deve focar nos riscos que podem afetar o sucesso do projeto de desenvolvimento. Para a identificação destes riscos deve-se levar em consideração as características já percebidas no contexto do projeto e que não estão documentadas, tais como características políticas, ambientais, econômicas, etc. Para isto, o Gestor do poderá solicitar, quando necessário, reuniões com os envolvidos no projeto: Representante dos Usuários do Sistema, Usuário Gestor e Equipe Técnica. O Gestor do também deve definir estratégias para controle e mitigação dos riscos identificados. Estas estratégias podem ser, por exemplo, para negociação de equipamentos, negociação com clientes externos ao TCU, aquisição de recursos ou componentes, etc. Atenção: somente as atividades de revisão deste PGR plano de gestão de riscos estão detalhadas no processo. As atividades de execução para tratar os riscos identificados deverão ser realizadas durante todo o ciclo de vida do projeto. DV documento de visão PT plano de trabalho Elabora o Plano de Desenvolvimento O Gestor do deve elaborar o artefato PD plano de desenvolvimento. Para tal, deve levar em consideração as características do projeto, a fim de decidir quais artefatos são necessários e serão produzidos no decorrer do projeto. Processo PD plano de desenvolvimento Caso haja divergência com o processo de desenvolvimento, no que se refere aos artefatos que serão produzidos, este artefato deve ser apresentado ao Gestor do Processo, que deverá avaliar e aprovar a adequação do projeto ao processo de desenvolvimento.

12 Entrada Atividade Descrição Responsável Participante Saída Normas e * artefatos fornecidos pelo cliente * DV - documento de visão EST - entrevista stakeholder GL - glossário Identifica os Requisitos O Analista de Requisitos deve identificar e documentar os requisitos do sistema: funcionais e não funcionais. Ele deve identificar os casos de que comporão os requisitos funcionais do sistema e, para cada um deles, deve gerar uma versão outline da ESP - caso de. Esta versão contém as principais informações necessárias para o usuário. Analista de Requisitos Representante dos Usuários do Sistema Usuário Gestor ESP - especificação de caso de MUC - modelo de caso de DW ES - especificação GL - glossário Norma para Elaboração da Especificaçã o de Caso de Análise DW O Analista de Requisitos deve elaborar o MUC - modelo de caso de DW, revisá-lo e reestruturá-lo com o objetivo de identificar informações comuns a mais de um caso de e identificar informações opcionais. A execução destas tarefas inclui identificar atores, identificar casos de, descrever a interação entre atores e casos de, elaborar MUC - modelo de caso de DW e elas devem ser realizadas a partir das características do projeto estabelecidas no DV - documento de visão e das informações prestadas pelo Representante dos Usuários do Sistema. O Analista de Requisitos também deve identificar os requisitos não funcionais do sistema e gerar a ES - especificação. Portanto, deve se basear nas características estabelecidas no DV - documento de visão, nas entrevistas registradas em EST - entrevista stakeholder e nas informações prestadas pelo Representante dos Usuários do Sistema. Durante a realização desta atividade, surgem vários conceitos relacionados ao projeto. Eles devem ser definidos, discutidos, e registrados, possibilitando eventuais consultas, no GL glossário. Os artefatos gerados devem ser submetidos ao Usuário Gestor para aprovação. Caso não haja aprovação, o Analista de Requisitos deverá providenciar as alterações necessárias e submetê-los novamente à aprovação.

13 Entrada Atividade Descrição Responsável Participante Saída Normas e DV documento de visão ES - especificação ESP - especificação de caso de MUC - modelo de caso de DW Atualiza Base de Requisitos Após a aprovação, pelo Usuário Gestor, dos artefatos que documentam os requisitos funcionais e os requisitos não funcionais (es), o Analista de Requisitos deve cadastrá-los na base de requisitos, mantendo as matrizes atualizadas e consistentes no artefato MAR - matriz de rastreabilidade. O analista de Requisitos deve coletar as informações necessárias sobre os requisitos a fim de cadastrá-las e/ou atualizá-las na base de requisitos. Analista de Requisitos Gestor de MAR - matriz de rastreabilidade DV - documento de visão ES - especificação MUC - modelo de caso de DW Define Arquitetura Física do DW Elaborar um documento da arquitetura do ambiente DW contendo itens que: indicam os pontos da arquitetura do projeto que são compatíveis com a norma; descrevem os pontos que não são compatíveis com a norma; descrevem os pontos da arquitetura de integração, quando for o caso. Arquiteto Administrador de Dados DAF - documento de arquitetura física do DW Norma para arquitetura de DW DAF - documento de arquitetura física do DW DV - documento de visão ES - especificação MUC - modelo de caso de DW Elabora o Plano de Teste O Analista de Teste deve planejar e comunicar ao Gestor do as intenções do esforço relacionado a testes. Ele deve, a partir das características do sistema definidas nos artefatos de entrada, identificar os testes que serão realizados no sistema e descrever as suas características, bem como todos os requisitos necessários para a execução destes testes. Estas definições devem ser registradas no PTE - Plano de Teste. O Gestor do deve ser ouvido sobre a priorização dos testes e, se necessário, também sobre o refinamento dos testes dos requisitos não funcionais. Analista de Teste PTE - plano de teste

14 Entrada Atividade Descrição Responsável Participante Saída Normas e DV - documento de visão ES - especificação ESP - especificação de caso de MUC - modelo de caso de DW PGR - plano de gestão de riscos Revisa o Plano de Gestão de Riscos Identificar, analisar e priorizar os riscos para o projeto e determinar as estratégias de gerenciamento de riscos mais adequadas. Ao revisar o PGR plano de gestão de riscos, o Gestor do deve focar nos riscos técnicos que podem afetar o sucesso do projeto de desenvolvimento. Para a identificação destes riscos deve-se levar em consideração as características do projeto que estão estabelecidas nos artefatos de entrada. Os riscos não técnicos também deverão ser revisados e registrados neste momento. Equipe Técnica PGR - plano de gestão de riscos Sempre que julgar necessário, o Gestor do poderá solicitar reuniões, junto à Equipe Técnica e demais envolvidos no projeto, para identificar possíveis riscos técnicos do projeto e definir as estratégias de controle e mitigação destes riscos. Somente as atividades de revisão deste plano estão detalhadas no processo. As atividades de execução relacionadas ao gerenciamento e à mitigação ou eliminação dos riscos deverão ser previstas e acompanhadas pelo Gestor de durante todo o ciclo de vida do projeto. Ele também deve definir o responsável por tais atividades de execução. PD - plano de desenvolvimento PT - plano de trabalho Realiza as Estimativas do Estimar o tamanho inicial do sistema e calcular o esforço necessário para implementá-lo. Estimar e documentar os recursos computacionais para o projeto. Estimar os custos do projeto, em termos de tamanho e esforço estimados e em termos dos demais custos operacionais do projeto. O Gestor do deve aplicar métrica, de acordo com uma técnica selecionada, para o dimensionamento do projeto de sistema. Equipe Técnica ETES - estimativa de tamanho e esforço de software MR - memória de recursos RCC - recursos computacionais críticos Para realização desta atividade é necessário, por exemplo: definir o tipo de projeto, selecionar as categorias profissionais necessárias, calcular a quantidade de horas por categoria profissional, calcular o custo baseado no tamanho e esforço do sistema, identificar os recursos computacionais críticos, analisar os recursos computacionais críticos, dentre outros. O Gestor do deve documentar as estimativas ao elaborar os artefatos de saída.

15 Entrada Atividade Descrição Responsável Participante Saída Normas e DV - documento de visão ES - especificação ESP - especificação de caso de ETES - estimativa de tamanho e esforço de software MR - memória de recursos MUC - modelo de caso de DW PGR - plano de gestão de riscos PT - plano de trabalho PD plano de desenvolvimento PTE - Plano de Teste CR cronograma RCC - recursos computacionais críticos DAF - documento de arquitetura física do DW Elabora o Plano de Trabalho e o Cronograma do O Gestor do, após reunir-se com toda Equipe Técnica, deve realizar o planejamento do projeto. Também deve atualizar o CR - cronograma do projeto contendo as atividades, os marcos, as responsabilidades e os produtos. Durante esse planejamento, deve-se: definir o escopo do projeto, negociando com o Usuário Gestor, com base na previsão feita nas estimativas para o sistema e o projeto; definir as Unidades/Empresas envolvidas no projeto; especificar o conteúdo técnico das iterações, apresentando a distribuição dos casos de nas mesmas; definir o número e os objetivos das iterações que deverão fazer parte das fases do projeto; definir, quando aplicável, planos de suporte à gestão do projeto de desenvolvimento. definir duração das fases, das iterações e das macro-atividades do projeto. definir os principais marcos do projeto. elaborar a WBS (EAP) do projeto e transferi-la para o cronograma; detalhar as atividades do cronograma e as dependências entre elas; identificar as restrições das atividades, definir responsabilidades e alocar recursos para elas; definir o cronograma das tarefas de teste e atualizar o PTE - Plano de Teste em conjunto com o Analista de Teste. documentar as suposições; refinar o CR - cronograma do, planejando todas as atividades referentes à próxima iteração; Usuário Gestor Representante dos Usuários do Sistema Processo de Desenvolvi - mento Equipe Técnica Analista de Teste PT - plano de trabalho PD plano de desenvolvimento CR - cronograma WBS - estrutura analítica do projeto (EAP) PTE - plano de teste Após a elaboração do PT - plano de trabalho, o Gestor de deve submetê-lo, juntamente com o Cronograma, à aprovação do Usuário Gestor. O artefato PD plano de desenvolvimento também deve ser atualizado e apresentado ao Gestor do Processo de Desenvolvimento que deverá avaliar e aprovar a adequação do projeto ao processo de desenvolvimento.

16 Entrada Atividade Descrição Responsável Participante Saída Normas e CR - cronograma DV - documento de visão PD - plano de desenvolvimento PGR - plano de gestão de riscos PT - plano de trabalho Avalia a Iteração O Gestor do deve efetuar a avaliação da iteração junto à sua equipe apresentando, discutindo e avaliando: os resultados obtidos frente ao planejado; os desvios ocorridos no decorrer da iteração e os motivos da ocorrência de tais desvios; as lições aprendidas; as providências a serem tomadas; Estas informações devem ser documentadas no artefato AI - avaliação da iteração e divulgadas para os servidores dos serviços de desenvolvimento de DW. Equipe Técnica AI - avaliação da iteração * itens de configuração * Gera Versão do O Gestor do deve gerar um label de todos os artefatos da iteração na ferramenta para Configuração de Ambiente, selecionando todas as versões dos documentos que se aplicam àquela iteração. Ele deve garantir que os subsistemas e componentes de software, quando atingirem o nível desejado de maturidade, sejam colocados sob uma baseline, e disponibilizados como padrão para quaisquer tipos de alteração que venham a acontecer, no contexto do projeto. Deve também garantir que os itens de configuração que estão sendo tratados na mudança sejam controlados. Nota: qualquer alteração a ser realizada em um item de configuração contido em um baseline deve ser previamente analisada e autorizada pelo Gestor do. * baseline *

17 6. FASE DE ELABORAÇÃO 6.1. Diagrama de Atividades da fase de Elaboração

18 6.2. Tabela de Atividades da fase de Elaboração OBS : os produtos que não possuem template estao mencionados entre * ( ex: * ambiente de desenvolvimento * ). CR - cronograma Inicia a Iteração O Gestor do deve realizar reunião com a Equipe Técnica. Durante esta reunião, devem ser apresentados os objetivos da iteração e as atividades que deverão ser executadas, e que estão definidas no CR - cronograma do projeto. Equipe Técnica Usuário Gestor Ata de reunião O Gestor do deve gerar a Ata de reunião e comunicar ao Usuário Gestor o início da iteração e seu cronograma. Solicita Planejamento dos Treinamentos O Gestor do deverá formalizar junto ao Elaborador de Treinamento a necessidade de iniciar o Planejamento dos Treinamentos. Elaborador de Treinamento * informativo * * informativo * Planeja os Treinamentos Caso seja verificada a necessidade, o Elaborador de Treinamento deve planejar os treinamentos a serem ministrados para os usuários do sistema, designando aqueles aos quais o ISC prestará apoio. Elaborador de Treinamento PTR plano de treinamento * informativo * O Elaborador de Treinamento deve comunicar ao Gestor do, via , a decisão tomada acerca do treinamento dos usuários. Essa atividade deve ser realizada somente na primeira iteração da fase de Elaboração. DV documento de visão ES especificação GL glossário caso de Refina os Requisitos O Analista de Requisitos deve definir a granularidade da tabela Fato no documento ESP caso de. Deve também detalhar os relatórios a serem produzidos no projeto produzindo o artefato RCA relatório de contexto de. Ele deve detalhar e refinar as regras de negócio, as dimensões e seus atributos, os fatos e seus atributos, e as medidas. Caso necessário, o artefato ES especificação deve ser refinado nessa atividade. Analista de Requisitos Usuário Gestor ES especificação GL glossário EST entrevista stakeholder caso de RCA relatório de contexto de Para tanto, o Analista de Requisitos deve realizar entrevistas com o Usuário Gestor

19 caso de Elabora o Modelo Lógico do DW O Analista de Requisitos deve identificar os atributos da tabelafato e das tabelas-dimensão e apresentar como a tabela-fato se relaciona com as tabelas-dimensão, construindo MLDW - modelo lógico do DW. Analista de Requisitos Administrador de Dados MLDW modelo lógico do DW O Analista de Requisitos pode solicitar o apoio do administrador de dados para elaborar o MLDW - modelo lógico do DW. ES especificação caso de MLDW modelo lógico do DW Valida a Especificação de Caso de Análise e o Modelo Lógico do DW O Analista de Requisitos deve apresentar a ESP - especificação de caso de para os arquitetos, os administradores de dados e os analistas de OLAP, ETL e testes. Os objetivos desta apresentação são: Avaliar a solução apresentada e identificar os pontos de difícil implementação, levantando alternativas de solução. Avaliar os pontos de integração da solução Analista de Requisitos Arquiteto Analista OLAP Analista ETL Analista de Teste Administrador de dados Ata de reunião O Analista de Requisitos deve formalizar em ata as decisões e realizar as alterações necessárias nos artefatos. caso de Aprova a Especificação de Caso de Análise com o Usuário O Analista de Requisitos deve submeter a ESP - especificação de caso de para aprovação do usuário gestor. Caso seja necessário, o Analista de Requisitos deve fazer as devidas alterações submetendo-as novamente ao usuário gestor. Analista de Requisitos Usuário Gestor caso de Deve manter a consistência entre os artefatos, atualizando os que forem necessários. ES especificação caso de MAR - matriz de rastreabilidade Atualiza a Base de Requisitos Após a aprovação pelo Usuário Gestor dos artefatos que documentam os requisitos es e os requisitos funcionais, o Analista de Requisitos deve cadastrá-los na base de requisitos. Ele deve manter a base de requisitos, garantindo que as matrizes estejam sempre atualizadas, coerentes e consistentes. Analista de Requisitos MAR - matriz de rastreabilidade DAF - documento de arquitetura física do DW ES especificação Revisa a Arquitetura do DW Com base nas especificações de caso de refinadas, o Arquiteto deve revisar a arquitetura do sistema, observando os padrões internos do Tribunal e as características do projeto. A Norma para arquitetura de DW apresenta todas as orientações necessárias para o estabelecimento da arquitetura dos sistemas Arquiteto Grupo de arquitetos DAF - documento de arquitetura física do DW Norma para arquitetura de DW

20 desenvolvidos no Tribunal. caso de No caso de mudança ou expansão da arquitetura de referência, tais alterações devem ser apresentadas ao grupo de arquitetos, que será responsável pela decisão de alteração ou não da arquitetura de referência. As mudanças ou expansões da arquitetura, particulares do projeto, que não forem incorporadas à norma devem ser referenciadas na Norma para arquitetura de DW. MLDW modelo lógico do DW Elabora Modelo Físico do DW O Administrador de Dados deve mapear as tabelas previstas no MLDW - modelo lógico do DW em um modelo físico a ser implementado no banco de dados do DW. Administrador de Dados MFD modelo físico do DW Ele deve, por exemplo, definir acerca das tabelas: chaves primárias e estrangeiras. índices. forma de implementação do relacionamento N x N entre tabelas MFD modelo físico do DW Implementa o Modelo Físico do DW O Administrador de Banco de Dados deve definir parâmetros necessários para a implementação do DW, tais como: tablespaces, blocagem de registros, dentre outros. Ele deve gerar e executar scripts que implementam o modelo físico do DW. Administrador de Banco de Dados * DW caso de MFD modelo físico do DW MUC - modelo de caso de do DW Mapeia os Contextos de Análise O Analista OLAP deve descrever o mapeamento das informações definidas na ESP caso de para os objetos do banco de dados do DW, a fim de disponibilizar tais informações para o usuário. Ele deve descrever as hierarquias entre os objetos das dimensões. Finalmente, deve gerar o MCA modelo dos. Analista OLAP MCA modelo dos MCA modelo dos * DW RIOLAP roteiro Implementa os Contextos de Análise O Analista OLAP deve criar os, conforme definido no MCA modelo dos, na ferramenta OLAP. Para tanto, ele importa as tabelas do banco de dados do DW e define os relacionamentos entre elas, cria campos de consulta Analista OLAP * contexto de RIOLAP roteiro de apoio à