Guia de Projeto - energia cria energia - Galp · Arquitetura – Guia de Projeto Geral DSI -...
Transcript of Guia de Projeto - energia cria energia - Galp · Arquitetura – Guia de Projeto Geral DSI -...
Arquitetura – Guia de Projeto Geral
DSI/DIS – Desenho e Implementação de Soluções COPYRIGHT 2016 Galp 1 de 24
Arquitetura – Guia de Projeto Geral
Data da Publicação: Janeiro 2017
Versão: 4.6
Arquitetura – Guia de Projeto Geral
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)
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 3 de 24
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 4 de 24
Í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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 5 de 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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 6 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 7 de 24
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 8 de 24
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 9 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 10 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 11 de 24
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 12 de 24
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
A colocação das componentes desenvolvidas no âmbito do projeto neste ambiente é da
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 13 de 24
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
A colocação das componentes desenvolvidas no âmbito do projeto neste ambiente é da
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp, SA 14 de 24
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:
Arquitetura – Guia de Projeto Geral
DSI/DIS – Desenho e Implementação de Soluções COPYRIGHT 2016 Galp 15 de 24
Arquitetura – Guia de Projeto Geral
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 17 de 24
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)
Arquitetura – Guia de Projeto Geral
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 19 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 20 de 24
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
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 21 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 22 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 23 de 24
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.
Arquitetura – Guia de Projeto Geral
DSI - Arquitectura & Standards COPYRIGHT 2016 Galp 24 de 24
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.