Especificação de Processo Desenvolvimento de DW

Tamanho: px
Começar a partir da página:

Download "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 à

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL)

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Versão 2.0 Escritório de Gerenciamento de Projetos - EGP Superintendência da Gestão Técnica da Informação SGI Agência Nacional de Energia Elétrica

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Desenvolvimento de Software Prof. Alessandro J de Souza ajdsouza@cefetrn.br 1 Rational Unified Process RUP Fase Construção 2 VISÃO GERAL Fase Construção. Visão Geral 3

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

DESENVOLVIMENTO DE SISTEMAS

DESENVOLVIMENTO DE SISTEMAS Agência Nacional de Vigilância Sanitária METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS GGTIN GESIS Brasília, julho de 2006. Página: 1 Histórico de Revisões Data Versão Descrição Autor 12/06/2006 1.0.00 Criação

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS. Sumário CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO IV PROJETO BÁSICO: PROCESSO DE DESENVOLVIMENTO DE PROJETOS Sumário 1. DIRETRIZES PARA O PROCESSO DE DESENVOLVIMENTO DE PROJETOS DE APLICATIVOS...172 1.1. INTRODUÇÃO...172

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

Leia mais

MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO

MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO 1ª Edição 2012 MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO

Leia mais

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 VANT-EC-SAME Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 Histórico da Revisão Data Versão Descrição Autor 17/0/07 1.0 Versão Inicial Douglas Moura Confidencial VANT-EC-SAME, 2007

Leia mais

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida Arquitetura do Processo Unificado Tempo para um projeto típico Tempo para um projeto Complexo O tempo gasto nas fases iniciais aumentam Para cada fase consideramos A meta a ser atingida Workflows a executar

Leia mais

POLÍTICA ORGANIZACIONAL

POLÍTICA ORGANIZACIONAL POLÍTICA ORGANIZACIONAL PARA DESENVOLVIMENTO DE SOFTWARE NA DR TECH Data 01/03/2010 Responsável Doc ID Danielle Noronha PoliticaOrg_DR_V003 \\Naja\D\Gerenciamento\Política Localização Organizacional Versão

Leia mais

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0

PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Metodologia de Desenvolvimento de Sistemas (Versão 2.0)

Metodologia de Desenvolvimento de Sistemas (Versão 2.0) SERVIÇO PÚBLICO FEDERAL MINISTÉRIO DA INTEGRAÇÃO NACIONAL DEPARTAMENTO NACIONAL DE OBRAS CONTRA AS SECAS Metodologia de Desenvolvimento de Sistemas (Versão 2.0) 1 Sumário 1Introdução... 5 1.1 Objetivo...

Leia mais

ANEXO IA ÁREA COMPARTILHADA DE TECNOLOGIA DA INFORMAÇÃO ACTI

ANEXO IA ÁREA COMPARTILHADA DE TECNOLOGIA DA INFORMAÇÃO ACTI ANEXO IA ÁREA COMPARTILHADA DE TECNOLOGIA DA INFORMAÇÃO ACTI Metodologia e Acompanhamento dos Projetos ACTI MAPA Versão 5.1 Histórico da Revisão Data Versão Autor 06/11/2008 5.1.0 Versão inicial do documento.

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

Processo Unificado (RUP)

Processo Unificado (RUP) Fases do Desenvolvimento Processo Unificado (RUP) Ulf Bergmann ulf@ime.eb.br Domínio do Problema Objetos Objetos do do Mundo Mundo real real Modelo Semântico Domínio da Solução Aplicação Interface Serviços

Leia mais

PROJETO DE FÁBRICA DE SOFTWARE

PROJETO DE FÁBRICA DE SOFTWARE FACULDADE SETE DE SETEMBRO FASETE Departamento de Sistemas de Informação PROJETO DE FÁBRICA DE SOFTWARE Denise Xavier Fortes Paulo Afonso BA Agosto/2015 Sumário 1. INTRODUÇÃO... 3 2. PERFIS FUNCIONAIS...

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS VERSÃO 2.0 MDS 12/3/2013 2.0 1/79 SUMÁRIO 1. INTRODUÇÃO... 4 2. OBJETIVO... 4 3. TIPOS DE DEMANDA DE SISTEMA DA DET... 5 3.1 Novo Sistema... 5 3.2 Sustentação

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS Versão 1 MDS Metodologia de Desenvolvimento de Sistemas 1 Presidente INCRA Rolf Hackbart Diretor de Gestão Estratégica DE - INCRA Roberto Kiel Coordenador Geral

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Workshop de Teste de Software. Visão Geral. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br

Workshop de Teste de Software. Visão Geral. Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br Workshop de Teste de Software Visão Geral Emerson Rios emersonrios@riosoft.org.br www.emersonrios.eti.br 1 AGENDA DO CURSO Conceitos Básicos Documentação Processo Plano de Teste Caso de Teste BIBLIOGRAFIA

Leia mais

Metodologia de Desenvolvimento de Software (MDS) do DNIT

Metodologia de Desenvolvimento de Software (MDS) do DNIT Versão 1.02 Metodologia de Desenvolvimento de Software (MDS) do DNIT Projeto: FUB/DNIT Emissão: 08/06/2015 Arquivo: MDS DNIT v1.02 20150701a - revisado e formatado (2).doc 1/86 FICHA TÉCNICA Grupo de Trabalho

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Plano de Gerência de Configuração

Plano de Gerência de Configuração Plano de Gerência de Configuração Objetivo do Documento Introdução A aplicação deste plano garante a integridade de códigos-fonte e demais produtos dos sistemas do, permitindo o acompanhamento destes itens

Leia mais

Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo

Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo Plano de Projeto Projeto: Biblioteca Central da UFES Versão: 2.0 Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta a versão 2.0 do Plano de Projeto para o projeto de desenvolvimento

Leia mais

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no 1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified

Leia mais

Nome da Empresa. Plano de Desenvolvimento de Software. Versão <1.0>

Nome da Empresa. <Nome do Projeto> Plano de Desenvolvimento de Software. Versão <1.0> Nome da Empresa Plano de Desenvolvimento de Software Versão Histórico de Revisões Data Versão Descrição Autor 2/7 Índice Analítico 1. Objetivo

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 3 Planejamento e Aula 8 do Projeto Aula 08 do Projeto SUMÁRIO INTRODUÇÃO... 3 ACOMPANHAMENTO DO PROJETO... 3 1. do Progresso...

Leia mais

TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO

TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO DO ESTADO DE MATO GROSSO INSTRUÇÃO NORMATIVA STI Nº 01/2011 Versão: 01 Publicação: DJE nº de / /2011 Unidade Responsável: Coordenadoria de Tecnologia da Informação - CTI I FINALIDADE Instituir a Metodologia

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Teste de Software Apresentação

Teste de Software Apresentação Teste de Software Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Agenda Teste de Software VV&T e Defeitos de Software Inspeção de Software Teste

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

PPS - Processo de Proposta de Solução Versão 1.3.1

PPS - Processo de Proposta de Solução Versão 1.3.1 PPS - Processo de Proposta de Solução Versão 1.3.1 Banco Central do Brasil, 2015 Página 1 de 13 Índice 1. FLUXO DO PPS - PROCESSO DE PROPOSTA DE SOLUÇÃO... 3 2. SOBRE ESTE DOCUMENTO... 4 2.1 GUIA DE UTILIZAÇÃO...

Leia mais

ANEXO TÉCNICO IMPLANTAÇÃO DO SOFTWARE GEMCO ANYWHERE

ANEXO TÉCNICO IMPLANTAÇÃO DO SOFTWARE GEMCO ANYWHERE ANEXO TÉCNICO IMPLANTAÇÃO DO SOFTWARE GEMCO ANYWHERE A BEMATECH realizará as seguintes atividades: Instalação do banco de dados do sistema GEMCO ANYWHERE no servidor do CLIENTE; Treinamento de atualização

Leia mais

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO

ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO ITIL V3 (aula 2) AGENDA: GERENCIAMENTO DE MUDANÇA GERENCIAMENTO DE LIBERAÇÃO GERENCIAMENTO DE CONFIGURAÇÃO Gerência de Mudanças as Objetivos Minimizar o impacto de incidentes relacionados a mudanças sobre

Leia mais

Gerenciamento de Projeto

Gerenciamento de Projeto UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Projeto Engenharia de Software 2o. Semestre/ 2005

Leia mais

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0

Resumo do BABok 2.0 O Guia de Referência de Análise de Negócio Curso de Analista de Negócio 3.0 O que é BABok? O BABok 2.0, Corpo de Conhecimento de Análise de Negócios, é considerado como um Guia Referência de Práticas de Análise de Negócio. Este guia é publicado e mantido pelo IIBA. O guia BABok

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita Unified Process Sueleni Mendez Batista Orientadora: Dra. Elisa Hatsue Moriya Huzita Processo de Desenvolvimento de Software 8O processo de desenvolvimento de software é um conjunto de atividades e resultados

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

ANEXO II - Especificações Técnicas

ANEXO II - Especificações Técnicas ANEXO II - Especificações Técnicas Índice 1 CONTEXTUALIZAÇÃO DO ESCOPO... 24 1.1 OBJETIVO DESTE DOCUMENTO... 24 1.2 CARACTERÍSTICAS DAS SOLUÇÕES SAGER E SAAT... 24 1.3 COMPONENTES DO PROJETO PARA O DESENVOLVIMENTO

Leia mais

Orientações para o Planejamento e Realização do Projeto Final

Orientações para o Planejamento e Realização do Projeto Final Orientações para o Planejamento e Realização do Projeto Final Simone Diniz Junqueira Barbosa Versão: 1.0.4 Orientações para o Planejamento e Realização do Projeto Final Sumário 1 Introdução... 3 2 Projeto

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

Leia mais

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart.

Glossário Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Apresenta a definição dos termos, siglas e abreviações utilizadas no contexto do projeto Citsmart. Versão 1.6 15/08/2013 Visão Resumida Data Criação 15/08/2013 Versão Documento 1.6 Projeto Responsáveis

Leia mais

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

Leia mais

Especialização em Engenharia de Software e Banco de Dados

Especialização em Engenharia de Software e Banco de Dados Especialização em Engenharia de Software e Banco de Dados Disciplina: Engenharia de Software Tópico: Modelos de Ciclo de Vida Prof. Rodolfo Miranda de Barros rodolfo@uel.br Ciclo de Vida A Engenharia de

Leia mais

Processo de Desenvolvimento de Software da Empresa de Planejamento e Logística PDS EPL. Versão 1.0

Processo de Desenvolvimento de Software da Empresa de Planejamento e Logística PDS EPL. Versão 1.0 Processo de Desenvolvimento de Software da Empresa de Planejamento e Logística PDS EPL Versão 1.0 1 2 Diretor Presidente Bernardo José Figueiredo Gonçalves de Oliveira Diretoria Hederverton Andrade Santos

Leia mais

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como:

Referências internas são os artefatos usados para ajudar na elaboração do PT tais como: Plano de Teste (resumo do documento) I Introdução Identificador do Plano de Teste Esse campo deve especificar um identificador único para reconhecimento do Plano de Teste. Pode ser inclusive um código

Leia mais

Especificação de Processo Carga do DW

Especificação de Processo Carga do DW Especificação de Processo Carga do DW Versão 1.0 F:\SEINF\Sequap\Processos de Trabalho\Carga do DW\Carga do DW - v3.doc Histórico de Revisão Data Versão Descrição Autor 21/05/06 0.1 Elaboração do processo

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

RESOLUÇÃO - TCU Nº 247, de 7 de dezembro de 2011

RESOLUÇÃO - TCU Nº 247, de 7 de dezembro de 2011 RESOLUÇÃO - TCU Nº 247, de 7 de dezembro de 2011 Dispõe sobre a Política de Governança de Tecnologia da Informação do Tribunal de Contas da União (PGTI/TCU). O TRIBUNAL DE CONTAS DA UNIÃO, no uso de suas

Leia mais

Simulações em Aplicativos

Simulações em Aplicativos Simulações em Aplicativos Uso Avançado de Aplicativos Prof. Marco Pozam mpozam@gmail.com A U L A 0 4 Programação da Disciplina 20/Agosto: Conceito de Project Office. 27/Agosto: Tipos de Project Office.

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

O modelo unificado de processo. O Rational Unified Process, RUP.

O modelo unificado de processo. O Rational Unified Process, RUP. Cursos: Sistemas de Informação Disciplina: Administração ADM Prof. Jarbas Avaliação: Prova B1, 5º/6º semestres Data: 27/09/2010 Nome: Gabarito RA: Assinatura: Turma: 1) Segundo as afirmações a seguir,

Leia mais

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br

Teste de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Teste de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos Teste de software

Leia mais

Exame de Fundamentos da ITIL

Exame de Fundamentos da ITIL Exame de Fundamentos da ITIL Simulado B, versão 5.1 Múltipla escolha Instruções 1. Todas as 40 perguntas devem ser respondidas. 2. Todas as respostas devem ser assinaladas na grade de respostas fornecida.

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

CONHECIMENTOS ESPECÍFICOS

CONHECIMENTOS ESPECÍFICOS CONHECIMENTOS ESPECÍFICOS Acerca dos conceitos básicos de gerenciamento de projetos e considerando o PMBOK, julgue os itens a seguir. 51 No gerenciamento de um projeto, deve-se utilizar não apenas as ferramentas

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

Contrato de Serviço (SLA) para [Cliente] por [Provedor]

Contrato de Serviço (SLA) para [Cliente] por [Provedor] Contrato de Serviço (SLA) para [Cliente] por [Provedor] Data Gerador do documento: Gerente de Negociação: Versões Versão Data Revisão Autor Aprovação (Ao assinar abaixo, o cliente concorda com todos os

Leia mais

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES

Prova de Conhecimento para Consultores de Implementação MPS.BR INSTRUÇÕES Implementação MPS.BR 26 de maio de 2008 4 horas de duração e-mail: (DEIXAR EM BRANCO) RESULTADO: Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Nota INSTRUÇÕES Para a maioria das questões você tem mais de uma opção e

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Aula 2 Governança do projeto Papéis e Responsabilidades

Aula 2 Governança do projeto Papéis e Responsabilidades Aula 2 Governança do projeto Papéis e Responsabilidades Objetivos da Aula: Nesta aula, iremos conhecer os diversos papéis e responsabilidades das pessoas ou grupos de pessoas envolvidas na realização de

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 3. Gerência de

Leia mais

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Projetos Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Laboratório de Tecnologia de Software LTS www.ufpa.br/lts Rede Paraense de Pesquisa em Tecnologias de Informação

Leia mais

PODER JUDICIÁRIO TRIBUNAL REGIONAL DO TRABALHO DA 3ª REGIÃO

PODER JUDICIÁRIO TRIBUNAL REGIONAL DO TRABALHO DA 3ª REGIÃO Controle de Versões Autor da Solicitação: Subseção de Governança de TIC Email:dtic.governanca@trt3.jus.br Ramal: 7966 Versão Data Notas da Revisão 1 03.02.2015 Versão atualizada de acordo com os novos

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos GERÊNCIA DE INTEGRAÇÃO GERÊNCIA DO ESCOPO GERÊNCIA DO TEMPO GERÊNCIA DE CUSTO GERÊNCIA DA QUALIDADE Desenvolvimento do Plano

Leia mais

Empresa de Informática Infinity LTDA. Gerenciamento de Configuração. Sistema de Gerenciamento de Plano Corporativo de Celulares

Empresa de Informática Infinity LTDA. Gerenciamento de Configuração. Sistema de Gerenciamento de Plano Corporativo de Celulares Empresa de Informática Infinity LTDA Gerenciamento de Configuração Sistema de Gerenciamento de Plano Corporativo de Celulares 22/05/2012 Índice Analítico 1. Introdução 1.1 Finalidade 1.2 Escopo 1.3 Definições,

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira LEVANTAMENTO DE REQUISITOS Lílian Simão Oliveira Níveis de erros Fonte: imaster.com um software São as características e funcionalidades que um software tem Engenharia de Requisitos O que é? Quem faz?

Leia mais

Planejamento Iterativo

Planejamento Iterativo Planejamento Iterativo Planejando as Fases e Iterações Hermano Perrelli hermano@cin.ufpe.br 1 Revisando Processo iterativo Req A&P Imp I/T Imp Req A&P Imp I/T Imp Req A&P Imp I/T Imp Iteração 1 Iteração

Leia mais

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software

FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas. OpenUp. Arquitetura de software FIC Faculdade Integrada do Ceará Curso em tecnologia em analise e desenvolvimento de sistemas OpenUp Arquitetura de software Fortaleza/2010 OpenUP Alguns anos atrás, vários funcionários da IBM começaram

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Visão Geral do RUP Rational Unified Process. Jorge Fernandes UFRN Junho de 2002

Visão Geral do RUP Rational Unified Process. Jorge Fernandes UFRN Junho de 2002 Visão Geral do RUP Rational Unified Process Jorge Fernandes UFRN Junho de 2002 Resumo do Artigo de Krutchen O que é o RUP? 6 Práticas Comprovadamente Efetivas Desenvolvimento Interativo Gestão de Requisitos

Leia mais

Teste de Software. Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br

Teste de Software. Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br Rafael D. Ribeiro, M.Sc. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br Engenharia de Software Conceitos Básicos: Evolução Os primeiros anos (1950 a início dos 60) Aplicações científicas

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

Gerenciamento de Requisitos Gerenciamento de Requisitos

Gerenciamento de Requisitos Gerenciamento de Requisitos Gerenciamento de Requisitos Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS- Metodologia de Desenvolvimento e Manutenção de Sistemas da Superintendência de Tecnologia da Informação - STI Metodologia de Desenvolvimento e Manutenção de Sistemas da Histórico de Alterações Versão

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

24/04/2011 GERÊNCIA DO ESCOPO PMBOK GESTÃO DE PROJETOS NA PRÁTICA

24/04/2011 GERÊNCIA DO ESCOPO PMBOK GESTÃO DE PROJETOS NA PRÁTICA GESTÃO DE PROJETOS NA PRÁTICA Prof. Me. Luís Felipe Schilling "Escolha batalhas suficientemente grandes para importar, suficientemente pequenas para VENCER." Jonathan Kozol 1 No contexto do projeto, o

Leia mais

Projeto Final. APS Luiz Antônio M. Pereira

Projeto Final. APS Luiz Antônio M. Pereira APS Luiz Antônio M. Pereira Seminário: Agenda Objetivo do Projeto O Sistema A Equipe de Projeto Método de Trabalho Padrões para Documentação Próximos Passos Temas Batidos Dicas Desenvolvimento do projeto

Leia mais

Poder Judiciário. Justiça do Trabalho. Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO

Poder Judiciário. Justiça do Trabalho. Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO Poder Judiciário Justiça do Trabalho Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO DIVISÃO DE SISTEMAS E INTERNET METODOLOGIA DE PRODUÇÃO DE SOFTWARE Versão 1.0 APROVAÇÃO

Leia mais