Guia de Projeto - energia cria energia - Galp · Arquitetura – Guia de Projeto Geral DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 6 de 24 2 Normas, Standards e Melhores

Arquitetura – Guia de Projeto Geral

DSI/DIS – Desenho e Implementação de Soluções COPYRIGHT 2016 Galp 1 de 24


Data da Publicação: Janeiro 2017

Versão: 4.6


DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 2 de 24

Controlo de Versões

Controlo de Versões

Quadro 1 - Controlo de Versões

Direitos Autorais

Documento inédito com todos os direitos reservados. A inscrição “COPYRIGHT © 2016 Galp” foi

atribuída a este documento para, em caso de publicação acidental, proteger os direitos da Galp.

Nenhuma parte deste documento pode ser reproduzida sob qualquer forma, inclusive fotocópia ou

transmissão eletrónica para qualquer computador, sem o prévio consentimento escrito da Galp.

Confidencialidade

As informações contidas neste documento são confidenciais e da propriedade exclusiva da Galp, não

podendo ser utilizadas, divulgadas, ou cedidas a terceiras partes, sem o prévio consentimento escrito da

Galp.

Versão Descrição Data Responsável

V0.1 Criação de documento 19-11-2010 Rui Miguel (DSI)

V1 Criação de documento 23-12-2012 Rui Miguel

(DSI)

V2 Revisão 23-05-2012 Rui Miguel

(DSI)

V2.1 Inclusão de identificação

de log por parte do TIBCO\BC

20-06-2012 Rui Miguel (DSI)

V2.2 Alteração referente à

obtenção do PIARQT012 23-08-2012 Rui Ventura

(DSI)

V2.3 Ajustes decorrentes da

alteração do PIGEND06 - Guia de Projeto - TIBCO

11-01-2013 Rui Miguel

(DSI)

V3.0 Inclusão de plataforma SAP

08-03-2013 Rui Miguel (DSI)

V4.0 Inclusão de platafforma

OBIEE 26-04-2013 Rui Miguel

(DSI)

V4.1

Adaptação ao novo acordo ortográfico e

alteração da designação do PIGENT005

08-05-2013 Rui Ventura (DSI)

V4.2 Actualização 08-04-2016 Filipe Rosa

(DSI)

V4.3 Adição do documento PIGENT023

09-08-2016 Rui Ventura (DSI)

V.4.4 Adicionar Plataforma

Fiori 29-08-2016 Rui Ventura

(DSI)

V4.5 Atualizações 21-12-2016 Rui Ventura

(DSI)

V4.6 Atualização de

documento 31-01-2017

Rui Miguel

(DSI)





Índice

1 INTRODUÇÃO ........................................................................................................................................ 5 1.1 INTRODUÇÃO E OBJETIVO DO DOCUMENTO ......................................................................................... 5 2 NORMAS, STANDARDS E MELHORES PRÁTICAS ...................................................................................... 6 2.1 NORMAS E STANDARDS EM VIGOR ...................................................................................................... 6 3 ARQUITETURA TÉCNICA - AMBIENTES ..................................................................................................... 9 3.1 PROJETO ........................................................................................................................................ 11 3.2 DESENVOLVIMENTO ......................................................................................................................... 11 3.3 QUALIDADE ..................................................................................................................................... 11 3.4 FORMAÇÃO ..................................................................................................................................... 12 3.5 PRÉ-PRODUÇÃO ............................................................................................................................. 12 3.6 PRODUÇÃO ..................................................................................................................................... 13 3.7 MANUTENÇÃO ................................................................................................................................. 13 4 DOCUMENTAÇÃO DO PROJETO ............................................................................................................ 13 5 DOCUMENTAÇÃO COMPLEMENTAR ....................................................................................................... 24



1 Introdução

1.1 Introdução e Objetivo do Documento

Este documento tem como propósito efetuar o enquadramento às equipas aplicacionais (equipas de

projeto e equipas de manutenção) sobre as regras e as normas a serem seguidas ao nível das

plataformas aplicacionais existentes ou a implementar no Grupo Galp Energia.

A definição de regras e normas no âmbito da intervenção aplicacional visa garantir a sistematização e

atualização do conhecimento bem como garantir a utilização mais eficaz e eficiente das plataformas

Aplicacionais do Grupo.

Nesse sentido este documento aborda as seguintes temáticas:

Ciclo de vida de projeto.

Normas, Standards e Melhores Práticas.

Documentação do Projeto.

Ambientes de trabalho.

Modelos de Referência Galp.

Dependendo do grau de especificidade da plataforma e do seu grau de maturidade na Galp poderá

haver para a mesma documentação mais detalhada que não se encontra referenciada neste

documento. Nesses casos este documento identifica as plataformas e a localização da respectiva

documentação que poderá abranger qualquer dos pontos anteriormente referenciados.



2 Normas, Standards e Melhores Práticas

No sentido de garantir a eficiência e eficácia dos recursos utilizados estão definidas normas,

standards e melhores práticas que qualquer equipa, de projeto ou de manutenção, têm de seguir.

É responsabilidade das equipas garantirem que se mantêm atualizadas sobre evoluções introduzidas

pela Galp e pelos fornecedores das plataformas de software que utilizam.

Caso não existam normas Galp publicadas, os projetos são responsáveis por contactar a Área de

Arquitetura no sentido de definir, antes do desenho e implementação das soluções, a metodologia a

seguir, a qual poderá passar por:

Utilizar toda ou parte de uma metodologia em vigor para determinada plataforma.

Utilizar práticas em vigor, mas não documentadas, por parte do Outsourcer.

Utilizar metodologia e melhores práticas por parte do fornecedor de software.

Definir uma abordagem baseada nos 3 pontos anteriores.

Se em alguma situação for identificada uma diretiva Galp que esteja em discordância com o

preconizado pelo fornecedor da plataforma aplicacional, tal situação deverá ser formalmente

comunicada à equipa de Arquitetura no sentido de produzir respetivo parecer.

No que respeita à documentação a ser elaborada, a Galp elaborou a sua estratégia no sentido de

orientar a mesma para que:

Esteja o mais possível mais orientada ao processo de negócio.

Facilite a consolidação e atualização da informação na knowledge base da Galp.

Seja fácil de utilizar e atualizar pelas equipas de manutenção e pelas equipas de projeto.

O não cumprimento destas orientações poderá resultar na não aceitação do trabalho efetuado.

2.1 Normas e Standards em vigor

Os documentos que suportam as normas e regras transversais a qualquer plataforma encontram-se

disponíveis no site “Arquitetura e Análise Funcional”.

Estes documentos estão disponíveis no site “Arquitetura e Análise Funcional” em:

“01 Guias e Normas » 02. Arquitetura » 00. Regras Transversais

Os documentos disponibilizados cobrem as seguintes áreas:

Metodologia de testes, explica a metodologia de testes a ser usada pelos projetos de forma a

cobrir os vários tipos de testes a serem efetuados, antes de passagem a produção das

funcionalidades.



o PIQASD001 - Metodologia e Procedimentos de Testes

Em face da importância que a componente de testes tem para o sucesso dos projetos,

no sentido de reduzir os riscos de inconformidade da solução desenvolvido face aos

requisitos do negócio, foi definida uma metodologia de abordagem ao teste, baseado no

modelo V-Model.

O documento apresenta o modelo e a forma como as diferentes fases de teste se

encontram associadas às diferentes atividades do ciclo de vida de desenvolvimento de

aplicações.

Para cada fase de teste são identificados os aspetos que deverão ser validados e

monitorizados, em que ambientes é que os testes devem ser efetuados, em que fases

devem ser efetuados os planeamentos dos testes e quando é que estes devem ser

executados.

O documento identifica os diferentes modelos de intervenção da equipa de Qualidade e

Testes e os procedimentos inerentes à execução dos testes e interação com esta

equipa.

Monitorização:

o PIARQD020 - Cockpit de Monitorização, explica o funcionamento do processo de

logging e gestão de erros na plataforma de logging transversal. Nesta pasta estão

disponíveis os seguintes documentos:

PIARQD020_A – Cockpit de Monitorização – Manual de Utilizador: Como

utilizar o Cockpit de Integração, do ponto de vista do utilizador (Gestão de

acessos, parametrização de serviços, fluxos, processos, passagens entre

ambientes, etc.);

o Error Handling, estabelece as regras a serem seguidas no que respeita ao registo e

tratamento de erros, de forma transversal aos vários sistemas, bem como as guidelines

para a correta utilização deste serviço

o PIARQD018 - Códigos de Erro Comuns, identifica os códigos autorizados a usar para

efeitos de logging na plataforma de monitorização.

Business Activity Monitoring:

o PIARQD030 – BAM – Context, Identifica os objetivos e respetivo contexto subjacente à

utilização das ferramentas de BAM.

o PIARQD031 – BAM Quick Development Overview, explica como efetuar

desenvolvimentos no sentido de BAMizar os fluxos e processos.

o PIARQD032 – BAM – Demo – Cockpit Tempo Real, apresenta alguns dos écrans

disponibilizados na ferramenta BAM – Cockpit Tempo Real

No sentido de garantir uma uniformização da documentação que seja independente da plataforma

estão definidos um conjunto de templates para a implementação de novas funcionalidades (quando



são evoluções às funcionalidades existentes dever-se-á usar\atualizar a documentação existente). Os

templates disponibilizados são:

PIGENT004 – Análise de Gap’s, documento para identificação dos gap’s entre a funcionalidade

existente e os requisitos.

PAF002 – Requisitos, documento que identifica os requisitos a serem cobertos quer eles sejam

requisitos, funcionais, técnicos, performance, segurança, etc.

PIGENT011 e PIGENT012, Desenho Técnico Alto Nível, documento de desenho alto nível das

funcionalidades

PIARQT011 – Checklist de Projeto, documento de controlo da documentação a ser

produzida/atualizada pelo projeto. É com base neste documento que a:

Arquitetura:

Efetua o controlo dos objetos a que o projeto tem acesso, da documentação do projeto,

coerência dos dados apresentados no documento de métricas.

Equipas de Manutenção Aplicacional:

Dão acesso a sources e validam os objetos que estão autorizados passarem de ambiente.

PIARQT012 – Tempos de Execução, para os objetos que fazem uso da vertente de logging,

este documento permite avaliar, se os mesmos foram alvo de teste pelo projeto, os respetivos

tempos de execução, o número e tipo de erros gerados, etc..

Este documento é gerado automaticamente pela Arquitetura, após o preenchimento por parte do

projeto da folha de Integração-Métricas (PIARQT012) incluída no PIARQT011 – Checklist de

Projeto.

PIGENTx22 – Checklist de Deploy. Documento a ser usado para garantir o deploy correto dos

objetos alvo de migração de ambiente. Para as situações mais complexas este documento serve

também para definir tempos de execução de cada tarefa e aferir se o tempo previsto de deploy

está a decorrer dentro dos prazos estabelecidos ou não.

PIQAST001 – Plano de Abordagem ao Teste, Documento a ser usado em situações em que os

testes são mais complexos e em que é necessário garantir um conjunto de requisitos antes de

iniciar os mesmos.

PIQAST003 – Plano de Testes, Documento que identifica os casos de teste a serem efetuados

tal como definido ao nível da metodologia de testes da Galp (testes unitários, testes funcionais,

testes de performance/carga, testes técnicos).

PIQAST004 – TEC, Documento usado quando há intervenção da equipa de Qualidade e Testes

na execução de testes. Este documento serve para definir as condições para que a solução seja

aceita pra teste por parte desta Equipa. Este documento deve servir de suporte à reunião em

que a equipa de projeto demonstra que os casos de teste previamente acordados estão dentro

dos KPI’s definidos.

PIGENT023 – Project Release Mgmt, Documento que identifica as releases para Produção



que o projeto tem planeadas, estas releases dividem-se em Major Releases e Minor Releases.

As Major Releases são consideradas as passagens das componentes principais do projeto

(normalmente o go-live), as passagens a subsequentes, sejam para complementar o primeiro

deploy com novas funcionalidades, ou para efetuar correções a erros detetados, devem ser

enquadradas em minor project releases. Quando, e por razões unicamente relacionadas com

correções de funcionalidades em produção, ou de execução de data repairs, for necessário

efetuar um deploy fora do plano estabelecido, está será considerada uma Emergency Project

Release. Estas releases tem um processo de aprovação associado.

Change Order, documento a ser preenchido no sentido de preparar a aprovação para promoção

de ambiente, em especial para qualidade consolidada e produção. Este documento deve ser

disponibilizado com pelo menos 15 dias de antecedência à execução das operações. No

entanto, este tempo deverá ser previamente acordado entre o projeto e o Outsourcer.

A documentação específica associada a cada plataforma está disponível no site “Arquitetura

e Análise Funcional” em:

“01 Guias e Normas » 02. Arquitetura» [plataforma]

Em que [plataforma] corresponde à respetiva plataforma aplicacional

Para o desenvolvimento numa plataforma específica deverá ser consultada a documentação

específica de forma a garantir o cumprimento das normas e regras definidas.

As plataformas para as quais existe documentação específica são:

Tibco

Siebel

SAP PI

ETL

3 Arquitetura Técnica - Ambientes

O landscape da Galp poderá ter associado diversos ambientes, sendo que o mais normal é haver

ambiente de desenvolvimento, ambiente de qualidade e ambiente de produção (identificados na

figura abaixo pelas caixas laranja).

As setas azuis, da figura, representam os processos de passagem de ambiente que normalmente são

seguidos.



Os ambientes podem diferir conforme a plataforma, qualquer dúvida sobre quais os

ambientes disponíveis, deverá ser consultada a documentação específica de forma a garantir

o cumprimento das normas e regras definidas.



3.1 Projeto

Há situações (ex.: plataforma TIBCO) em que os desenvolvimentos são efetuados pelas equipas nas

suas próprias máquinas (PC’s\Laptop’s, etc.). Para estas situações a Galp, disponibilizará, sempre

que seja necessário o software licenciado por esta, às equipas de projeto, sendo responsabilidade

destas a respetiva instalação.

Caso existe este ambiente, o mesmo servirá para a execução dos desenvolvimentos e realização dos

testes unitários.

Poderá haver situações (ex.: Utilização da plataforma transversal de logging) em que já nesta fase

sejam dadas permissões às equipas para utilização de algumas componentes do ambiente de

desenvolvimento.

Todas as sources e bibliotecas serão, preferencialmente, disponibilizadas via ferramenta TFS (Team

Foundation Server) da Microsoft.

3.2 Desenvolvimento

Por norma, no início do projeto será atribuído um ambiente de desenvolvimento à equipa de projeto

com as permissões necessárias à sua utilização.

Qualquer software adicional ao disponibilizado, que seja necessário ao projeto, deverá ser

identificado e solicitado à Galp com a devida antecedência. A instalação do mesmo é da

responsabilidade da Galp.

Necessidades de alterações às parametrizações base do software deverão ser solicitadas à Galp que

avaliará os impactos da solicitação e respetiva alteração.

O ambiente de desenvolvimento será configurado com os serviços transversais necessários ao

projeto de modo a que possam ser “vistos” e usados de forma standard pela equipa de projeto.

Caso não exista ambiente de projeto, será neste ambiente que as equipas efetuarão os respetivos

desenvolvimentos e testes unitários.

Deverá ser também neste ambiente que deverão ser feitos os testes básicos com outras plataformas

(testes de conectividade, testes simples de integração).

3.3 Qualidade

O ambiente de qualidade disponibilizado tenta refletir, tanto quanto possível, a arquitetura técnica e

respetiva infraestrutura de servidores de produção.

É o primeiro ambiente onde as questões de cariz de infraestrutura (rede, clusters, switches,

balanceamento de carga, etc.) se encontram pela primeira vez disponíveis às equipas de

desenvolvimento, permitindo a estas conduzirem ciclos e condições de teste específicos (por exemplo

testes de performance aplicacional ou testes de exceção/falha de um dos servidores em

balanceamento de carga) que no ambiente de desenvolvimento tipicamente não são controladas.

A colocação das componentes desenvolvidas no âmbito do projeto neste ambiente é da



responsabilidade da equipa de projeto, com a supervisão da equipa de manutenção. De qualquer

forma, as componentes só deverão passar para qualidade após a realização dos testes que garantam

que a funcionalidade implementada corresponde a todas as especificações efetuadas.

O acompanhamento por parte da equipa de manutenção, tem como objetivo validar o plano de

instalação fornecido, previamente, pela equipa de projeto.

Após a instalação do “projeto” neste ambiente, a garantia de funcionamento (levantar e baixar

serviços) dos serviços é da responsabilidade da equipa de manutenção com o apoio da equipa de

projeto.

Adicionalmente, é o ambiente onde as soluções desenvolvidas são testadas de forma integrada com

uma garantia mínima de controlo sobre as alterações a componentes que, tipicamente, num ambiente

de desenvolvimento, se encontram sujeitos a um maior número de atualizações.

Neste ambiente e antes de se proceder aos testes de aceitação por parte dos utilizadores deverá ser

garantido a realização dos vários tipos de testes constantes no documento “PIQASD001 –

Metodologia de Testes”.

Este ambiente poderá estar dividido em 2:

Qualidade isolada:

As funcionalidades ainda não se encontram “compiladas” com as restantes funções do

sistema, permitindo uma maior autonomia da equipa de projeto de inclusão de correções aos

desenvolvimentos efetuados.

Nesta fase deverão ser executados todos os testes de cariz funcional, técnico e de integração

Qualidade consolidada:

As funcionalidades são “compiladas” com as restantes funcionalidades da plataforma, tal

como as mesmas irão para produção.

Neste ambiente devem ser efetuados testes de aceitação, de carga e performance.

3.4 Formação


responsabilidade da equipa de manutenção com o apoio da equipa de projeto.

Este ambiente tem como objetivo possibilitar a disponibilização de um ambiente em que os

utilizadores possam simular as funcionalidades existentes em produção sem preocupações de alterar

informação de negócio. Este ambiente destina-se em primeiro lugar à formação dos operadores de

Contact-Center.

3.5 Pré-Produção

Usado para realização de testes finais da solução que irá entrar em produção. Aquando da existência

do mesmo a responsabilidade de instalação dos objetos é da responsabilidade da equipa de

manutenção, sendo que a equipa de projeto deverá dar o respetivo apoio.



O controlo da realização dos testes é da responsabilidade da equipa de manutenção, sendo que a

execução dos mesmos é da responsabilidade da equipa de projeto.

3.6 Produção


responsabilidade da equipa de manutenção com o apoio da equipa de projeto. O mesmo só poderá

ser efetuado com a prévia autorização da Área de Arquitetura.

Para isso toda a documentação terá que estar entregue e validada e terão que ser apresentadas

evidências dos vários tipos de testes efetuados (integração, técnicos, funcionais, aceitação, carga).

Aquando da passagem a produção, a equipa de projeto deverá efetuar o acompanhamento durante

um período mínimo de 15 dias, sendo que neste período deverá ser garantido que todas as

funcionalidades implementadas/alteradas foram alvo de utilização. O acompanhamento por parte da

equipa de projeto, tem como objetivos garantir a correta instalação das componentes desenvolvidas,

assegurar que todas as componentes estão a funcionar corretamente e assegurar a passagem do

know-how para a equipa de manutenção.

Após o período de transição a equipa de manutenção será, ao nível aplicacional, a entidade

responsável pela operacionalidade das componentes que foram desenvolvidas no âmbito do projeto.

No entanto, qualquer situação em que se verifique a existência de erros decorrentes de uma falha de

implementação e caso esteja a decorrer o período de garantia, a responsabilidade pela correção do

erro é da responsabilidade da equipa de projeto.

3.7 Manutenção

Ambiente onde o Outsourcer usa para efetuar manutenções evolutivas/corretivas. Em algumas

situações, se este ambiente não existir, o outsourcer poderá ter acesso ou a um ambiente de

desenvolvimento ou a um ambiente de projeto próprio.

4 Documentação do Projeto

As equipas não poderão assumir a aceitação tácita da documentação apresentada em caso de

não resposta por parte da Área de Arquitetura Aplicacional. Sempre que haja atraso na resposta, é

da responsabilidade das equipas alertar os responsáveis do projeto, por parte da Galp, para a obtenção

das aprovações necessárias.

A documentação a ser produzida deverá ser desenvolvida numa ótica de processo. Isto é, em vez de

haver um documento por projeto, o projeto deverá acordar com a Área de Arquitetura da DSI os

documentos que deverão ser desagregados por processo. Esta desagregação deverá seguir a

identificação de processos que se encontram definidos no PAF003 – Documento de Análise Funcional.

O mapeamento dos processos integrados no PAF003 – Documento de Análise Funcional, devem ser

efetuados na ferramenta Bizagi (existente nos utilitários do site da Arquitetura). Em caso de

adequação/modificação de mapeamentos de processos já existentes, as equipas de projeto devem

solicitar o desenho de processo existente em iBPMS ou Bizagi, e criar as novas versões na ferramenta



Bizagi sob a norma BPMN2.0.

A documentação a ser avaliada pela Área de Arquitetura da DSI, deverá ser disponibilizada no site de

Arquitetura, devendo para tal, ser solicitada a criação da pasta de projeto respetiva.

Apresenta-se de seguida a matriz com os templates/tipo de documentos transversais a serem

produzidos. Os templates transversais são os documentos que deverão ser criados\atualizados por cada

projeto, independentemente da(s) plataforma(s) usada(s).

Nos casos das plataformas com modelos de Governance específicos, a matriz abaixo é complementada

com a matriz específica da plataforma.

Os templates transversais estão disponíveis no site “Arquitetura e Análise Funcional” em:

“01. Guias e Normas » 99. Templates » 00. Transversais

Os templates específicos de cada plataforma estão disponíveis no site “Arquitetura e Análise

Funcional” em:

“01. Guias e Normas » 99. Templates » [plataforma]

Em que [plataforma] corresponde à plataforma aplicacional.

As plataformas para as quais existe documentação e templates específicos são:

Tibco

Siebel

SAP PI

ETL

StreamServe

SAP

OBIEE

Fiori

De acordo com as fases definidas para a realização de um projeto de SI na Galp, apresenta-se a

documentação que deverá ser elaborada/atualizada em cada fase:


DSI/DIS – Desenho e Implementação de Soluções COPYRIGHT 2016 Galp 15 de 24


DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 16 de 24

Apresenta-se por cada uma das plataformas, em maior detalhe, a documentação que deverá ser produzida/atualizada.

Documentação Siebel StreamServ SAP PI SAP TIBCO ETL OBIEE FIORI Outras

Documentação Genérica

Checklist Projecto (PIARQT011)

Requisitos Técnicos (PAF002)

Análise de Gap's (PIGENT004)

Desenho Funcional (PAF003 + BPDs Bizagi)

Desenho Técnico Alto Nível (PIGENT011) PIGENT311 PIGENT611

Plano de abordagem ao teste (PIQAST001)

Plano de testes (PIQAST003)

Change Order – Passagem a Produção

Métricas de Projecto - Integração (PIARQT012)

Métricas Plataforma (Relatório BAM – Analítico) PIARQT351 PIARQT651 PIARQT712

Desenho Técnico (PIGENT012) PIGENT312 PIGENT612 PIGENT412

Project Release Mgmt (PIGENT023)

Modelo de Entidades (PIARQT313) * PIARQT313BI

Mapeamento de dados (PIGENT016)

PIGENT216M

Desenho Técnico Objeto PIARQT319 PIGENT619 PIGENT119 PIGENT219 PIGENT019 PIGENT419 PIGENT719 PIGENT219M

Desenho Técnico Interface PIARQT319UI

PIGENT119 PIGENT219 PIGENT018 PIGENT419 PIGENT719UI PIGENT219MUI

Regras SQL de EH (PIGENT020)

Inventário de Erros_Avisos_Monitorização PIGENT315 PIGENT615 PIGENT115 PIGENT215 PIGENT015 PIGENT415 PIGENT315

Checklist de Deploy (PIGENT022) PIGENT622

Deployment PIGENT313 PIGENT613 PIGENT113 PIGENT013 PIGENT413 PIGENT713

Manual de Exploração PIGENT326 PIGENT626

PIGENT726



Documentação Siebel StreamServe SAP PI SAP TIBCO ETL OBIEE FIORI Outras

Documentação Específica

Document Server Template (PIARQT320)

Desenho Documento e Definições de Publicação (PIGENT640)

Communication Channels (PIGENT120)

Regras SQL do Routing (PIGENT021)

Regras de Filtragem (PIGENT025)

Regras Hawk - Dominio (PIGENT017)

BAM – Deploy RTView (PIARQD614)

BAM – Deploy Business Events (PIARQD615)

BAM – Deploy Spotfire (PIARQD616)

BAM – Sondas (PIARQT020)

Gestão de Perfis (PIGENT716)

Fiori - Perfis de acessos (PIGENT716 SAP M)


DSI - Arquitectura & Standards COPYRIGHT 2011 Galp Energia, SA 18 de 24

PIARQT011 – CHECKLIST DE PROJETO

Este documento tem como objetivo:

Identificar os objetos a serem utilizados pelo projeto.

Possibilitar a verificação de eventuais conflitos com outros projetos.

Controlo dos objetos a serem disponibilizados pela equipa de manutenção ao projeto.

Controlo dos objeto que o projeto está autorizado a solicitar pedidos de promoção de ambiente.

Controlo sobre o estado de aprovação da documentação do projeto.

Identificação das datas em que o projeto pretende utilizar os vários ambientes.

Controlo dos projetos na promoção de ambientes

Do mesmo consta:

Documentos a serem produzidos.

Os objeto a criar, alterar e/ou usar, com a respetiva caracterização.

Relações entre objetos.

No início do projeto este documento é preenchido pela equipa de projeto com os objetos que pretende criar,

alterar ou utilizar. Após a entrega deste documento o mesmo será mantido pela equipa de Arquitetura

Aplicacional e equipa de Manutenção numa pasta, em que o projeto só terá acesso em modo de consulta.

Após entrega inicial por parte do projeto o documento será a base para:

Aprovação dos nomes dos objetos a serem usados pelo projeto.

Identificação de eventuais conflitos com outros projetos em termos da utilização dos mesmos recursos.

Caso tal aconteça haverá que definir um processo de mitigação.

Disponibilização por parte da equipa de manutenção dos objetos ao projeto.

Controlo por parte da equipa de manutenção dos objetos para os quais o projeto tem autorização para

solicitar pedidos de promoção de ambiente.

Verificação do status de aprovação da documentação do projeto.

Neste documento deverão estar também identificadas as entradas no log por parte do BC. Isto

deverá ser efetuado na folha para registo dos serviços\interfaces do TIBCO



PIGENT004 – ANÁLISE DE GAP’S

Este documento sistematiza os Gap´s entre a situação atual e a situação desejada com a implementação do

projeto, identificando as ações a executar para colmatar os mesmos.

O documento encontra-se dividido em Gap’s do tipo:

Funcionais.

Técnicos.

Segurança.

Outros (Adicionais).

Os Gap’s identificados deverão estar claramente associados aos requisitos do projeto, os quais deverão

estar sistematizados no documento “PIGENT005 – Requisitos Técnicos”.

PAF002 – REQUISITOS

O PAF002 tem um papel central uma vez que permite (1) sistematizar todos os requisitos, sejam eles

funcionais, técnicos, seguranças, etc., (2) facilitar a comparação das respostas por parte dos fornecedores,

(3) acompanhar eventuais alterações ao longo do projeto, (4) garantir o alinhamento da documentação

funcional e técnica, (5) base de referência para a elaboração/validação dos cadernos de teste.

Com a maior sistematização que está a ser colocada sobre a abordagem à qualidade dos testes, este

documento é um dos principais input’s (1) para carregamento da informação na ferramenta de testes e (2),

entre outras situações, associado à intervenção da equipa de Qualidade e Testes (sempre que tal é

definido), para verificar se os casos de testes elaborados cobrem os requisitos e suportar a elaboração de

testes de regressão.

PAF003 - DESENHO FUNCIONAL

Este documento identifica ao nível funcional e numa ótica de negócio o processo subjacente ao que se

pretende implementar. Em muitas das situações e apaesar se ao nível técnico só se intervir numa das suas

componentes, este documento deve dar um enquadramento end-to-end do referido processo.

No PAF003 dever-se-á ter especial atenção para que:

Só tenha a especificação de um único processo

O diagrama reflita corretamente o processo e que o mesmo esteja definido no iBPMs ou no Bizagi

Este documento deverá, tanto quanto possível, ser independente das plataformas aplicacionais em

que a solução técnica vai ser implementadas. Ie. Não deve ter diagramas técnicos nem especificações

técnicas.



Dever-se-á ter em atenção que na descrição do processo e numa perspectiva de negócio sejam

identificados:

O que leva a que o processo seja despoletado;

Relação com os requisitos identificados no PAF002 (em especial os de negócio/funcionais)

Qual a sua periodicidade e criticidade;

Quais são os intervenientes;

Quais são os input’s;

O que é feito em cada subprocesso;

Quais são os output’s e para que é que os mesmos servem

PIGENT011 - DESENHO TÉCNICO ALTO NÍVEL

Sistematiza do ponto de vista técnico as funcionalidades a desenvolver e respetivas integrações entre

plataformas aplicacionais.

O documento é composto por duas vertentes:

AS-IS, em que é apresentado o atual modelo de funcionamento (caso o mesmo exista).

TO-BE, em que é apresentado o futuro modelo de funcionamento.

PIGENT012 – DESENHO TÉCNCO END-TO_END

Este documento deverá descrever do ponto de vista técnico o fluxo de informação associado ao PAF003,

dando uma visão mais detalhada da existente ao nível do PIGEMT011.

Neste sentido, embora possam existir exceções, um PIGENT012 deverá corresponder a um PAF003.

CHECKLIST DEPLOY

Deverá ser criado com as ações de todas as equipas para que se possa assegurar que nenhum ponto seja

esquecido aquando a passagem a qualidade/produção.

DOCUMENTO DE DEPLOY

Documento os passos específicos para deploy dos objetos associados à plataforma.

PIQAST001 – PLANO DE ABORDAGEM AO TESTE

Este documento, que passa a ser de preenchimento obrigatório, em especial quando se verifica a

intervenção da equipa de Qualidade e Testes, e tem por objetivo a definição/identificação de:

Pré-requisitos para a realização dos testes, sejam estes ao nível de infraestruturas, dados, aplicações,

ou outro tema relevante



Requisitos a serem garantidos durante a fase de testes (ex.: necessidades de backup, etc.)

Datas relevantes e respetivo plano de qualidade e testes (ex.: início e fim da fase de teste, entrada em

produção, etc.)

Documentação com casos de testes, e outra documentação relevante de enquadramento do projeto

(PAF002, PAF003’s, etc.)

Definição dos critérios de aceitação por parte da equipa de qualidade e testes para execução dos

testes

Definição dos critérios de aceitação de passagem na fase de testes

Ferramentas a serem usadas para registo dos requisitos, registo casos de testes, gestão e controlo de

defeitos, execução dos testes, controlo da execução dos testes

Este documento deverá ser complementado com a elaboração do documento “PIQAST003 – Plano de

Testes”.

PIQAST003 – CADERNOS DE TESTES

Este grupo de documentos, serve para identificar os vários tipos de testes a serem executados no âmbito

dos desenvolvimentos que estão a ser efetuados bem como para registo da sua execução.

Neste documento há que identificar/associar os casos de teste aos respetivos requisitos identificados no

PAF002.

Dependendo da fase/ambiente (desenvolvimento, qualidade, produção) deverão estar definidos e ser

executados os respetivos cadernos de teste (testes unitários, testes técnicos, testes performance, teste de

carga, testes de aceitação, testes de regressão.

No casos em que os projetos intervêm em componentes com impactos em processos técnicos que não

fazem parte do âmbito do projeto, os mesmos deverão alertar a Galp no sentido de esta, em conjunto com

os outsourcer’s, planear testes adicionais no sentido de validar que esses processos se mantêm a funcionar

como esperado.

Este documento deverá abranger testes:

Técnicos: Incluindo casos de erro, em que deverá ser definido o comportamento esperado em termos

de recuperação do mesmo.

Funcionais: Que deverá incluir as situações de sucesso como as situações de validação de erros

associados à introdução de dados (ex.: NIF errado, Morada já existente, tamanho de campo excedido,

campo que não aceita algarismos, etc.).

Carga: Verificação que o sistema implementado tem capacidade de funcionar com a carga esperada.



PIQAST004 – TEC

Este documento, passa a ser de preenchimento obrigatório quando se verifica a intervenção da equipa de

Qualidade e Testes. Tem por objetivo o suporte à reunião para validação que estão reunidas as condições,

por parte do projeto, para que a aplicação/solução seja aceita para testes por parte da equipa de Qualidade

e Testes.

PIGENT023 – PROJECT RELEASE MGMT

Este documento destina-se a identificar:

As releases a efetuar nos diversos ambientes;

As releases associadas a melhorias e a necessidades de correção de erros;

Este documento deverá ser atualizado ao longo do projeto, sendo um input importante para o planeamento

das atividades dos vários stakeholder envolvidos, em especial as equipas de manutenção e para a

realização das reuniões de pré-CEP* e CEP*

Este documento deverá estar disponível na pasta do projeto no site de Arquitetura, na raiz da subpasta

“Deploy’s”**

PIGENTX19/PIARQTX19 - DESENHO TÉCNICO DETALHADO OBJETO

Documento técnico por objeto que identifica a lógica ao nível técnico do seu funcionamento e respetivas

particularidades.

Deverá ainda dar uma contextualização da arquitetura na ótica do objeto.

PIARQTX19UI – DESENHO TÉCNICO DETALHADO COM UI

Este documento técnico deve ser usado para documentar tecnicamente cada fluxo de informação numa

aplicação associado a um fluxo de User Interface (ex.: criação de cliente em Siebel, pedido de cartão no

GFO). Este documento deve explicar tecnicamente o fluxo aplicacional, os écrans, respetivos campos, listas

e validações e pequenas funcionalidades.

Sempre que associado ao fluxo exista um processo com uma complexidade média ou alta, o mesmo deve

ser identificado alto nível neste documento e elaborada a documentação técnica detalhada do mesmo no

PIARQTx19/PIGENTx19.

O elemento “x” no nome do template assume o valor que está atribuído por parte da Galp a cada aplicação

constante no seu SI.

Em situações particulares, e a acordar com a equipa de Arquitetura e Standards, se a aplicação for de

pequena dimensão e com um conjunto reduzido de funcionalidades, poderá ser decido elaborar um único

documento com todas as funcionalidades/fluxos de informação da aplicação.



PIGENT313BI - MODELO DE DADOS BUISNESS INTELLIGENCE

O PIGENT313BI, é um template específico para documentação da vertente técnica de Business Intelligence

que deriva do PIGENT011 deve clarificar com um maior nível de detalhe a forma como as entidades

informacionais se relacionam entre si, e como estas são refletidas no modelo físico (schemas e tabelas).

No PIGENT313 dever-se-á ter especial atenção para:

Identificação dos indicadores

Matriz que cruza os factos com as dimensões de análise

Garantir o alinhamento dos modelos fisicos por schema (nomenclaturas corretas, descrição das tabelas

e dos campos), com as funções definidas para cada camada da Arquitectura de BI

Dimensões (de análise) comuns ou transversais (ex: Tempo, Geografias, Cliente, Estações de Serviço,

Centros de Custo….)

CHANGE ORDER – PASSAGEM A PRODUÇÃO

Documento exigido pelo Outsourcer Galp para passagem a produção, este documento terá de ser entregue

15 dias da data de passagem.

PIARQT012 – TEMPOS DE EXECUÇÃO

Documento que tem como objetivo obter evidências dos testes efetuados em termos de:

Número de chamadas\evocações de determinado objeto.

Número e tipo de erros ocorridos.

Cumprimento das regras associadas ao logging e à gestão de erros.

Sempre que possível a informação subjacente a este documento será obtida de forma automática por

ferramentas disponibilizadas pela Galp sendo de responsabilidade da Arquitetura. Os projetos sempre que

pretendam submeter o projeto à promoção de ambientes devem preencher a folha Integração-Métricas

(PIARQT012) incluída no PIARQT011 – Checklist de Projeto.

Este documento é um documento complementar ao PIQAST003 – Plano de Testes.

MANUAL DE EXPLORAÇÃO

A atualização deste documento deverá ser alinhada com a equipa de manutenção e deverá ter sempre em

consideração que eventuais processos que sejam descontinuados pela entrada ou alteração de

funcionalidades deverão ser adequados à nova realidade.



5 Documentação Complementar

Apresenta-se de seguida a documentação complementar de enquadramento que deverá ser tida em

consideração na execução de projetos:

1. PIGEND007 – Implementação de projetos EAI.doc. 2. PIGEND307 – Implementação de projetos Siebel.doc. 3. PIGEND006 – Tibco – Guia de Projeto. 4. PIGEND106 – SAP PI – Guia de Projeto. 5. PIGEND306 – Siebel – Guia de Projeto. 6. PIGEND406 – ETL – Guia de Projeto. 7. PIGEND606 – StreamServe – Project Guide and Framework. 8. PIGEND706 – OBIEE – Guia de Projeto. 9. PIGEND206M – SAP M – Guia de Projeto – Fiori.

Documents

Guia de Projeto - energia cria energia - Galp · Arquitetura – Guia de Projeto Geral DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 6 de 24 2 Normas, Standards e Melhores