Gestão de Projectos e Gestão da Manutenção nasDirecções de Sistemas de Informação
Diogo Filipe Dos Reis Pinto
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Orientadores: Professor José Luís Brinquete BorbinhaEngenheiro Miguel Ângelo Cotrim Bentes
Júri
Presidente: Professor Miguel Nuno Dias Alves Pupo CorreiaOrientador: Professor José Luís Brinquete Borbinha
Vogal: Professora Maria do Rosário Gomes Osório Bernardo Ponces de Carvalho
Novembro 2015
ii
Agradecimentos
Em primeiro lugar gostaria de deixar um agradecimento especial ao meu orientador externo Miguel
Bentes, que me acompanhou durante toda a dissertacao, em especial durante os tres meses de
desenvolvimento da solucao, demonstrando um empenho, compromisso e dedicacao extraordinarios
e que me permitiram, alem de adquirir todo o conhecimento necessario ao desenvolvimento desta
dissertacao, desenvolver um conjunto de competencias tecnicas que de certo serao muito importantes
no meu crescimento profissional.
Gostaria tambem de deixar um agradecimento especial ao meu orientador interno, o professor Jose
Borbinha, pela sua disponibilidade e experiencia, orientando-me durante todo o processo e auxiliando-
me na melhoria contınua do meu trabalho.
Por ultimo gostaria de agradecer aos meus pais, a minha namorada e aos meus amigos por todo o
apoio incondicional demonstrado.
iii
iv
Resumo
E proposto um processo generico para a gestao de pedidos de projectos e manutencoes evolutivas
numa direccao de sistemas de informacao de uma organizacao. Assumindo a direccao de sistemas de
informacao como o principal stakeholder, esta proposta alinha entre si tres vistas: a vista de processos,
a vista de responsabilidades e a vista de informacao.
A gestao nos sistemas de informacao de uma organizacao requer a gestao destes pedidos em al-
inhamento com as expectativas do negocio e um conjunto de outros criterios (risco, prioridade, capaci-
dade da equipa). Estes pedidos devem ser geridos de acordo com um conjunto de processos definidos
ate a sua satisfacao, identificando que actividades devem ser executadas e quais as entidades envolvi-
das nas mesmas.
Esta arquitectura de processos foi desenvolvida utilizando o metodo Design Science Research
Methodology (DSRM), inicialmente considerando o caso real de uma organizacao, sendo depois gen-
eralizado de forma a torna-la reutilizavel para outras organizacoes. A proposta aplicada ao caso real
apresentado foi ainda alvo de uma avaliacao por parte dos stakeholders da organizacao.
Palavras-chave: Gestao de Sistemas de Informacao, Gestao de Projecto, Gestao da Manutencao,
Responsabilidades.
v
vi
Abstract
It is proposed a generic process for dealing with requests for new projects or for evolutionary main-
tenance in an information systems department of an organization. Assuming the information systems
department’s organization as the main stakeholder, the proposal considers the alignment of three views:
the processes, the responsibilities and the information.
Information systems management on an organization requires handling these requests in alignment
with business expectations and several other criteria (risk, priority, team capabilities). These requests
must then be managed accordingly to a set of defined processes until its fulfillment, stating what activities
must be executed and who must be the entities involved in those activities.
This process architecture was developed using the Design Science Research Methodology, first
considering the real case scenario of a real organization, and after generalized in order to make it
reusable for any potential organization. An assessment of the proposal concerning the real case also
was performed by stakeholders of the real organization.
Keywords: Information Systems Management, Project Management, Maintenance Manage-
ment, Responsibilities.
vii
viii
Glossario
Arquitectura Principais conceitos e propriedades de um sistema de
acordo com o contexto em que este existe, englobando o
conjunto dos seus elementos e relacoes.
Gestao de Portfolios Escolha de programas e projectos, prioritizando-os e con-
trolando as dependencias entre si, segundo a estrategia da
organizacao.
Gestao de Programas Harmoniza os varios projectos ou sub-programas de forma
a atingir objectivos e benefıcios especıficos do programa.
Gestao de Projectos Aplicacao de metodos, ferramentas, tecnicas e com-
petencias a um projecto. E realizada atraves de proces-
sos, que sao seleccionados e aplicados de acordo com a
governacao de projectos conduzida pela organizacao.
Governacao de Projectos Fornece ao gestor de projecto e as respectivas equipas um
conjunto de processos, ferramentas e modelos de decisao
para a gestao dos projectos, enquanto permite o suporte e
controlo do sucesso dos mesmos.
Governacao A forma de controlo de uma organizacao visando o alcance
dos objetivos da mesma. Corresponde, entre outros as-
pectos, a definicao da estrutura de gestao de projectos, as
polıticas e metodos a utilizar, a definicao de responsabili-
dades e tomadas de decisao, a gestao de interaccoes e a
comunicacao e escalamento de problemas e riscos.
Manutencao Adaptativa Modificacao do software apos a sua entrega, de forma
a mante-lo correcto e em execucao num ambiente de
execucao alterado ou em constante evolucao.
Manutencao Correctiva Modificacao reactiva do software apos a entrega, de forma
a corrigir um problema encontrado na sua utilizacao.
Manutencao Perfectiva Modificacao do software apos a entrega de forma a detec-
tar e corrigir falhas latentes no mesmo antes destas falhas
serem detectadas.
Manutencao Preventiva Modificacao do software apos a entrega, de forma a de-
tectar e corrigir falhas latentes no mesmo antes destas se
tornarem falhas operacionais.
Manutencao Conjunto de activifdades realizadas para a implementacao
de uma modificacao apos entrega de uma solucao, de
forma a corrigir falhas da mesma.
ix
Operacoes Actividades com caracter repetitivo associadas a aspec-
tos de operacao e manutencao de sistemas ou produtos
fornecidos pela organizacao.
Portfolio Conjunto de projectos, programas, sub-portfolios e
operacoes geridos em conjunto de forma a atingir objec-
tivos estrategicos da organizacao.
Processo de Negocio Conjunto de actividades e tarefas relacionadas entre si e
coordenadas de forma a alcancar determinados objectivos
de negocio.
Processos de Entrega Nao sao unicos a gestao de projecto, e correspondem a
definicao e fornecimento de determinado produto, resul-
tado ou servico, dependendo do tipo de entregavel a que
se destina.
Processos de Gestao de Projecto Especıficos a gestao de projecto e determinam de que
forma as actividades a aplicar na gestao de projecto sao
conduzidas.
Processos de Suporte Nao sao unicos a gestao de projecto,fornecendo suporte
aos processos de gestao de projecto e de entrega em
areas como a area logıstica, a area financeira ou a area
de seguranca.
Programa Agrupado em portfolios e composto por sub-programas,
projectos e outras actividades que sao geridas de forma
coordenada para suportar o respectivo portfolio.
Projecto Conjunto unico de actividades coordenadas e controladas
com uma data de inıcio e fim definidas, executadas de
forma a alcancar um conjunto de objectivos estabelecidos
para o projecto.
Risco Conjunto de factores e influencias internas ou externas que
tornam incerto o alcance dos objectivos da organizacao.
Issue Acontecimento ocorrido e nao planeado, sendo necessario
proceder a sua gestao. Pode ter origem num risco que
tenha ocorrido ou qualquer tipo de nao-conformidade com
planos ou requisitos do projecto.
Software Parte integrante de um sistema, executando uma determi-
nada funcao neste contexto.
Stakeholder Elemento que possui informacoes e um conjunto de inter-
esses relativos ao projecto e ao sucesso do mesmo, sendo
parte integrante de todo o processo de gestao de projecto.
x
Indice
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Indice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
1 Introducao 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Definicao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Metodo de Investigacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Fundamentos 7
2.1 ISO/IEC 12207: Software Life Cycle Processes . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 ISO/IEC 14764: Software Life Cycle Processes - Maintenance . . . . . . . . . . . . . . . 10
2.3 ISO 21500: Guide on Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 PMBOK: Project Management Book of Knowledge . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Referencias Complementares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5.1 COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 ITIL v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.3 ISO 31000 - Risk Management - Principles and Guidelines . . . . . . . . . . . . . 19
3 Analise do Problema 22
3.1 Contextualizacao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Motivacao e Contexto Pratico do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Definicao Concreta do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Solucao 28
4.1 Arquitectura de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 Vista de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2 Vista de Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
xi
4.1.3 Vista de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Fase de Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Vista de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Vista de Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Vista de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Fase de Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Vista de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Vista de Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3 Vista de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Fase de Implementacao e Controlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.1 Vista de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.1.1 Controlo Semanal do Projecto . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.1.2 Controlo Mensal do Projecto . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1.3 Gestao de Riscos do Projecto . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1.4 Gestao de Issues do Projecto . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.1.5 Gestao de Alteracoes do Projecto . . . . . . . . . . . . . . . . . . . . . . 53
4.4.2 Vista de Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3 Vista de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Fase de Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.1 Vista de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.2 Vista de Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.3 Vista de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 Avaliacao 65
5.1 Avaliacao com Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Mapeamento com Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.1 Fase de Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.2 Fase de Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.3 Fase de Implementacao e Controlo . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.4 Fase de Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 Conclusao e Trabalho Futuro 74
Bibliografia 77
A Apendices 78
A.1 Documentos de Suporte da Fase de Oportunidade . . . . . . . . . . . . . . . . . . . . . . 78
A.2 Documentos de Suporte da Fase de Planeamento . . . . . . . . . . . . . . . . . . . . . . 79
A.3 Documentos de Suporte da Fase de Implementacao e Controlo . . . . . . . . . . . . . . . 80
A.4 Documentos de Suporte da Fase de Handover . . . . . . . . . . . . . . . . . . . . . . . . 81
A.5 PMBOK - Processos de Gestao de Projecto . . . . . . . . . . . . . . . . . . . . . . . . . . 82
xii
Lista de Tabelas
3.1 Processos de projecto e de compra considerados para o desenho da arquitectura. . . . . 26
4.1 Actividades detalhadas de identificacao e classificacao da oportunidade. . . . . . . . . . 34
4.2 Actividades detalhadas de analise da oportunidade e integracao em portfolio de projectos. 35
4.3 Matriz de responsabilidades das actividades de identificacao e analise da oportunidade. . 36
4.4 Matriz de responsabilidades das actividades de analise da oportunidade e integracao em
portfolio de projectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Matriz CRUF dos documentos de suporte da fase de oportunidade. . . . . . . . . . . . . 39
4.6 Actividades detalhadas do procedimento de compra. . . . . . . . . . . . . . . . . . . . . . 42
4.7 Vista de responsabilidades detalhada do procedimento de compra na fase de planeamento. 45
4.8 Matriz CRUF dos documentos de suporte ao processo na fase de planeamento. . . . . . 47
4.9 Actividades detalhadas do processo de controlo semanal do projecto. . . . . . . . . . . . 49
4.10 Actividades detalhadas do processo de controlo mensal do projecto. . . . . . . . . . . . . 50
4.11 Actividades detalhadas do processo de gestao de risco do projecto. . . . . . . . . . . . . 52
4.12 Vista de responsabilidades dos processos de controlo semanal e mensal do projecto. . . 56
4.13 Matriz CRUF dos documentos de suporte do processo de gestao semanal do projecto. . 58
4.14 Matriz CRUF dos documentos de suporte do processo de gestao mensal do projecto. . . 58
4.15 Matriz CRUF dos documentos de suporte do processo de gestao de riscos do projecto. . 59
4.16 Actividades detalhadas de aceitacao do projecto. . . . . . . . . . . . . . . . . . . . . . . . 61
4.17 Vista de responsabilidades das actividades de aceitacao do projecto. . . . . . . . . . . . 63
4.18 Matriz CRUF dos documentos de suporte da fase de handover do processo. . . . . . . . 64
5.1 Mapeamento com referencias relativo a fase de oportunidade. . . . . . . . . . . . . . . . 69
5.2 Mapeamento com referencias relativo a fase de planeamento. . . . . . . . . . . . . . . . 71
5.3 Mapeamento com referencias relativo a fase de implementacao e controlo. . . . . . . . . 72
5.4 Mapeamento com referencias relativo a fase de handover. . . . . . . . . . . . . . . . . . . 73
A.1 Documentos de suporte ao processo relativos a fase de oportunidade. . . . . . . . . . . . 78
A.2 Documentos de suporte ao processo relativos a fase de Planeamento. . . . . . . . . . . . 79
A.3 Descricao dos documentos de suporte ao processo relativos a fase de implementacao e
controlo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.4 Descricao dos documentos de suporte ao processo relativos a fase de handover. . . . . . 81
xiii
xiv
Lista de Figuras
1.1 Mapeamento das fases do DSRM para o trabalho realizado. . . . . . . . . . . . . . . . . . 5
2.1 Processos do ciclo de vida do software identificados pela ISO/IEC 12207. Extraıdo de [8]. 9
2.2 Tipos de pedidos de alteracao. Extraido de [7]. . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Contexto da gestao de projectos na organizacao. Extraıdo de [6]. . . . . . . . . . . . . . . 12
2.4 Processos de gestao de projecto segundo a ISO 21500. Extraıdo de [6]. . . . . . . . . . . 14
2.5 Elementos facilitadores da governacao identificados pelo COBIT. Extraıdo de [3]. . . . . . 17
2.6 Framework de gestao de risco proposta pela ISO 31000. Extraıdo de [5]. . . . . . . . . . 20
2.7 Processos de gestao de risco identificados pela ISO 31000. Extraıdo de [5]. . . . . . . . 21
3.1 Estrutura da organizacao considerada como caso real. . . . . . . . . . . . . . . . . . . . 24
4.1 Modelo conceptual da arquitectura de processos. Extraıdo de [9]. . . . . . . . . . . . . . 29
4.2 Fluxo completo do processo de gestao de projectos e manutencoes. . . . . . . . . . . . . 30
4.3 Fluxo do processo relativo a fase de oportunidade. . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Fluxo do processo relativo a gestao de stakeholders, riscos e comunicacoes na fase de
planeamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Fluxo do processo relativo ao procedimento de compra e gestao de calendario e de custos. 41
4.6 Fluxo do processo de controlo semanal do projecto. . . . . . . . . . . . . . . . . . . . . . 48
4.7 Fluxo do processo de controlo mensal do projecto. . . . . . . . . . . . . . . . . . . . . . . 49
4.8 Fluxo do processo de identificacao e analise do risco. . . . . . . . . . . . . . . . . . . . . 51
4.9 Fluxo do processo de tratamento do risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.10 Fluxo do processo de identificacao e gestao de issues escalados. . . . . . . . . . . . . . 53
4.11 Fluxo do processo de gestao de issues nao-escalados e fecho do issue. . . . . . . . . . . 53
4.12 Fluxo do processo de gestao de alteracoes relativo ao planeamento e aprovacao da
alteracao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.13 Fluxo do processo de gestao de alteracoes relativo ao controlo e fecho da alteracao. . . . 55
4.14 Fluxo do processo relativo a aceitacao do projecto. . . . . . . . . . . . . . . . . . . . . . . 60
4.15 Fluxo do processo relativo a passagem a producao e encerramento do projecto. . . . . . 62
A.1 Processos definidos pelo PMBOK. Extraıdo de [2]. . . . . . . . . . . . . . . . . . . . . . . 82
xv
xvi
Capıtulo 1
Introducao
Neste capıtulo e feita uma introducao ao tema da gestao de projectos e manutencoes nas direccoes dos
sistemas de informacao. Pretende-se realizar uma contextualizacao do tema, que tem vindo a ter um
maior destaque na area dos sistemas de informacao, motivado pela necessidade das organizacoes de
possuir processos bem definidos para a gestao de actividades de execucao de projectos e manutencoes,
garantindo o alcance dos seus objectivos de negocio.
Pretende-se ainda apresentar quais os principais objectivos da solucao a desenvolver e um conjunto
de questoes que guiam todo o metodo de desenvolvimento. Estas questoes serao fundamentais na
avaliacao da solucao e da satisfacao dos requisitos do problema.
Todo o trabalho realizado foi conduzido por um metodo de investigacao, o Design Science Research
Metodology (DSRM) [16], amplamente utilizado na definicao e validacao de solucoes para problemas
na area dos sistemas de informacao, e adaptado no contexto deste trabalho de forma a ir ao encontro
dos seus objectivos.
1.1 Motivacao
Um dos aspectos importantes para uma organizacao ganhar vantagem competitiva face a concorrencia
e na forma como lida com a recepcao e gestao de pedidos de execucao de projectos e manutencoes.
Ha uma necessidade fundamental de classificar todos os pedidos em termos de oportunidades e valor
para o negocio, bem como o risco associado a sua aceitacao pela organizacao, tornando um pedido
numa oportunidade de negocio. Uma correcta analise do pedido e da consequente oportunidade que
apresenta a organizacao sera fundamental para garantir o sucesso no caso da sua aceitacao.
Alem da capacidade de analise de pedidos, a organizacao necessita de possuir processos bem
definidos para a gestao dos mesmos. Quando um novo pedido e apresentado a organizacao, deve ser
gerido de acordo com um processo predefinido que, independentemente do seu caracter ou da sua
origem, defina actividades (e respectivos inputs e outputs) e responsabilidades durante todo o ciclo de
vida do pedido ate a sua satisfacao.
Ao longo dos anos, profissionais da area dos sistemas de informacao definiram um conjunto de
1
frameworks e guias, numa tentativa de fornecer e normalizar praticas de gestao dos sistemas de
informacao. Tendo em conta o estado de arte actual nesta area, a ISO 21500 apresenta-se como a
norma internacional orientada a gestao de projectos. Considerando a definicao fornecida pela propria
ISO (Iternational Standard Organization), a ISO 21500 fornece um conjunto de praticas aconselhadas
na gestao de projectos que podem ser utilizadas por qualquer tipo de organizacao, independentemente
da sua area de servico ou do tipo de projecto, complexidade ou duracao. Nao define actividades es-
pecıficas a executar, apresentando uma visao orientada aos processos que devem ser executados
durante toda o ciclo de vida do projecto e focando-se nos inputs e outputs de cada processo.
A utilizacao do Project Management Book Of Knowledge (PMBOK), um dos guias de gestao de
projecto amplamente aceite por profissionais de todas as areas de conhecimento como uma referencia
em processos de gestao de projecto, complementa de forma extensa a ISO 21500, apresentando uma
correspondencia quase perfeita no que ao ambito dos processos diz respeito. Porem, apresenta um
maior nıvel de detalhe e identifica ainda um conjunto de tecnicas e ferramentas a aplicar no conjunto
de processos de gestao apresentados.
Considerando a area da gestao da manutencao, a norma ISO/IEC 14764 define os processos de
manutencao no ciclo de vida do software e servicos desenvolvidos por uma organizacao, cobrindo
as fases de planeamento, execucao, controlo, revisao e avaliacao de manutencoes. Corresponde a
especializacao dos processos de manutencao identificados por outra norma, a ISO/IEC 12207, que
identifica os processos do ciclo de vida do software e servicos, tambem analisada na definicao dos
processos a considerar no ambito da solucao a desenvolver.
Apesar de uma cobertura quase completa do ciclo de vida de projectos e manutencoes, aspectos
mais intrınsecos a organizacao, como a recepcao de pedidos ou a aceitacao de produtos e servicos pelo
cliente, nao se encontram explıcitos nestas referencias, sendo necessario considerar como referencia
secundaria o COBIT 5, orientado a gestao e governacao dos sistemas de informacao na organizacao. O
ITIL, um guia de praticas de gestao de servicos de tecnologias de informacao e a ISO 31000, orientada
a gestao de risco, tambem sao consideradas como referencias complementares fazendo face a lacunas
identificadas na cobertura de todos os processos de gestao de projectos e manutencoes.
Com o objectivo de estabelecer um processo de gestao de pedidos de execucao de projectos e
manutencoes, numa primeira fase sao analisadas um conjunto de referencias em processos orientados
a gestao de projectos e manutencoes na area dos sistemas de informacao, extraindo-se um conjunto
de conhecimentos necessarios para o desenho de todo o processo e definicao de responsabilidades,
atraves de uma arquitectura de processos que alinha entre si tres vistas, a vista de processos, a vista
de responsabilidades e a vista de informacao.
Alem destas referencias, sera tambem utilizado um caso real de uma organizacao como base para
o desenho do processo, que contemplara duas iteracoes: Uma arquitectura de processos aplicada ao
caso real da organizacao, traduzida num manual do processo especıfico, e uma arquitectura de proces-
sos mais generica, apresentada neste documento, e que procura ser aplicavel a um maior numero de
organizacoes, generalizando aspectos que sao intrınsecos ao caso real que estamos a considerar.
Para a avaliacao desta arquitectura serao utilizados dois metodos: a avaliacao com stakeholders,
2
metodo apresentado na seccao 5.1 e que procura ir ao encontro das expectativas dos stakeholders
tendo em conta o caso real da organizacao, e o metodo de mapeamento com referencias, apresentado
na seccao 5.2, que consiste num metodo teorico de definicao de correspondencias dos processos
definidos na arquitectura com processos identificados nas principais referencias consideradas.
1.2 Definicao do Problema
O proposito deste trabalho e a definicao de um processo de referencia para a gestao de pedidos de
projectos e de manutencoes numa direccao dos sistemas de informacao. Neste ambito, considera-
se um projecto como um conjunto unico de actividades coordenadas e controladas com uma data de
inıcio e fim definidas, executadas de forma a alcancar um conjunto de objectivos estabelecidos para o
projecto. Uma manutencao corresponde a um conjunto de actividades realizadas para a implementacao
de uma modificacao apos entrega de uma solucao, de forma a corrigir falhas da mesma.
Considerando o caso real de uma organizacao, pretende-se definir, alem do fluxo do processo e
das actividades a executar, um conjunto de responsabilidades atribuıdas a estrutura organizacional da
organizacao bem como um conjunto de documentos de suporte ao processo.
Pretende-se ainda garantir a aplicabilidade da solucao atraves da sua generalizacao, possibilitando
a sua adaptacao a qualquer organizacao. Em suma, o objectivo e responder as seguintes questoes:
1. Questao 1 - Que processos (e correspondentes actividades) devem ser executados para a gestao
de pedidos de execucao de projectos e manutencoes?
2. Questao 2 - Quais as responsabilidades dos varios elementos da area de sistemas de informacao
em todo o processo?
3. Questao 3 - Quais os documentos que suportam todo o processo?
Alem das questoes de desenvolvimento definidas, foram tracados um conjunto de objectivos rela-
cionados com o desenho da solucao e os contrangimentos que a ela se aplicam, permitindo durante a
fase de avaliacao garantir o cumprimento de todos os objectivos estabelecidos:
• A solucao devera cumprir um prazo limitado de desenvolvimento, sendo necessario identificar um
conjunto de processos a considerar, nao sendo possıvel garantir uma extensibilidade da solucao
em todos os processos identificados pelas referencias.
• A arquitectura de processos a desenvolver devera garantir uma conformidade com um conjunto de
referencias na area da gestao de projectos e gestao de manutencoes, apresentadas no capıtulo
2, baseando-se nas melhores praticas de gestao.
• A arquitectura devera ser, alem de aplicavel ao caso real da organizacao considerado, adaptavel
a um conjunto de outras organizacoes, sendo necessario generalizar aspectos especıficos e
intrınsecos ao caso real analisado.
3
1.3 Metodo de Investigacao
De forma a conduzir todo o desenvolvimento foi utilizado o metodo de investigacao Design Science
Research Methodology (DSRM), apresentado no artigo A design science research methodology for
information systems research [16], e utilizado amplamenta na area dos sistemas de informacao para a
apresentacao e validacao de solucoes desenvolvidas.
Os sistemas de informacao retiram um conjunto de vantagens da aplicacao do DSRM a investigacao
na area, nomeadamente no desenvolvimento de solucoes para problemas da propria area e da sua
presenca nas organizacoes. Este metodo possui tes objectivos principais: Apresentar um metodo para
a conducao de investigacoes, definir como base da investigacao um conjunto de referencias literarias
que a suportam e fornecer aos investigadores um modelo mental dos resultados da investigacao.
O DSRM consiste num processo com caracter iterativo e composto por seis fases:
• Identificacao do problema e motivacao - Definicao da importancia do problema e da necessi-
dade de uma solucao;
• Definicao dos objectivos da solucao - Definicao dos requisitos que devem ser cumpridos pela
solucao a implementar;
• Desenho e desenvolvimento - Fase principal do processo na qual os artefactos da solucao sao
implementados para cumprir os requisitos estabelecidos. Esta fase possui um caracter iterativo
pois necessita de avaliacoes e revisoes aos artefactos. Ira receber feedback das fases seguintes.
• Demonstracao - Confirmacao da aplicacao dos artefactos aos requisitos do problema;
• Avaliacao - Medida do nıvel de satisfacao dos requisitos estabelecidos por parte dos artefactos
produzidos.
• Comunicacao - Documentacao e divulgacao dos artefactos como solucao do problema identifi-
cado.
Na figura 1.1 e possıvel observar a aplicacao do metodo ao trabalho realizado. A necessidade
de definicao de um processo para a gestao de projectos e manutencoes na direccao de sistemas de
informacao de uma organizacao apresentada como caso real assume o papel de entry point para todo
o processo:
• Identificacao do problema e motivacao - Analise do estado da arte na gestao de projectos e
manutencoes nas direccoes de sistemas de informacao, fazendo um levantamento dos principais
processos a considerar.
• Definicao dos objectivos da solucao - Desenho de uma arquitectura de processos para a gestao
de projectos e manutencoes aplicavel a um conjunto de direccoes de sistemas de informacao,
tendo como base o caso real de uma organizacao e o conjunto de stakeholders considerado.
Tendo em conta este objectivo, a arquitectura a definir possuira duas versoes:
4
Figura 1.1: Mapeamento das fases do DSRM para o trabalho realizado.
– Versao generalizada da arquitectura, apresentada no capıtulo 4 deste documento e que
generaliza aspectos intrınsecos as organizacoes e a sua estrutura organizacional.
– Versao aplicada ao caso real da organizacao, que corresponde ao manual do processo
produzido na fase de comunicacao, e que aplica a arquitectura generalizada ao caso real da
organizacao.
• Desenho e desenvolvimento - Definicao da arquitectura de processos que alinha entre si tres
vistas: a vista de processos, a vista de responsabilidades e a vista de informacao, indo ao encon-
tro do conjunto de constrangimentos ao problema identificados.
• Demonstracao - Producao de um manual do processo com a definicao de uma arquitectura
aplicada ao caso real da organizacao considerado, alvo de um processo iterativo de validacao
com os stakeholders considerados.
• Avaliacao - Aplicacao de dois metodos de avaliacao da arquitectura de processos. A avaliacao
com stakeholders, aplicavel as duas versoes da arquitectura produzidas e o mapeamento com
referencias, aplicado a versao generalizada da arquitectura.
• Comunicacao - Producao do manual do processo, relativo a versao da arquitectura de proces-
sos aplicada ao caso real da organizacao, e a escrita da dissertacao que apresenta a versao
generalizada da arquitectura desenvolvida.
1.4 Estrutura do Documento
Este documento encontra-se organizado da seguinte forma:
1. O capıtulo 1 introduz o problema a solucionar, apresentando-se uma contextualizacao do tema
e motivacao do problema, sendo tambem apresentado o metodo de investigacao utilizado no
desenvolvimento da solucao.
5
2. O capıtulo 2 apresenta um conjunto de fundamentos na area de gestao de projectos e manutencoes,
identificando um conjunto de referencias consideradas como normas ou guias de boas praticas na
area e a partir das quais e feito todo o desenvolvimento da solucao. Neste capıtulo serao apresen-
tados as normas internacionais ISO/IEC 12207, ISO/IEC 14764 e ISO 21500 e o PMBOK, sendo
tambem analisadas como referencias complementares o COBIT 5, o ITIL V3 e a ISO 31000.
3. O capıtulo 3 apresenta em maior detalhe o problema abordado, contextualizando-o e definindo
alguns constragimentos que introduz a solucao a desenvolver. Neste capıtulo e tambem apresen-
tado o caso real da organizacao que sera utilizado para demonstracao da solucao.
4. O capıtulo 4 apresenta a solucao desenvolvida, identificando de que forma endereca o problema
considerado, sendo detalhadas algumas decisoes de desenvolvimento e os aspectos mais impor-
tantes da arquitectura desenvolvida.
5. No capıtulo 5 e apresentada a avaliacao da solucao, procedendo-se a utilizacao de dois metodos
de avaliacao: avaliacao com stakeholders e o mapeamento com referencias.
6. No capıtulo 6 sao apresentadas as principais conclusoes obtidas e identificadas propostas de
trabalho futuro no ambito do trabalho desenvolvido.
6
Capıtulo 2
Fundamentos
Neste capıtulo sao apresentadas um conjunto de referencias na area da gestao de projectos e gestao
de manutencoes, a utilizar como base de conhecimento na definicao da arquitectura de processos. As
frameworks, normas e guias apresentadas de seguida reunem um conjunto de conhecimentos consid-
erados por profissionais da area como as melhores praticas de gestao de projectos e manutencoes,
sendo necessario seleccionar o conjunto de conhecimentos efectivos a aplicar, de acordo com os ob-
jectivos definidos para a arquitectura a desenvolver.
A primeira referencia a analisar e a norma internacional ISO/IEC 12207 - Software Life Cycle Pro-
cesses [8]. Esta norma define uma framework de processsos a aplicar durante o ciclo de vida do
software e de servicos, sendo util na identificacao das areas de processos a considerar na definicao
da arquitectura de processsos. Directamente relacionada com esta norma, a ISO/IEC 14764: Soft-
ware Life Cycle Processes - Maintenance [7] detalha os processos de manutencao identificados pela
ISO/IEC 12207, apresentando processos, actividades e conceitos que cobrem todo o ciclo de vida das
manutencoes.
Na area da gestao de projectos, a ISO 21500: Guide on Project Management [6] e o Project Man-
agement Book of Knowledge [2] constituem as principais referencias, identificando boas praticas e
processos aplicaveis a um vasto conjunto de organizacoes. Definem toda a base de conhecimento
a partir da qual sera desenhada a arquitectura, desde as areas de processos a desenvolver ate aos
documentos de suporte a considerar.
Alem destas referencias, e tendo em conta algumas lacunas em termos de classificacao e entregas
de pedidos, bem como de alguns aspectos especıficos da gestao de projecto, consideram-se tambem
um conjunto de referencias complementares, detalhadas na seccao 2.5.
2.1 ISO/IEC 12207: Software Life Cycle Processes
Esta norma internacional estabelece uma framework de processos a executar durante o ciclo de vida do
software e servicos, apresentando processos, actividades e tarefas que deverao ser executadas tanto
na sua compra e fornecimento bem como durante o seu desenvolvimento, operacao e manutencao.
7
O principal objectivo desta norma e facilitar a comunicacao entre todos os participantes no ciclo de
vida do software e servicos, garantindo que as organizacoes envolvidas no seu fornecimento e compra
se encontrem perfeitamente alinhadas em termos de processos a desenvolver bem como de objectivos
e resultados a alcancar.
Os conceitos de sistema e software definem o contexto dos processos identificados por esta norma.
De acordo com esta norma, o software corresponde a uma parte integrante de um sistema, execu-
tando uma determinada funcao neste contexto. Esta relacao torna-se mais perceptıvel, por exemplo, na
analise de requisitos, em que os requisitos do software sao extraıdos a partir da analise de requisitos
do sistema. Apesar desta distincao, existem casos em que a separacao entre o sistema e o software
que o compoe e praticamente residual.
De acordo com a ISO 12207, o ciclo de vida de software e servicos inicia-se com uma ideia ou
necessidade a colmatar e termina com a manutencao desse mesmo software ou servico. A framework e
consitutida por um conjunto de processos e relacoes, identificados de acordo com os princıpios basicos
de coesao (os processos devem estar interligados entre si de forma a garantir uma framework coesa) e
de responsabilidade (o desenho e implementacao de um processo e responsabilidade da organizacao
ao qual se destina).
O conjunto de processos e dividido numa primeira fase entre processos no contexto do sistema e
processos no contexto de software, sendo no seu conjunto agrupados em 7 grupos de processos. Cada
processo e descrito em termos dos seus objectivos, resultados esperados e actividades a executar para
alcancar esses objectivos. Os processos dividem-se nos seguintes grupos:
• Processos de acordo - Processos necessarios ao estabelecimento de acordos de compra e
fornecimento de software ou servicos entre duas organizacoes.
• Processos organizacionais - Processos para a gestao da capacidade de compra e fornecimento
de software e servicos atraves da execucao de projectos. Estes processos garantem a posse de
recursos e infraestruturas necessarias ao suporte dos projectos e a satisfacao dos objectivos da
organizacao.
• Processos de projecto - Processos para a definicao de planos do projecto, para a avaliacao da
performance e progresso relativamente aos planos e para o controlo da execucao do projecto ate
ao seu encerramento.
• Processos tecnicos - Processos que acompanham o ciclo de vida de um sistema, desde a
definicao dos requisitos ao desenho e implementacao do mesmo. Inclui tambem processos rela-
tivos a utilizacao do sistema pelos utilizadores.
• Processos de implementacao de software - Processos utilizados para produzir um elemento
especıfico de um sistema implementado na forma de software. Estes processos transformam um
conjunto de procedimentos, interfaces e constrangimentos numa implementacao de um elemento
de um sistema que satisfaz um conjunto de requisitos extraidos dos requisitos do sistema.
8
• Processos de suporte de software - Processos focados num conjunto de actividades de suporte
aos processos de implementacao de software, contribuındo para o seu sucesso e para a qualidade
do projecto.
• Processos de reutilizacao de software - Processos que suportam a capacidade da organizacao
de reutilizar software de um dado projecto noutros projectos ou contextos em que possa ser
aplicado. Estes processos sao executados foram do ambito de um projecto particular, sendo
comum a todos os projectos.
Na figura 2.1 podemos observar os grupos de processos identificados anteriormente, sendo tambem
apresentado os processos que fazem parte de cada grupo.
Figura 2.1: Processos do ciclo de vida do software identificados pela ISO/IEC 12207. Extraıdo de [8].
Esta norma nao detalha os processos em termos de detalhes de implementacao, nao os pre-
screvendo a organizacao e deixando espaco de decisao para escolhas de implementacao. Alem disso,
o conjunto de processos apresentado e suficientemente generico de modo a permitir a sua adopcao e
adaptabilidade a um conjunto vasto de organizacoes, que actuem em diferentes contextos.
Esta norma internacional possui especial interesse na medida em que identifica o grupo de proces-
sos que contempla todas as fases do ciclo de vida de sistemas, que pretendemos cobrir com a arquitec-
tura a desenvolver. Tendo em conta os objectivos definidos, serao especialmente importantes os pro-
cessos de acordo, processos organizacionais e processos de projecto, que apresentam um foco mais
9
orientado a gestao do projecto do que a aspectos mais operacionais e especıficos a implementacao de
sistemas. Na seccao 3.3 esta norma sera utilizada na identificacao dos processos especıficos consid-
erados no desenvolvimento da solucao.
2.2 ISO/IEC 14764: Software Life Cycle Processes - Maintenance
A norma ISO/IEC 14764: Software Life Cycle Processes - Maintenance [7] corresponde a uma especializacao
do processo de manutencao identificado pela ISO/IEC 12207, apresentada acima, e define todo o pro-
cesso de planeamento, execucao, controlo, revisao e avaliacao de manutencoes. Focando-se apenas
na manutencao de software, esta norma aplica-se a qualquer contexto nesta area, independentemente
do tamanho, complexidade ou aplicacao do software.
Na figura 2.2 encontramos a definicao dos varios pedidos de alteracao considerados por esta norma
e que poderao ser apresentados durante a manutencao de um software. Um pedido generico de
alteracao e classificado como um pedido correctivo (correspondendo a uma alteracao reactiva prove-
niente de uma nao conformidade do software) ou um pedido de melhoria (correspondendo a uma
alteracao que visa a satisfacao de um novo requisito), sendo depois detalhado num dos seguintes
tipos de manutencao:
Figura 2.2: Tipos de pedidos de alteracao. Extraido de [7].
• Manutencao correctiva - Modificacao reactiva do software apos a entrega, de forma a corrigir
um problema encontrado na sua utilizacao.
• Manutencao preventiva - Modificacao do software apos a entrega, de forma a detectar e corrigir
falhas latentes no software antes destas se tornarem falhas operacionais.
• Manutencao adaptativa - Modificacao do software apos a sua entrega, de forma a mante-lo
correcto e em execucao num ambiente de execucao alterado ou em constante evolucao.
• Manutencao perfectiva - Modificacao do software apos a entrega de forma a detectar e corrigir
falhas latentes no software antes destas falhas serem detectadas.
O processo de manutencao apresentado nesta norma contem um conjunto de actividades e tare-
fas necessarias desenvolver, sendo a sua implementacao responsabilidade da area de manutencao
10
da organizacao, que deve garantir que todas as actividades se encontram implementadas e funcionais
antes de iniciar o desenvolvimento de software. Este processo devera ser iniciado assim que os requisi-
tos de manutencao surjam no ambito do projecto, dando inıcio ao desenvolvimento de planos e alocacao
de recursos. Esta norma define o seguinte processo de manutencao, dividido em seis sub-processos:
• Implementacao do processo - Nesta fase sao desenvolvidos os planos e procedimentos para
a execucao do processo de manutencao. O plano de manutencao deve ser desenvolvido em
paralelo com o plano de desenvolvimento, garantindo que toda a manutencao e planeada ainda
durante o desenvolvimento do software e que todas as interfaces de comunicacao entre equipas
de desenvolvimento e manutencao sao estabelecidas.
• Analise da manutencao - Este processo e os restantes sao apenas executados quando o soft-
ware transita para manutencao e pedidos de manutencao surjam. Sao analisados os pedidos
de manutencao, replicados e verificados possiveis problemas que deram origem ao pedido, anal-
isadas e documentadas opcoes para a implementacao da manutencao e obtida aprovacao para a
implementacao da solucao seleccionada.
• Implementacao da manutencao - Este processo corresponde ao desenvolvimento e teste da
manutencao realizada no software de forma a ir ao encontro do pedido de manutencao analisado
na fase anterior.
• Revisao e aceitacao da manutencao - Este processo assegura que as alteracoes ao software
foram as correctas e aceites pela entidade que requeriu a manutencao, de acordo com os proces-
sos definidos pela organizacao para esse efeito.
• Migracao - Processo que assegura a passagem do software para o ambiente de execucao em
conformidade com a ISO/IEC 12207, sendo desenvolvido um plano de migracao para o acompan-
hamento de todo o processo.
• Retirada do software - Processo para a saıda de funcionamento do software, que devera ser su-
portado por uma analise de necessidade. Devem ser identificadas todas as actividades necessarias
realizar nesta fase pelos responsaveis da manutencao e desenvolver um plano de saıda de fun-
cionamento.
Todo o processo de manutencao detalhado nesta norma possui um caracter mais operacional, iden-
tificando tarefas especıficas a realizar em cada sub-processo de forma a ir ao encontro do ciclo de
vida do software identificado pela ISO/IEC 12207. Tendo em conta os objectivos estabelecidos, nao
se pretende uma visao tao operacional do processo, razao pela qual se encontra especial interesse
na estrategia de manutencao de software identificada nesta norma. Esta estrategia identifica quais os
recursos humanos e materiais necessarios para fornecer a manutencao, dividindo-se nos seguintes
elementos:
• Conceito da manutencao - Corresponde ao primeiro passo de desenvolvimento de uma es-
trategia de manutencao, devendo ser identificado o seu ambito, o processo de implementacao e
11
responsaveis e realizada uma estimativa de custos da manutencao.
• Plano de manutencao - Corresponde ao planeamento das actividades de manutencao e a aquisicao
de todos os recursos necessarios de forma a que estes se encontrem disponıveis no momento
da transicao do software para manutencao. O planeamento e iniciado assim que o conceito da
manutencao e definido e termina com a definicao do plano de manutencao.
• Analise de recursos - Corresponde a definicao de todos os recursos necessarios a implementacao
da manutencao. O responsavel pela manutencao devera determinar os recursos humanos, tec-
nologicos e financeiros necessarios.
A norma ISO/IEC 14764 apresenta-se como a referencia completa em toda a area de gestao da
manutencao, identificando todos os processos de manutencao necessarios durante o ciclo de vida do
software, atraves de uma visao mais operacional da manutencao, e apresentando processos para a
definicao da estrategia de manutencao de software, com um caracter mais estrategico.
2.3 ISO 21500: Guide on Project Management
A ISO 21500:Guide on Project Management [6] reune um conjunto de conceitos alto-nıvel e processos
que sao considerados boas praticas na area de gestao de projecto. Pode ser utilizada por qualquer
tipo de organizacao, independentemente do seu contexto (publica, privada, comunitaria) e do tipo, com-
plexidade ou duracao de projectos levados a cabo. Um projecto e definido por esta norma como um
conjunto unico de actividades coordenadas e controladas com uma data de inıcio e fim definidas, ex-
ecutadas de forma a alcancar os objectivos do projecto. E ainda definido um conjunto de conceitos
e de relacoes entre eles, sendo possıvel definir um contexto de gestao de projectos dentro de uma
organizacao, apresentado na figura 2.3.
Figura 2.3: Contexto da gestao de projectos na organizacao. Extraıdo de [6].
12
Tendo em conta este contexto, a estrategia organizacional identifica um conjunto de oportunidades
que sao avaliadas e documentadas. Deste conjunto de oportunidades, apenas algumas sao aceites
para darem inicio a projectos, sendo desenvolvido o caso de negocio que representa a oportunidade em
termos de valor e objectivos para a organizacao. Esta fase corresponde ao conceito de governacao de
projecto, que e definido pela ISO 21500 como a forma como uma organizacao e orientada e controlada.
A governacao corresponde, entre outros aspectos, a definicao da estrutura de gestao de projectos,
as polıticas e metodos a utilizar, a definicao de responsabilidades e tomadas de decisao, a gestao de
interaccoes e a comunicacao e escalamento de problemas e riscos.
A gestao de projectos e definida como a aplicacao de metodos, ferramentas, tecnicas e com-
petencias a um projecto. E realizada atraves de processos, que sao seleccionados e adaptados a
governacao de projectos conduzida pela organizacao. Nesta norma sao identificados tres tipos de
processos:
• Processos de gestao de projecto - Especıficos a gestao de projecto e determinam de que forma
as actividades a aplicar na gestao de projecto sao conduzidas.
• Processos de entrega - Nao sao unicos a gestao de projecto, e correspondem a definicao e
fornecimento de determinado produto, resultado ou servico, dependendo do tipo de entregavel a
que se destina.
• Processos de suporte - Nao sao unicos a gestao de projecto, fornecendo suporte aos processos
de gestao de projecto e de entrega em areas como a logıstica, financeira ou seguranca.
No contexto da organizacao sao ainda apresentadas as operacoes, que diferem dos projectos
pelo seu caracter repetitivo e foco na realizacao de actividades repetidas, associadas a aspectos de
operacao e manutencao de sistemas ou produtos fornecidos pela organizacao. As actividades de
manutencao, embora nao especificadas nesta norma, sao consideradas tambem como operacoes.
Apesar de definir tres tipos de processos orientados a gestao de projecto, a ISO 21500 detalha
apenas os procesos de gestao de projecto, que devem ser usados como um todo durante o ciclo de
vida do projecto, que corresponde ao perıodo entre a data de inıcio e de fim do mesmo. Divide-se em
fases de acordo com pontos de decisao, que variam em funcao da organizacao a que se aplicam. No
final da ultima fase do projecto, todos os entregaveis do projecto devem encontrar-se finalizados.
O conjunto de processos a aplicar para a gestao de projectos deve ser seleccionado e detalhado de
acordo com os objectivos da organizacao, de forma a se encontrar alinhado com os mesmos. A ISO
21500 divide os processos de acordo com duas perspectivas diferentes, como grupos de processos e
como areas de conhecimento. O conjunto de processos identificados podem ser observados na figura
2.4. Para cada processo sao detalhados os seus objectivos, a descricao de actividades a realizar e um
conjunto de inputs e outputs do processo.
Esta norma internacional corresponde a principal referencia considerada na area da gestao de pro-
jecto. Cobre todo o ciclo de vida de um projecto, desde a definicao da oportunidade ate ao encerra-
mento. Porem, foca-se apenas em processos de gestao de projecto, nao detalhando os processos de
13
Figura 2.4: Processos de gestao de projecto segundo a ISO 21500. Extraıdo de [6].
governacao e que serao especialmente importantes para a classificacao de oportunidades. E tambem
considerado que um projecto termina com os processos de encerramento do projecto, nao detalhando
aspectos de aceitacao e entrega do mesmo.
Alem destas limitacoes, a ISO 21500 foca-se principalmente nos inputs e outputs de cada processo
identificado, nao detalhando o conteudo destes artefactos. A definicao de actividades de cada processo
tambem e limitada, sendo apenas apresentados alguns objectivos de alto nıvel do processo. Por esta
razao, e necessario considerar uma referencia mais completa no que a actividades a executar em cada
processo diz respeito.
2.4 PMBOK: Project Management Book of Knowledge
O Project Management Book of Knowledge (PMBOK) [2] corresponde a um guia de boas praticas na
gestao de projectos individuais, definindo tambem um conjunto de conceitos relacionados com a area.
E considerado como o guia de referencia na gestao de projectos, independentemente da area ou do
tipo, complexidade ou tamanho do projecto. Resulta da experiencia de profissionais na area ao longo
dos anos bem como da aplicacao das praticas em projectos reais.
O PBMOK define um projecto como um esforco temporario realizado para criar um produto, servico
14
ou resultado unico. A natureza temporaria do projecto e definida por uma data de inıcio e de fim. O
encerramento do projecto e ditado pela satisfacao dos objectivos do mesmo ou por um fim previo devido
a impossibilidade de cumprimentos desses objectivos.
Um conceito importante referir e a relacao entre portfolios, programas e projectos. Um portfolio
corresponde a um conjunto de projectos, programas, sub-portfolios e operacoes geridos em conjunto
de forma a atingir objectivos estrategicos. Os programas sao agrupados em portfolios e sao compostos
por sub-programas, projectos e outras actividades que sao geridas de forma coordenada para suportar
o respectivo portfolio. Os projectos, que podem estar contidos num programa, pertencem sempre a um
portfolio. Apesar de os projectos e programas nao estarem directamente ligados entre si, relacionam-se
com a estrategia implementada pela organizacao atraves do portfolio.
Tendo em conta estes conceitos e importante compreender de que forma a sua gestao e distinta
em termos do seu contributo para os objectivos estrategicos da organizacao. A gestao de portfolio
implementa a estrategia da organizacao atraves da escolha de programas e projectos, prioritizando-
os e controlando as dependencias entre si. A gestao de programas harmoniza os varios projectos ou
sub-programas de forma a atingir objectivos e benefıcios especıficos. A gestao de projecto desenvolve
e implementa planos para alcancar objectivos especıficos dentro do ambito do projecto e que sao
conduzidos pela gestao de programas e de portfolios.
A governacao de projectos encontra-se de acordo com o modelo de governacao da organizacao
e fornece ao gestor de projecto e as respectivas equipas um conjunto de processos, ferramentas e
modelos de decisao para gestao dos projectos, enquanto permite o suporte e controlo do sucesso dos
mesmos. A governacao de projectos e distinta da governacao da organizacao, embora estejam em
sintonia para a satisfacao dos objectivos estrategicos da organizacao. A governacao da organizacao
foca-se mais em aspectos estrategicos do negocio e no alcance dos seus objectivos.
O PMBOK apresenta alguns exemplos de elementos que fazem parte da governacao de projectos,
dos quais se destacam os criterios de aceitacao de projectos, processos para a identificacao, escala-
mento, e resolucao de problemas no projecto, processos para a comunicacao de informacao, processos
para tomada de decisoes, processos para definicao e revisao de fases do projecto e processos para
definicao e revisao de alteracoes ao orcamento, ambito, qualidade e calendario.
Segundo o PMBOK, a gestao de projectos e a aplicacao do conhecimento, ferramentas e tecnicas
a actividades de projecto de forma a ir ao encontro dos requisitos identificados. E realizada atraves da
aplicacao e integracao de 47 processos agrupados logicamente e categorizados em cinco grupos de
processos: Processos de iniciacao, processos de planeamento, processos de execucao, processos de
monitorizacao e controlo e processos de encerramento.
Os processos de iniciacao correspondem a definicao de um novo pojecto ou de uma nova fase de
um projecto ja existente, atraves da autorizacao para o inıcio do projecto ou da fase. Os processos de
planeamento correspondem a definicao do ambito, objectivos e actividades para execucao do projecto.
Os processos de execucao definem as actividades a realizar para cumprir o planeamento do projecto
e os respectivos objectivos. Os processos de monitorizacao e controlo definem o controlo, revisao e
monitorizacao do progresso do projecto enquanto que os processos de encerramento formalizam o fim
15
das actividades do projecto.
Alem da divisao dos processos por fases, o PMBOK tambem apresenta uma divisao por areas
de conhecimento, nomeadamente: Gestao da integracao, gestao de ambito, gestao de tempo, gestao
de custos, gestao de qualidade, gestao de recursos humanos, gestao de comunicacoes, gestao de
risco, gestao de compras e gestao de stakeholders. Esta divisao torna-se especialmente interessante
na medida em que nos permite seleccionar quais as areas que queremos cobrir na arquitectura a
desenvolver e aquelas que pretendemos abstrair. No anexo A.5 podemos observar todos os processos
identificados pelo PMBOK divididos por fases de projecto e areas de conhecimento.
Um aspecto importante na utilizacao desta referencia e o seu alinhamento com a ISO 21500, a
principal referencia de processos na gestao de projectos que estamos a considerar, sendo possıvel
encontrar, para todas as fases e areas de processos da ISO 21500, fases e areas de processos no
PMBOK, apresentadas em maior detalhe em termos de actividades, ferramentas e tecnicas a aplicar
no processo.
2.5 Referencias Complementares
Tendo em conta as referencias anteriores e algumas lacunas em aspectos especıficos que pretende-
mos abordar, foi necessario considerar um conjunto de referencias complementares para colmatar es-
sas lacunas. Embora nao sejam aplicaveis na ıntegra, estas referencias detalham alguns aspectos
fundamentais para fornecer o conhecimento necessario a definicao do processo.
Uma das referencias a analisar e o COBIT 5 (Control Objectives for Information and Related Tec-
nhology ) [3], uma framework criada pela ISACA (Information Systems Audit and Control Association)
orientada a gestao e governacao nos sistemas de informacao. Esta referencia sera especialmente im-
portante na area da governacao de projectos, permitindo-nos definir o processo de recepcao e entrega
dos pedidos de projectos e manutencoes, que nao se encontra detalhado em nenhuma das referencias
anteriores.
Outra referencia importante a considerar e o ITIL V3 (Information Technology Infrastructure Library )
[15, 11, 13, 12, 14, 10], que define um conjunto de boas praticas na gestao de servicos de tecnolo-
gias de informacao. Tornou-se a principal referencia nesta area e foi adoptado por organizacoes em
todo o mundo, desde publicas a privadas, permitindo transformar capacidades de gestao de servicos
em mais-valias estrategicas. Apesar de nao estar directamente relacionado com a gestao de pro-
jecto, fornece um conjunto de conhecimentos em areas como a gestao de incidentes, problemas ou
alteracoes, encontrando-se facilmente uma correspondencia com a area da gestao de projectos.
Por ultimo, e considerando a gestao de risco como um tema complexo e de elevado interesse,
considerou-se a ISO 31000 [5], um conjunto de normas internacionais na gestao de risco, como uma re-
ferencia a considerar. Esta norma fornece uma framework e um conjunto de processos para a aplicacao
de princıpios de gestao de risco numa organizacao, independentemente do contexto em que actua.
16
2.5.1 COBIT 5
O COBIT 5 (Control Objectives for Information and Related Tecnhology) e uma framework criada pela
ISACA (Information Systems Audit and Control Association) que auxilia as organizacoes a alcancar os
seus objectivos estrategicos atraves da governacao e gestao dos sistemas de informacao. Tem como
objectivo optimizar o valor de negocio dos sistemas de informacao, mantendo um equilibrio entre os
benefıcios que alcanca, os riscos de negocio e a utilizacao de recursos. Foca-se em cinco prıncipios:
Ir ao encontro das necessidades dos stakeholders, cobrir toda a organizacao, aplicar uma framework
unica e perfeitamente integrada, permitir uma abordagem holıstica e separar a governacao da gestao.
Tendo em conta o ultimo principio, o COBIT defende que existe uma clara distincao entre governacao
e gestao, na medida em que consistem em diferentes tipos de actividades a realizar, estruturas or-
ganizacionais a considerar e possuem diferentes propositos. A governacao garante que as necessi-
dades dos stakeholders sao avaliadas e analisadas de forma a tomar decisoes ponderadas em termos
dos objectivos da organizacao. E responsavel pela orientacao estrategica da organizacao atraves da
prioritizacao e tomada de decisoes, bem pelo controlo da performance e monitorizacao dos objectivos a
alcancar. Por outro lado, a gestao e responsavel pelo planeamento, execucao e controlo de actividades
de acordo com a governacao de forma a alcancar os objectivos da organizacao.
Sao ainda definidos sete elementos facilitadores, que individualmente ou colectivamente, actuam
como elementos que positiva ou negativamente influenciam a governacao. Estes facilitadores, apre-
sentados na figura 2.5, relacionam-se entre si em termos da sua importancia e da sua presenca na
organizacao. Cada um destes elementos possui um conjunto de stakeholders, objectivos, ciclo de vida,
e um conjunto de boas praticas passıveis de serem definidas.
Figura 2.5: Elementos facilitadores da governacao identificados pelo COBIT. Extraıdo de [3].
Em termos do modelo de referencia de processos, apresentado em detalhe em [4], existem dois
grandes domınios de processos, os processos de governacao e os processos de gestao. O domınio da
governacao contem apenas um sub-domınio, denominado Evaluate, Direct and Monitor (EDO), focado
na governacao da organizacao em termos de alcance dos objectivos, optimizacao do risco e recursos e
transparencia com os stakeholders. Relativamente aos domınio dos processos de gestao, sao definidos
quatro sub-domınios:
• Align, Plan and Organise (APO) - Coordena a gestao de projectos, portfolios e operacoes com
17
a governacao da organizacao em termos de recursos, orcamento, nıveis de servico, qualidade,
risco e seguranca, entre outros aspectos.
• Build, Acquire and Implement (BAI) - Processos necessarios ao desenho, acquisicao e implementacao
de solucoes, tanto a nıvel de planeamento como de execucao, incluindo aspectos como gestao
de configuracoes, gestao de alteracoes, gestao de capacidade e disponibilidade, entre outros.
• Deliver, Service and Support (DSS) - Processos para a entrega e suporte de solucoes desen-
volvidas, desde a gestao de problemas, gestao de incidentes, operacoes ou a simples garantia de
continuidade de produtos e servicos.
• Monitor, Evaluate and Assess (MEA) - Processos para a monitorizacao e avaliacao da perfor-
mance da organizacao, do cumprimento dos requisitos e da conformidade com os processos da
organizacao.
O COBIT, embora garanta a cobertura de um vasto conjunto de processos na governacao e gestao
dos sistemas de informacao, possui uma orientacao muito clara a objectivos de controlo e implementacao
da framework, apresentando inclusive a definicao de responsabilidades em cada uma das actividades a
realizar em cada processo. Por essa razao, nao constitui uma das referencias principais, embora possua
uma vasta base de conhecimento, nomeadamente na area da entrega de solucoes e de orientacao aos
objectivos da organizacao, areas que ainda nao se encontravam devidamente cobertas pelas restantes
referencias.
2.5.2 ITIL v3
Inicialmente desenvolvido por um departamento do governo britanico nos anos 80, o ITIL (Informa-
tion Technology Infrastructure Library ) define um conjunto de processos para a gestao de servicos de
tecnologias de informacao. Tornou-se na principal referencia na gestao de servicos, conhecendo-se
implementacoes das praticas que identifica de acordo com os objectivos individuais de organizacoes
publicas e privadas. As praticas de gestao de servicos sao definidas num conjunto de volumes de
acordo com o ciclo de vida considerado para estes servicos. Ao todo sao 5 volumes que partilham a
mesma estrutura conceptual, apresentando praticas fundamentais e princıpios, processos e actividades
do ciclo de vida, estruturas e papeis na organizacao, consideracoes tecnologicas, desafios e praticas
de implementacao, riscos e factores de sucesso:
• Estrategia de servico - Guias para a obtencao de mais-valias estrategias atraves da melhoria
das capacidades de gestao de servico actuais. Apresenta princıpios que sao importantes no
desenvolvimento e implementacao de polıticas e processos para a gestao de servicos. Define os
processos de gestao financeira, gestao de portfolio de servicos e gestao da procura.
• Desenho de servico - Guias para o desenho e desenvolvimento de servicos e praticas orien-
tadas a sua gestao. Cobre princıpios de desenho e metodos para tornar objectivos estrategicos
da organizacao em portfolios de servicos que garantam um conjunto de mais-valias. Define os
18
processos de gestao de catalogo de servicos, gestao de nıvel de servicos, gestao de capacidade,
gestao de disponibilidade, gestao de continuidade de servico, gestao de seguranca de informacao,
gestao de oferta, gestao de aplicacoes, gestao de Informacao e gestao de servicos de negocio.
• Transicao de servico - Guias para a implementacao e melhoria de processos de transicao de
servicos em desenvolvimento ou manutencao para execucao. Define os processos de gestao de
alteracoes, gestao de configuracoes, gestao de instalacao, gestao de conhecimento, gestao de
stakeholders, planeamento da transicao e avaliacao de servico.
• Operacao de servico - Guias de praticas e actividades necessarias na operacao diaria dos
servicos em execucao. Tem como objectivo garantir a eficiencia e eficacia no suporte de servicos,
garantindo a criacao de valor para o cliente e para a organizacao. Define os processos de gestao
de eventos, gestao de incidentes, gestao de problemas, gestao de pedidos e gestao de acessos.
• Melhoria contınua do servico - Guias para a criacao e manutencao do valor para os clientes
atraves da melhoria dos processos de desenho, transicao e operacao de servicos. Inclui proces-
sos de gestao de nıveis de servico e processos de melhoria.
O ITIL V3 fornece uma visao bastante operacional na gestao de servicos, apresentando praticas
concretas a considerar durante o seu ciclo de vida. Apresenta um foco mais operacional para a gestao
de servicos, estando ligado a tematica da gestao de projectos na medida em que estes podem conduzir
a implementacao de servicos, havendo a necessidade de considerar aspectos do ciclo de vida destes
servicos no processo de gestao de projectos.
2.5.3 ISO 31000 - Risk Management - Principles and Guidelines
A ISO 31000 corresponde a um conjunto de normas internacionais orientadas a gestao de risco nas
organizacoes, fornecendo um conjunto de principios genericos aplicaveis a qualquer organizacao pub-
lica, privada ou comunitaria, nao sendo especıfica a nenhuma industria ou sector.
A gestao de risco e uma das areas mais complexas na gestao de projectos, estando directamente
relacionada com todo o ciclo de vida do projecto, e requer um controlo e avaliacao constantes atraves
de diferentes abordagens. A ISO 31000 surge como uma tentativa de normalizar todo o processo de
gestao de risco, tentando integra-lo na organizacao atraves de uma framework de gestao de risco,
aplicavel tanto a nıvel de gestao de projectos como a todos os nıveis de gestao da organizacao.
Esta norma define o risco como o conjunto de factores e influencias internas ou externas que tornam
incerto o alcance dos objectivos da organizacao. Todas as actividades realizadas envolvem risco, tendo
as organizacoes que identifica-lo, analisa-lo e trata-lo de acordo com um conjunto de medidas. Durante
este processo, e necessario executar actividades de comunicacao do risco a stakeholders bem como
monitorizar e rever o tratamento dos riscos de forma a assegurar que nao sao necessarias novas
medidas a aplicar.
A ISO 31000 define a gestao de risco como a coordenacao de actividades de orientacao e controlo
na organizacao relativamente ao risco, apresentando tambem uma framework de gestao de risco que
19
integra os processos de gestao de risco na governacao da organizacao, em aspectos estrategicos, de
planeamento, comunicacao e culturais. Procura ainda alinha-la com um conjunto de princıpios de forma
a ser eficaz, dos quais se destacam:
• A gestao de risco cria e protege o valor da organizacao, sendo parte integrante dos seus proces-
sos;
• A gestao de risco e parte da tomada de decisoes, sendo estruturada, sistematica e baseada na
informacao mais precisa disponıvel;
• A gestao de risco e adaptada a organizacao, sendo dinamica na melhoria continua da organizacao
e dos seus processos;
• A gestao de risco e transparente e envolve toda a organizacao, tendo sempre aspectos humanos
e culturais em conta.
Na figura 2.6 podemos observar a framework proposta pela ISO 31000, utilizada para a implementacao
da gestao de risco nos processos de gestao da organizacao. Esta framework corresponde a uma
implementacao iterativa e dinamica que, de acordo com aspectos de governacao da organizacao, sera
iterativamente desenhada, implementada, revista e melhorada de forma a permanecer alinhada com os
objectivos da organizacao em termos da gestao de risco.
Figura 2.6: Framework de gestao de risco proposta pela ISO 31000. Extraıdo de [5].
Relativamente a fase de implementacao da gestao de risco, esta considera a implementacao dos
processos de gestao de risco identificados na figura 2.7. A definicao do contexto da gestao de risco,
a avaliacao do risco e o seu tratamento correspondem aos principais processos considerados nesta
norma, que se relacionam directamente com os processos de monitorizacao e revisao bem como de
comunicacao, que fornecem aos restantes processos toda a informacao e feedback necessario para
garantir a sua eficacia.
Destaca-se a importancia dos processos de avaliacao (identificacao, analise e avaliacao) e trata-
mento de risco que constituem o nucleo da gestao de risco na organizacao. Os processos de monitorizacao
e controlo bem como os de comunicacao deverao ser analisados tendo em conta os processos de con-
trolo e de comunicacao do projecto, de forma a serem consistentes com estes. Todos os processos de
20
Figura 2.7: Processos de gestao de risco identificados pela ISO 31000. Extraıdo de [5].
gestao de risco apresentados devem ser analisados no contexto da gestao de risco apresentada pelo
conjunto de referencias anteriores, tendo em conta que todas abordam esta tematica, sendo necessario
avaliar quais os aspectos diferenciadores de cada abordagem e quais se enquadram melhor nos objec-
tivos a alcancar.
21
Capıtulo 3
Analise do Problema
Neste capıtulo o problema e analisado em termos do seu contexto e dos constrangimentos que apre-
senta, de forma a ir ao encontro de uma solucao adequada ao mesmo e aos objectivos a alcancar.
Na seccao de definicao geral do problema sao definidos os principais constrangimentos apresen-
tados pelo problema, directamente ligados ao contexto em que actuam o conjunto de organizacoes
consideradas para aplicacao da solucao. Na seccao de motivacao e contexto pratico do problema e
apresentado o caso real da organizacao considerado, que representa uma especializacao do problema
e que introduz um conjunto de constragimentos a versao da arquitectura aplicada ao caso real.
Na seccao de definicao concreta do problema sao apresentados todos os constrangimentos consid-
erados para o problema e para a solucao a desenvolver, que resultam de toda a analise do problema e
que sao aplicaveis as duas versoes da arquitectura.
3.1 Contextualizacao do Problema
Um pedido de execucao de projecto ou manutencao, apresentado a direccao dos sistemas de informacao
de uma organizacao, necessita de ser classificado em projecto ou manutencao, de acordo com aspec-
tos intrınsecos a cada organizacao na forma como distingue estes dois tipos de pedidos. A ISO 21500
define um projecto como um conjunto unico de actividades coordenadas e controladas com uma data
de inıcio e fim definidas, executadas de forma a alcancar os objectivos do projecto. Relativamente as
manutencoes, a ISO/IEC 14764 identifica uma manutencao como uma modificacao apos a entrega da
solucao, de forma a corrigir falhas da mesma. Esta norma divide os pedidos de manutencao em dois
tipos: correctivos e de melhoria, estes ultimos que passaremos a designar de evolutivos.
Esta analise e consequente classificacao do pedido dependera de um conjunto de factores. As-
pectos como o risco para o negocio, o impacto financeiro para a organizacao ou os nıveis de esforco
necessario para implementacao poderao influenciar esta classificacao. Nao havendo um criterio definido,
tudo depende dos aspectos que a organizacao define como diferenciadores destes tipos de oportu-
nidade.
Depois de considerada viavel pela organizacao, a oportunidade deve ser gerida durante todo o seu
22
ciclo de vida ate a sua aceitacao final, nos moldes definidos pela organizacao. Esta gestao implica toda
a analise e planeamento da oportunidade, implementacao da solucao e aceitacao final da mesma de
acordo com os criterios definidos.
Uma das particularidades do problema abordado e considerar-se que a organizacao nao tem capaci-
dade para realizar a implementacao de projectos internamente, sendo esta implementacao realizada
em outsourcing. Este aspecto tem um impacto elevado em todo o desenho da solucao, tendo em
conta que ira definir constragimentos a forma como o projecto e planeado pela direccao de sistemas de
informacao. Tera de ser tido em conta todo o processo de compra da implementacao do projecto, desde
a escolha do parceiro (entidade responsavel pela implementacao do projecto), o controlo do progresso
de implementacao ou mesmo questoes orcamentais e de calendario.
Apesar da implementacao ser feita em outsourcing, terao de ser considerados processos tanto
de planeamento como de controlo, que serao diferentes dos do parceiro, embora contando com a
colaboracao do mesmo. Outro aspecto importante e o facto das implementacoes das manutencoes
tambem poderem ser realizadas em outsourcing, bem como internamente. Neste caso sera uma de-
cisao tomada pela direccao dos sistemas de informacao tendo em conta aspectos como a capacidade
das equipas ou os recursos disponıveis.
Considera-se tambem que todos os pedidos que chegam a direccao de sistemas de informacao
da organizacao sao internos, ou seja, provenientes de areas de negocio da propria organizacao. Este
aspecto tem particular importancia no que diz respeito a aspectos de facturacao e pagamentos do pro-
jecto ou manutencao, que nao serao considerados pelo facto de se tratarem de oportunidades internas
a propria organizacao.
Tendo em conta o ambito alargado do problema, depois da classficacao da oportunidade em pro-
jecto ou manutencao, o problema sera confinado ao processo aplicado a pedidos classificados como
projectos, garantindo que os pedidos de manutencao sao implementados pela organizacao de acordo
com um processo definido ou integrados num servico de manutencao que e realizado em outsourcing.
Pretende-se tambem desenvolver uma solucao a um nıvel de granularidade mais baixo, nao de-
talhando questoes operacionais e de granularidade fina, deixando uma margem de liberdade para
uma implementacao por parte de organizacoes especıficas. Isto e, nao se pretende que o processo
estabeleca de forma fechada um conjunto de tecnicas para executar determinada actividade, confi-
nando a solucao a descricao das actividades a executar e a forma como estas devem ser coordenadas
entre si.
3.2 Motivacao e Contexto Pratico do Problema
O objectivo de considerar um caso real de uma organizacao e o de definir o processo para a gestao de
pedidos de projectos e manutencoes a partir de um contexto real, utilizando entrevistas e sessoes de
esclarecimento para numa primeira fase compreender o processo actual as-is e de forma incremental
desenhar um novo processo de acordo com o conjunto de referencias analisadas no capıtulo 2.
O desenho do processo sera revisto em conjunto com os stakeholders considerados, de forma a ir
23
de encontro com as suas expectativas, sendo tambem a definicao de responsabilidades e documentos
de suporte de acordo com o feedback obtido em reunioes de revisao e entrevistas. Depois de toda
a arquitectura desenhada para o caso real da organizacao, o objectivo sera generaliza-la de forma a
ser aplicavel a um conjunto de outras direccoes de sistemas de informacao, que embora estabelecidas
noutros contextos reais, possam adoptar este processo para a gestao deste tipo de pedidos, tendo
apenas como pressupostos os contragimentos definidos na seccao de contextualizacao do problema.
A direccao de sistemas de informacao encontra-se organizada de acordo com o organograma ap-
resentado na figura 3.1. A entidade maxima corresponde a administracao da direccao de sistemas de
informacao, responsavel por toda a gestao estrategica e por questoes orcamentais, nomeadamente
a aprovacao de orcamentos da direccao de sistemas de informacao. O director DSI corresponde a
entidade que regula as areas de projectos e de manutencoes, sendo o responsavel maximo por es-
tas duas areas, tendo tambem a responsabilidade da gestao de portfolios. A area de planeamento e
controlo (P&C) e responsavel pela gestao operacional de orcamento, realizando alteracoes e revisoes
aos orcamentos de projectos. A area de compras e a area responsavel por conduzir os processos de
compra de implementacoes de projectos e manutencoes, desde a consulta ao mercado a definicao das
minutas de contractos e notas de encomenda. As areas de projectos e manutencao (O&M) sao as
responsaveis pela execucao de projectos e manutencoes, subdividindo-se em equipas de projectos e
equipas de manutencao, cada uma delas tendo um gestor de projecto ou um gestor de manutencao,
respectivamente.
Figura 3.1: Estrutura da organizacao considerada como caso real.
A area de projectos ira comprar a implementacao a terceiros, em outsourcing, embora mantenha
processos de planeamento e controlo do projecto, distintos do parceiro. As implementacoes de manutencoes
poderao ser realizadas internamente ou compradas em regime de outsourcing, ficando a cargo desta
area a decisao, com a aprovacao do director DSI. Relativamente aos pedidos de manutencao, estes
pedidos serao confinados a pedidos de manutencao evolutiva, considerando que a organizacao dispoe
de um servico de Help-Desk de primeira linha que filtra os pedidos que chegam a direccao de sistemas
de informacao.
Relativamente a classificacoes de pedidos entre pedidos de execucao de projectos e de manutencoes
24
evolutivas, a direccao de sistemas de informacao possui um criterio estabelecido que define que a
classificacao e realizada de acordo com um criterio de esforco. Pedidos classificados com um esforco
superior a 5 dias (esforco/homem), constituem pedidos de execucao de projectos enquanto os restantes
contituem pedidos de manutencoes evolutivas.
Todo o processo de compra de implementacoes, quer de projectos quer de manutencoes, e realizado
pela area de compras, que pode ser aconselhada pelas areas de projectos e de manutencoes, tendo
como responsabilidade conduzir todo o processo. E responsavel por seleccionar parceiros de acordo
com um conjunto de criterios de avaliacao, receber propostas, seleccionar a proposta a adjudicar e
definir minutas de contracto e notas de encomenda.
Um projecto so entra em ambiente de producao, que corresponde ao estado final do projecto ja em
funcionamento no ambiente final, apos aprovacao da area de manutencao. Esta aprovacao e feita com
a aceitacao do projecto pela area de manutencao e, apos a passagem a producao, passa a ser sua
responsabilidade. Futuros pedidos de correccao serao enderecados a esta area, que devera possuir
todas as ferramentas e conhecimento necessarios para proceder ao seu tratamento.
3.3 Definicao Concreta do Problema
Considerando este problema, e necessario identificar, tendo em conta um conjunto de referencias na
area de gestao de projectos e manutencoes, quais os processos necessarios definir e de que forma
estes deverao ser coordenados durante todo o ciclo de vida do pedido. Para definir estes processos sera
necessario analisar o conjunto de referencias apresentadas no capıtulo 2 e de seguida identificar um
conjunto de processos a considerar, tendo em conta que a gestao de projectos possui um domınio de
grande dimensao e impossıvel de cobrir na sua totalidade tendo em conta o tempo de desenvolvimento
disponıvel.
Por esta razao, uma das referencias analisadas foi a ISO/IEC 12207, que identifica todos os proces-
sos do ciclo de vida do software e servicos. Importa destacar que a escolha destas areas de processos
foi feita de acordo com um conjunto de entrevistas a stakeholders realizadas durante a definicao dos
objectivos da solucao, resultando num conjunto escolhido de acordo com o feedback recebido de profis-
sionais na area e orientado ao problema que estamos a considerar.
Relativamente a divisao apresentada nesta referencia entre processos no contexto do sistema e
processos no contexto do software, vamos considerar apenas processos do contexto do sistema, na
medida em que nao pretendemos detalhar aspectos operacionais da gestao de projecto, que serao
intrınsecos e correspondentes as praticas especıficas de cada organizacao. Esta decisao procura
tambem deixar espaco de liberdade para a implementacao dos processos por parte da organizacao,
nao a restringindo a decisoes tomadas de acordo com um arquitectura que se procura o mais general-
izada possıvel.
Considerando os processos do contexto do sistema, nao serao considerados os processos tecnicos,
que sao definidos por esta norma internacional como os processos necessarios a definicao de uma
solucao de acordo com requisitos especıficos de um produto de software ou servico. Nao pretendemos
25
uma arquitectura orientada ao desenvolvimento das solucoes mas sim a gestao de projectos, a partir
dos quais estas serao desenvolvidas.
Os processos de projecto serao aqueles que irao ter um maior foco no desenho da arquitectura, na
medida em que identifica processos intimamente ligados a gestao de projecto. Esta referencia consid-
era como processos primarios os processos de planeamento e de controlo de projecto, os quais iremos
tambem considerar para a arquitectura a desenvolver. Directamente relacionados, iremos tambem con-
siderar o processo de gestao de risco e o processo de gestao de decisao. Todos os restantes processos
identificados no contexto dos processos de projecto nao serao considerados por se tratarem de pro-
cessos mais operacionais, como por exemplo a gestao de configuracoes, que deverao ser analisados
numa perspectiva mais orientada a organizacao em si e as solucoes a desenvolver.
Tendo em conta que estamos a considerar a compra das implementacoes de projectos e manutencoes
em outsourcing, sera tambem considerado o processo de aquisicao, na medida em que determina um
conjunto de actividades a realizar para o planeamento e execucao de uma compra de software ou
servico. O processo de fornecimento sera tambem considerado, embora tenha de ser adaptado tendo
em conta que estamos a considerar apenas pedidos internos a organizacao, o que tera influencia num
conjunto de aspectos do processo como a definicao de contractos.
Relativamente aos processos de projecto e de compra, a ISO 21500 e o PMBOK, consideradas
como as pricipais referencias na gestao de projecto, identificam um conjunto de processos, permitindo-
nos seleccionar aqueles a considerar no desenho da arquitectura. Assim, iremos considerar os seguintes
processos relativos aos processos de projecto e de compra da ISO/IEC 12207:
Processos de gestao de projectos Processos
Integracao
- Inıcio do projecto;- Desenvolvimento de planos de projecto;- Monitorizacao e controlo de actividades de projecto;- Controlo de alteracoes;- Encerramento do projecto;- Identificacao de licoes aprendidas;
Stakeholders - Identificacao de stakeholders;- Controlo de stakeholders;
Calendario - Definicao do calendario de projecto;- Controlo do calendario de projecto;
Custos- Identificacao de custos de projecto;- Definicao do orcamento de projecto;- Controlo de custos de projecto;
Riscos
- Identificacao de riscos;- Avaliacao de riscos;- Tratamento de riscos;- Controlo de riscos;
Compras- Planeamento da compra;- Seleccao de parceiros;- Controlo da compra;
Comunicacao- Planeamento das comunicacoes;- Distribuicao da informacao;- Controlo da comunicacao;
Tabela 3.1: Processos de projecto e de compra considerados para o desenho da arquitectura.
Importa destacar que nao serao detalhadas as areas de gestao de ambito e gestao de recursos iden-
tificadas por estas referencias, pois alem de serem areas complexas que nao poderiam ser abordadas
com a necessaria extensibilidade, correspondem a processos directamente ligados a organizacao que
os implementa e ao tipo de projectos que executa, sendo utilizados processos e metodos especıficos e
26
adaptados a contextos especificos de actuacao.
Um processo de gestao de projecto que nao e identificado por nenhuma das referencias e a gestao
de issues. Um issue e definido como um acontecimento que ocorreu e nao foi planeado, sendo
necessario proceder a sua gestao. Pode ser gerado por um risco que tenha ocorrido ou qualquer
tipo de nao-conformidade com planos ou requisitos do projecto. O ITIL apresenta um conjunto de pro-
cessos passıveis de serem adoptados para a gestao de issues, nomeadamente a gestao de problemas
e gestao de incidentes, que serao utilizados para a definicao do processo.
Relativamente aos processos organizacionais, serao considerados apenas os processos de gestao
de portfolio pois consideramos que as oportunidades de projecto e de manutencao sao integradas em
portfolios, sendo estes sujeitos a um processo de gestao de orcamento e calendario com impacto no
planeamento de todos os projectos que deles fazem parte. Apesar de nao ser o foco desta solucao,
decidimos incluir os processos de gestao de portfolio no ambito da arquitectura de processos, embora
sem um detalhe aprofundado.
Os processos de gestao de portfolio e de fornecimento definidos pela ISO/IEC 12207 nao sao de-
talhados pela ISO 21500 e pelo PMBOK, razao pela qual serao consideradas as areas de Align, Plan
and Organise (APO), de Build, Acquire and Implement (BAI) e de Deliver, Service and Support (DSS)
apresentadas pelo COBIT para enderecar estes processos. Sera tambem considerado o caso real da
organizacao como input para a definicao destes processos embora tenha de ser tido em conta que a
gestao de portfolio encontra-se, na maioria das organizacoes, definida de acordo com os seus proprios
objectivos e visao de mercado.
Os processos de fornecimento que iremos considerar correspondem a aceitacao da solucao pro-
duzida, a passagem do projecto para a area de manutencao, a qual sera a responsavel pelo mesmo
a partir do momento da entrega, a passagem de ambiente de qualidade para ambiente de producao
e o encerramento do projecto. Um processo muitas vezes associado ao encerramento do projecto e a
formacao dos utilizadores, que sendo um processo intrınseco ao projecto e as suas caracterısticas, nao
sera considerado na arquitectura.
A recepcao e classificacao de pedidos de projectos e manutencoes nao se encontra directamente
coberta pelas referencias, pelo que sera necessario algum desenvolvimento original com base no caso
real da organizacao. E importante ainda destacar que esta classificacao e intrınseca a organizacao, nao
existindo processos bem definidos para este conjunto de actividades. Encontra-se tambem relacionada
com a governacao da organizacao, que define os conceitos de projectos e manutencoes de acordo
com o seu posicionamento estrategico no mercado e objectivos de negocio. Considera-se assim que
cada organizacao possui um criterio para a classificacao de projectos e manutencoes, sendo esta
classificacao de complexidade variavel de acordo com a organizacao.
Em termos de pedidos de manutencao, considera-se que depois de classificados, sao integrados
em portfolios de servicos de manutencao, que correspondem a servicos comprados em outsourcing, ou
agendados para manutencao. Tendo esta decisao em conta, os processos de gestao da manutencao
serao confinados aos processos de planeamento da manutencao identificados pela ISO/IEC 14764.
27
Capıtulo 4
Solucao
Neste capıtulo e apresentada a solucao proposta para o problema da gestao de pedidos de projectos e
manutencoes, detalhando-se as tres vistas definidas para esta arquitectura: Vista de processos, vista
de responsabilidades e vista de informacao.
Os principais concerns dos stakeholders na gestao de projectos e manutencoes sao assim enderecados
atraves da vista de processos, que identifica o conjunto de actividades a realizar e de que forma de-
vem ser coordenadas, da vista de responsabilidades, que identifica os intervenientes e respectivas
responsabilidades nas actividades definidas e da vista de informacao, que apresenta um conjunto de
documentos de suporte as actividades definidas na vista de processos.
A apresentacao da arquitectura encontra-se dividida em quatro fases conceptuais, directamente
ligadas ao ciclo de vida dos projectos e manutencoes considerado e ao problema enderecado. Cada
fase e identificada por um inıcio e fim bem definidos, correspondendo a pontos estrategicos na gestao
dos projectos e manutencoes na organizacao.
4.1 Arquitectura de Processos
A norma ISO/IEC 42010: Systems and Software Engineering – Architecture Description [9], descreve os
conceitos que devem ser considerados quando se desenvolvem arquitecturas conceptuais de sistemas,
considerando o contexto e os objetivos que se pretendem atingir. De acordo com esta norma, uma
arquitectura corresponde aos principais conceitos e propriedades de um sistema de acordo com o
contexto em que este existe, englobando o conjunto dos seus elementos e relacoes.
Considerando o modelo conceptual apresentado na figura 4.1 e descrito nesta norma, pretende-se
desenvolver uma architecture framework, que identifica um sistema de interesse atraves de um ou mais
concerns do mesmo. Esta framework e definida por viewpoints que coordenam os comportamentos,
responsabilidades e estruturas de informacao na organizacao.
Tendo em conta este modelo conceptual, define-se como sistema de interesse a gestao de projectos
e manutencoes na organizacao, que e enderecada pela arquitectura de processos definida. A direccao
dos sistemas de informacao e a administracao da organizacao, que sao os principais stakeholders,
28
Figura 4.1: Modelo conceptual da arquitectura de processos. Extraıdo de [9].
apresentam um conjunto de concerns associados a este sistema, directamente relacionados com o
conjunto de questoes apresentado na seccao 1.2 de definicao do problema:
• Que processos (e correspondentes actividades) devem ser executados para a gestao de pedidos
de projectos e manutencoes que chegam a direccao dos sistemas de informacao?
• Quais as responsabilidades dos varios elementos da direccao de sistemas de informacao em
todas as actividades de gestao de pedidos de projectos e manutencoes?
• Quais os documentos que suportam todas as actividades realizadas na gestao de projectos e
manutencoes?
4.1.1 Vista de Processos
Um processo de negocio corresponde a um conjunto de actividades e tarefas relacionadas entre si e
coordenadas de forma a alcancar determinados objectivos de negocio. No caso da arquitectura de
processos a desenvolver, pretende-se definir um conjunto de actividades, de acordo com as melhores
praticas identificadas no capıtulo 2, e coordena-las de modo a gerir pedidos de projectos e manutencoes
que chegam a direccao de sistemas de informacao.
Para definir o fluxo de todo o processo de gestao de pedidos de projectos e manutencoes sera
utilizada a linguagem BPMN (Business Process Model and Notation) 2.0. Esta linguagem fornece uma
representacao grafica para a especificacao de processos de negocio, conhecendo uma grande adopcao
por parte de organizacoes em todo o mundo para a definicao dos seus processos, sendo por essa razao
a linguagem de modelacao escolhida para a definicao desta vista.
Tendo em conta que o fluxo do processo e apresentado em termos de macro-actividades, sao ainda
apresentadas um conjunto de actividades detalhadas referentes a cada macro-actividade. A definicao
de cada actividade detalhada foi baseada nas referencias analisadas no capıtulo 2, cujos processos de
29
gestao apresentavam um conjunto de actividades e objectivos a cumprir, a partir dos quais foi feita a
adaptacao para os objectivos especıficos desta arquitectura.
Na figura 4.2 e apresentado o fluxo completo do processo de gestao de projectos e manutencoes
desenvolvido. O processo foi dividido em quatro fases, de acordo com a vista de processos apresen-
tada. Assume-se que uma fase do processo possui um inıcio e fim bem definidos, sendo nestes pontos
alcancados objectivos estrategicos da organizacao. As fases de oportunidade, de planeamento, de
implementacao e controlo e de handover constituem todo o ciclo de vida do pedido de projecto desde
que e recebido pela direccao dos sistemas de informacao, vindo da area de negocio, ate a entrega
e encerramento do projecto. Os pedidos que sejam classificados como manutencoes, apos a fase
de oportunidade, sao integrados em portfolios de servicos de manutencao ou sao agendados para
implementacao.
Figura 4.2: Fluxo completo do processo de gestao de projectos e manutencoes.
4.1.2 Vista de Responsabilidades
Na vista de responsabilidades sao atribuıdas, para cada uma das actividades detalhadas definidas
na vista de processos, um conjunto de responsabilidades aos elementos da direccao de sistemas de
informacao. Para a definicao desta vista foi considerada a estrutura organizacional da direccao de
sistemas de informacao do caso real considerado. Para cada actividade, os intervenientes do processo
possuem um conjunto de responsabilidades de acordo com o seu papel na organizacao e com as
actividades que devem executar.
A vista de responsabilidades e traduzida, por cada fase, numa matriz de responsabilidades, que
relaciona actividades a executar e intervenientes do processo atraves de um conjunto de responsabili-
dades definido de acordo com um modelo de responsabilidades. O modelo mais comum de definicao de
responsabilidades e o modelo RACI (Responsible, accountable, Consulted and Informed), que define
as seguintes responsabilidades:
30
• Responsible - Elemento com a responsabilidade de executar a actividade, havendo no mınimo
um elemento com esta responsabilidade.
• Accountable - Elemento com autoridade na execucao da actividade, sendo o principal responsavel
pela sua concretizacao e o qual delega a responsabilidade de execucao da actividade.
• Consulted - Elemento cujas opinioes e conhecimentos sao tidos em conta na execucao da ac-
tividade, e com o qual existe comunicacao bilateral.
• Informed - Elemento que deve ser informado do progresso da actividade, correspondendo a uma
comunicacao unilateral.
Apesar deste modelo ser amplamente adoptado pelas organizacoes, decidiu-se considerar um mod-
elo extendido, o qual designamos por matriz de responsabilidades e que foi proposto por Grude e Haug
[1], que apresenta a seguinte definicao de responsabilidades:
• X - Elemento responsavel por executar as tarefas a realizar na actividade.
• D - Elemento com poder de decisao individual e final num ponto de decisao do processo.
• d - Elemento com poder de decisao em conjunto, podendo influenciar a decisao tomada por um
elemento com uma responsabilidade de decisao individual.
• P - Elemento responsavel por assegurar que as actividades sao planeadas, implementadas e
controladas. Muitas vezes esta responsabilidade e delegada tambem a outros elementos mais
proximos dos responsaveis pela execucao das actividades.
• C - Elemento que deve ser consultado, possuindo informacoes que devem ser tidas em conta
no controlo de progresso, execucao de actividades e tomadas de decisao. Apesar de haver uma
obrigatoriedade de consulta, este elemento nao possui qualquer responsabilidade de decisao,
podendo a sua opiniao ser ignorada.
• A - Elemento a consultar opcionalmente, podendo possuir informacoes e opinioes numa fase do
projecto cuja importancia so pode ser avaliada nessa mesma fase.
• I - Elemento que deve ser informado da execucao, decisao ou controlo da actividade, correspon-
dendo a uma comunicacao unilateral.
A adopcao deste modelo na arquitectura de processos tem em vista a definicao de uma vista de
responsabilidades detalhada face a apresentada pela RACI, apresentando uma maior extensao no que
diz respeito a definicao de responsabilidades de decisao e de trocas de informacao.
A definicao da vista de responsabilidades, em contraste com a vista de processos, foi desenvolvida
atraves de trabalho original, nao sendo apresentada nenhuma proposta no conjunto das referencias
analisadas no capıtulo 2. Assim, foi necessario analisar a estrutura organizacional da direccao dos
sistemas de informacao, compreender quais os principais elementos e responsabilidades actuais e, de
acordo com a vista de processos definida, atribuir um conjunto de responsabilidades aos elementos
nas actividades identificadas.
31
4.1.3 Vista de Informacao
A vista de informacao define um conjunto de documentos de suporte ao processo de gestao de pro-
jectos e manutencoes. Esta vista relaciona-se com as anteriores na medida em que apresenta um
conjunto de documentos produzidos e consumidos pelas actividades definidas na vista de processos,
que sao utilizados pelos intervenientes no processo, identificados na vista de responsabilidades.
O objectivo desta vista e identificar o conjunto de documentos de suporte ao processo, descrevendo
a informacao contida e os respectivos objectivos. Estes documentos foram propostos tendo em conta
as referencias analisadas e um conjunto de necessidades especıficas relacionadas com o caso real
considerado. Este conjunto de documentos encontra-se adaptado a arquitectura desenvolvida, podendo
ser extendido ou adaptado numa implementacao desta arquitectura.
Alem desta descricao, pretende-se ainda apresentar de que forma os elementos da direccao dos
sistemas de informacao interagem com estes documentos, apresentando quais as entidades que criam,
consultam e alteram os varios documentos ao longo do processo. Por essa razao, considerou-se o
conceito de matriz de interaccoes, ou matriz CRUD (Create, Read, Update and Delete), amplamente
utilizado na definicao de arquitecturas de informacao nos sistemas de informacao, nas quais estas
matrizes sao usadas para descrever um conjunto de interaccoes de criacao, leitura, escrita e remocao
de informacao entre intervenientes e fontes de infomacao. Este conceito foi inspirador para a definicao
desta vista de informacao, levando a definicao do conceito de matriz CRUF:
• C - Criacao do documento.
• R - Obrigatoriedade de consulta do documento, embora a ausencia desta interaccao nao seja
impeditiva da consulta opcional do mesmo.
• U - Actualizacao ou alteracao do documento.
• F - Fecho do documento, com o arquivamento do mesmo para posterior consulta.
Assim, para cada fase do processo definida nesta arquitectura, e apresentada uma matriz CRUF que
relaciona os intervenientes com os documentos de suporte correspondentes a essa fase. A adopcao
desta matriz foi considerada durante o desenvolvimento da arquitectura de processos de forma a com-
plementar a vista de informacao e relaciona-la com as duas outras vistas, sendo uma proposta aceite
por todos os stakeholders na medida em que apresenta, de forma inovadora, uma nova visao na
definicao de interaccoes com o conjunto de documentos de suporte do processo.
4.2 Fase de Oportunidade
Na fase de oportunidade e feita a identificacao e respectiva classificacao do pedido recebido em opor-
tunidade de projecto ou de manutencao, podendo esta oportunidade ainda ser rejeitada. Caso seja
aceite, e iniciado o planeamento da oportunidade em termos de ambito, orcamento, calendario e analise
32
tecnica. Oportunidades de manutencao que nao tenham sido agendadas para implementacao sao in-
tegradas em portfolio, procedendo-se a uma definicao de orcamento, calendario e prioridade. Na figura
4.3 e apresentado o fluxo do processo relativo a fase de oportunidade.
Figura 4.3: Fluxo do processo relativo a fase de oportunidade.
4.2.1 Vista de Processos
De acordo com o fluxo do processo apresentado na figura 4.3 o processo inicia-se com a chegada
do pedido a direccao de sistemas de informacao. Todos os pedidos sao recebidos pela area de
projectos, aquela que possui elementos com a capacidade de analise do pedido em termos da sua
classificacao em projecto ou manutencao. Este pedido representa uma necessidade identificada pela
area de negocio e nesta fase do processo, e realizada uma analise a dois nıveis:
• Analise de negocio, a partir da qual e definido o caso de negocio que avalia a oportunidade em
termos de benefıcios para a organizacao.
• Analise de solucao, a partir da qual e definido o statement of work onde sao identificados os
resultados esperados com a aceitacao da oportunidade.
Estas analises serao necessarias na classificacao da oportunidade em projecto ou manutencao, a
qual e estabelecida em termos de uma definicao de esforco na concretizacao da oportunidade (esforco
por elemento de equipa) realizada tendo em conta o statement of work, definido previamente. Tendo
em conta o caso real considerado, uma oportunidade cujo nıvel de esforco para concretizacao e avali-
ado em cinco ou mais dias de trabalho por elemento da equipa, e classificada como projecto. Caso
33
contrario, tratar-se-a de uma oportunidade de manutencao. Na arquitectura definida considera-se que
a classificacao e baseada num criterio de esforco, embora nao impondo nıveis de classificacao.
E tambem realizada uma analise de viabilidade da oportunidade, embora no caso real considerado
uma oportunidade seja apenas rejeitada caso a direccao dos sistemas de informacao nao possua re-
cursos humanos suficientes para a sua aceitacao. Esta questao prende-se com o facto da organizacao
possuir um conjunto de mais-valias associadas ao numero de oportunidades aceites, pelo que tem
interesse em aceitar o maior numero possıvel. Importa tambem destacar que toda as actividades de
identificacao e classificacao da oportundidade sao realizadas em colaboracao entre as areas de pro-
jectos e manutencoes, como sera perceptıvel na vista de responsabilidades. Na tabela 4.1 sao apre-
sentadas as actividades detalhadas referentes as macro-actividades de identificacao e classificacao da
oportunidade.
Actividades
GPM-OP1 – Identificacao da oportunidade – Inıcio da identificacao do pedido com a definicao do caso de negocio edo statement of work.
GPM-OP1.1 – Registo da oportunidade em sistema de tracking.
GPM-OP1.2 – Atribuicao de um responsavel pela qualificacao da oportunidade.
GPM-OP1.3 – Definicao do caso de negocio da oportunidade de acordo com a identificacao apresentada.
GPM-OP1.4 – Definicao do statement of work de acordo com a identificacao da oportunidade realizada.
GPM-OP2 – Classificacao da oportunidade – Atribuicao de uma area ao pedido e responsavel pela sua gestao.
GPM-OP2.1 – Classificacao do pedido como projecto ou manutencao evolutiva com base numa analise de esforco(esforco/homem).
GPM-OP2.2 – Reuniao conjunta de elementos de projectos e de O&M para analise preliminar da viabilidade da oportunidade.
GPM-OP2.3 – Decisao de aceitacao da oportunidade de acordo com a classificacao realizada e a analise de viabilidade daoportunidade.
GPM-OP2.4 – Inıcio da definicao do project charter : responsavel pelo projecto, respectivas responsabilidades e a entidadeque aprova o projecto.
Tabela 4.1: Actividades detalhadas de identificacao e classificacao da oportunidade.
Caso a oportunidade seja classificada como um projecto, e realizada uma analise da oportunidade
em termos de requisitos funcionais, calendario, orcamento, riscos e solucao tecnica. Nesta fase, a area
de projectos pode realizar uma reclassificacao do pedido, caso considere que a oportunidade se trate
de uma manutencao e que a classificacao inicial nao tenha sido a correcta. Da analise da oportunidade
de projecto resulta o project charter, que sera utilizado para obtencao de aprovacao da oportunidade e
para o inıcio do planeamento do projecto.
Apos esta analise, a oportunidade e integrada num portfolio de projectos, que reune o conjunto de
oportunidades de projecto consideradas pela organizacao. Nesta fase, a analise anterior e reavaliada
numa perspectiva do conjunto de projectos que compoem o portfolio, sendo atribuida uma prioridade a
oportunidade, em funcao das restantes que compoem o mesmo, bem como realizada uma reavaliacao
de orcamento e calendario. Este portfolio e gerido pela area de projectos, e sera depois submetido
para avaliacao ao director DSI, que ira considerar o conjunto de portfolios da direccao de sistemas de
informacao e gerir as varias oportunidades de acordo com aspectos de governacao da organizacao.
Na tabela 4.2 sao apresentadas as actividades detalhadas referentes as macro-actividades de analise
34
da oportunidade e de integracao em portfolio.
Actividades
GPM-OP3 – Analise da oportunidade – Primeira abordagem a gestao do pedido com definicao de ambito, stakehold-ers, milestones e estimativa de alto nıvel de orcamento.
GPM-OP3.1 – Identificacao de alto nıvel dos stakeholders do projecto.
GPM-OP3.2 – Definicao dos objectivos, criterios de sucesso, assumpcoes e,constrangimentos de alto nıvel do projecto.
GPM-OP3.3 – Definicao de requisitos funcionais de alto nıvel do projecto baseados no statement of work.
GPM-OP3.4 – Definicao de esboco de solucao de alto nıvel tecnica do projecto de forma a auxiliar no planeamento demilestones e orcamento do projecto.
GPM-OP3.5 – Analise e decisao de reclassificacao do pedido de projecto em pedido de manutencao com base na analisetecnica e de requisitos do projecto.
GPM-OP3.6 – Definicao de milestones de alto nıvel do projecto.
GPM-OP3.7 – Definicao de alto nıvel de estimativa de orcamento do projecto.
GPM-OP3.8 – Identificacao de alto nıvel dos riscos associados ao projecto e a sua aceitacao pela organizacao.
GPM-OP4 – Integracao em portfolio de projectos – Gestao de portfolios de projecto com a definicao de score, cal-endario e orcamento de cada uma das oportunidades que compoem o portfolio.
GPM-OP4.1 – Atribuicao de score do projecto no contexto do portfolio de projectos, definindo a prioridade e importancia desteprojecto face aos restantes que compoem o portfolio.
GPM-OP4.2 – Definicao de estimativa de calendario do projecto no contexto do portfolio de projectos, tendo em conta asmilestones do projecto e os restantes projectos que compoem o portfolio.
GPM-OP4.3 – Definicao de orcamento do projecto no contexto do portfolio de projectos, analisando o orcamento totaldisponıvel para o portfolio e que sera futuramente submetido para aprovacao.
Tabela 4.2: Actividades detalhadas de analise da oportunidade e integracao em portfolio de projectos.
No caso de uma oportunidade classificada como manutencao, e realizada uma analise da oportu-
nidade de forma a identificar os requisitos da manutencao e realizar um esboco da solucao tecnica,
que ira permitir proceder a uma analise de esforco e a uma estimativa dos recursos necessarios e de
orcamento. Nesta macro-actividade e ainda tomada a decisao de compra da manutencao na forma
de servico de manutencao ou de implementacao interna pela area de manutencao. Tendo em conta a
analise de recursos necessarios e a capacidade da area de manutencao, e necessario avaliar se esta
area possui os recursos necessarios para realizar a implementacao e se e a opcao mais benefica para
a organizacao. Caso a area de manutencao conclua que nao possui capacidade para implementar a
manutencao, esta sera integrada num servico de manutencao, realizado em outsourcing e que na maio-
ria dos casos reune uma bolsa de horas, disponıveis para um conjunto de actividades de manutencao.
Caso seja tomada a decisao de implementacao interna, sera realizado o planeamento da manutencao,
com a alocacao de recursos, a definicao de calendario e o agendamento da manutencao no back-
log de operacoes de manutencao da area de manutencao. Apos esta actividade, considera-se que a
organizacao dispoe de um processo para a implementacao do conjunto das manutencoes pertencentes
ao backlog de manutencao.
No caso de integracao num servico de manutencao, e necessario, numa primeira fase, de acordo
com a analise de esforco realizada para a oportunidade, integra-la num servico de manutencao per-
tencente ao portfolio de servicos da organizacao, sendo depois realizada uma revisao da prioridade do
servico e do orcamento no contexto do portfolio de servicos de manutencao. Este portfolio, de forma
paralela ao que acontece com o portfolio de projectos, pertence a area de manutencao.
35
Depois da gestao da oportunidade por parte da area de projectos ou manutencao, de acordo com
a sua classificacao, sera realizada uma analise de portfolio por parte do director DSI, que entre out-
ros aspectos, ira rever questoes de orcamento, calendario e prioridades de projectos e manutencoes
pertencentes aos portfolios da direccao de sistemas de informacao. Esta analise tem como objectivo
a definicao do orcamento anual da direccao de sistemas de informacao, que deve ser submetido para
aprovacao a administracao de forma a garantir que todas as oportunidades consideradas se encontram
aprovadas para o inicio do seu planeamento. Estas actividades nao serao consideradas nesta versao
da arquitectura, embora desenvolvidas no ambito da arquitectura aplicada ao caso real, por serem
especıficas a organizacao e a sua estrutura organizacional.
4.2.2 Vista de Responsabilidades
Os principais intervenientes na fase de oportunidade sao a area de projectos e a area de manutencao,
executando todas as actividades com o auxılio da area de planeamento e controlo em questoes orcamentais,
do director DSI em tomadas de decisao de aceitacao e classificacao da oportunidade e da area de
negocio, responsavel pela apresentacao da oportunidade a direccao de sistemas de informacao.
A identificacao da oportunidade e realizada pela area de projectos, que recebe o pedido e atribui
um responsavel pela qualificacao da oportunidade, em acordo com o director DSI. Nestas actividades,
a area de O&M, o director DSI e a area de negocio desempenham um papel de aconselhamento,
sendo consultadas para actividades como a definicao do statement of work ou do caso de negocio. A
classificacao da oportunidade tambem e realizada na sua totalidade pela area de projectos, em parceria
com a area de O&M, que e consultada durante toda a actividade, e com o director DSI, responsavel pela
decisao final de aceitacao da oportunidade. Na tabela 4.3 e apresentada a matriz de responsabilidades
referente as actividades de identificacao e de classificacao da oportunidade.
Actividades Projectos O&M P&C Director
DSINegocio
GPM-OP1 – Identificacao da oportunidade
GPM-OP1.1 X/P A I
GPM-OP1.2 X/P/d A D I
GPM-OP1.3 X/P I C
GPM-OP1.4 X/P C C
GPM-OP2 – Classificacao da oportunidade
GPM-OP2.1 X/P C
GPM-OP2.2 X/P C I
GPM-OP2.3 X/P/d A D I
GPM-OP2.4 X/P A
Tabela 4.3: Matriz de responsabilidades das actividades de identificacao e analise da oportunidade.
A analise da oportunidade de projecto e realizada na totalidade pela area de projectos, estando a
area de manutencao, a area de planeamento e controlo, o director DSI e a area de negocio disponıveis
para ser consultados e fornecer aconselhamento na analise tecnica, de orcamento, de calendario e de
36
riscos. Ja na integracao em portfolio de projectos, a area de projectos executa todas as actividades em
parceria com o director DSI, que e consultado em todas as actividades, e com a area de planeamento
e controlo, consultada em aspectos orcamentais. Na tabela 4.4 e apresentada a matriz de responsabil-
idades referente as actividades de analise da oportunidade de projecto e de integracao em portfolio de
projectos.
Actividades Projectos O&M P&C Director
DSINegocio
GPM-OP3 – Analise da Oportunidade
GPM-OP3.1 X/P A C
GPM-OP3.2 X/P C
GPM-OP3.3 X/P C
GPM-OP3.4 X/P A A
GPM-OP3.5 X/P/D A C
GPM-OP3.6 X/P A C
GPM-OP3.7 X/P C A
GPM-OP3.8 X/P A A A A
GPM-OP4 – Integracao em Portfolio de Projectos
GPM-OP4.1 X/P C
GPM-OP4.2 X/P A C
GPM-OP4.3 X/P C C
Tabela 4.4: Matriz de responsabilidades das actividades de analise da oportunidade e integracao emportfolio de projectos.
A analise da oportunidade de manutencao e feita na totalidade pela area de manutencao, sendo
consultada a area de negocio para a definicao de requisitos de manutencao e a area de planeamento
e controlo para a definicao do orcamento. A decisao de implementacao da manutencao interna ou de
compra sob a forma de servico de manutencao e realizada pela area de manutencao e pelo director DSI,
pertencendo a este ultimo a decisao final. Caso a manutencao seja implementada internamente, todas
as actividades sao executadas pela area de manutencao, tendo esta apenas de informar o director DSI
e a area de negocio do agendamento da implementacao da manutencao. No caso da manutencao ser
integrada num servico de manutencao, as actividades sao executadas pela area de manutencao com o
auxılio da area de planeamento e controlo e do director DSI.
As responsabilidades identificadas nesta fase encontram-se intimamamente ligadas a estrutura da
organizacao, que define constrangimentos concretos a recepcao do pedido e a sua classificacao. O
facto da recepcao e classificacao da oportunidade ser feita pela area de projectos define de forma
restrita o conjunto de responsabilidades nestas actividades. O papel da area de manutencao como
entidade a ser consultada nestas actividades foi proposto tendo em conta este constrangimento, de
forma a envolver as duas principais areas que irao gerir posteriormente o projecto ou a manutencao.
Apos a classificacao, a definicao de responsabilidades encontra-se normalizada com a maioria dos
casos reais das organizacoes que possuem areas distintas para lidar com pedidos de projectos e pedi-
dos de manutencoes. Cada uma das areas lida com as suas oportunidades separadamemente, embora
37
com trocas de informacao entre si de forma a partilhar informacoes, resultados e objectivos em comum.
4.2.3 Vista de Informacao
A fase de oportunidade inicia-se com o registo da oportunidade num sistema de tracking de pedidos
na direccao dos sistemas de informacao. Este registo apresenta a primeira definicao da oportunidade
do ponto de vista do negocio, podendo ser complementado por informacao proveniente do elemento
responsavel pela recepcao dos pedidos. O registo da oportunidade fornece informacao que, em con-
junto com o feedback proveniente da area de negocio, permite definir o statement of work e o caso de
negocio.
O caso de negocio e o statement of work sao dois documentos que se complementam no que
diz respeito a caracterizacao da oportunidade. O caso de negocio apresenta a oportunidade em ter-
mos de investimento e oportunidade de negocio, identificando um conjunto de benefıcios esperados e
resultados a alcancar. O statement of work possui um caracter mais orientado aos resultados espera-
dos, identificando os produtos ou servicos pretendidos para colmatar um determinada necessidade de
negocio.
O project charter corresponde a um pre-plano de projecto, sendo composto pela analise inicial da
oportunidade classificada como projecto. E utilizado para obter autorizacao e identificar o responsavel
pelo projecto, reunindo toda a analise realizada na fase de oportunidade. E considerado pela maioria
das referencias em gestao de projecto como um documento que fornece autorizacao ao gestor de pro-
jecto para aplicar um conjunto de recursos da organizacao a actividades do projecto. Num paralelismo
com as oportunidades de projecto, definimos o maintenance charter, um documento que possui os
mesmos objectivos do project charter mas aplicado as oportunidades de manutencao.
A fase de oportunidade termina com a integracao das oportunidades em portfolios de projectos
ou de manutencoes, que agrupam um conjunto de oportunidades geridas em conjunto para alcancar
objectivos estrategicos da organizacao. Todos os documentos de suporte identificados na fase de
oportunidade sao detalhados na tabela A.1 no anexo A.1.
Tendo em conta a matriz de CRUF da fase de oportunidade, representada na tabela 4.5, todos
os documentos desta fase sao criados pela area de projectos ou de manutencao por serem unicos a
oportunidade recebida, com excepcao dos portfolios de projectos e manutencoes que sao comuns a
todas as manutencoes e projectos levados a cabo pela direccao de sistemas de informacao.
A vista de informacao encontra-se intimamente ligada com a vista de responsabilidades, na medida
em que as entidades que criam e alteram os documentos sao, na sua maioria, as mesmas entidades
responsaveis pela execucao das actividades nas quais esses documentos sao produzidos. E o caso do
project charter e do maintenance charter, criados e actualizados na fase de oportunidade pela area de
projectos e pela area de manutencao, respectivamente.
Importa tambem destacar a interaccao apenas de consulta para os portfolios de projectos e de
manutencoes por parte do director DSI. Tendo em conta que nao estamos a considerar aspectos de
gestao de Portfolio, assume-se que o director DSI nao executa qualquer tipo de analise e alteracoes aos
38
Documentos de suporte Projectos O&M P&C Director DSI Negocio
Registo da oportunidade C/U R R R
Caso de negocio C/U R R R
Statement of work C/U R R R
Project charter C/U R R R
Maintenance charter R C/U R R
Portfolio de projectos C/U R R
Portfolio de manutencoes C/U R R
Tabela 4.5: Matriz CRUF dos documentos de suporte da fase de oportunidade.
projectos e manutencoes pertences aos portfolios, sendo por isso uma interaccao apenas de consulta.
4.3 Fase de Planeamento
A fase de planeamento inicia-se com uma revisao da analise da oportunidade e com a definicao dos
planos de gestao de stakeholders, gestao de comunicacoes e gestao de risco. E nesta fase que tambem
e realizado todo o processo de compra da implementacao do projecto em outsourcing, sendo definido o
plano de gestao de compra e realizadas a consulta ao mercado, a seleccao da proposta a adjudicar e a
definicao do contracto de compra. Apos este processo de compra, e feito o planeamento de calendario
e custos do projecto, sendo definidos os planos de gestao de calendario e de gestao de custos. No final
desta fase e dado inıcio ao processo de implementacao do projecto.
4.3.1 Vista de Processos
Apos a fase de oportunidade, as oportunidades de manutencao encontram-se integradas em servicos
de manutencao ou agendadas para implementacao, possuindo a organizacao processos especıficos
para a sua gestao. No que diz respeito as oportunidades de projecto, estas encontram-se integradas
num portfolio de projectos, cujo orcamento e calendario se encontra bem definido em termos de
portfolio. Porem, e necessario realizar todo o planeamento do projecto individualmente, de forma a
detalhar toda a analise realizada na fase de oportunidade apresentada no project charter.
A fase de planeamento inicia-se com a gestao de stakeholders, de riscos e de comunicacoes, que
procura aprofundar toda a analise realizada na fase de oportunidade e definir os respectivos plano de
gestao. O fluxo do processo relativo a estas actividades e apresentado na figura 4.4.
No inıcio da fase e revisitado todo o planeamento da oportunidade realizado, com a revisao do
statement of work e do caso de negocio face aos novos desenvolvimentos do projecto. E tambem anal-
isada toda a informacao detalhada no project charter relativa a stakeholders do projecto, especificacoes
tecnicas, requisitos funcionais e riscos identificados. No final desta actividade o project charter, iniciado
na fase de oportunidade, e encerrado, passando toda a analise revista a fazer parte do plano de gestao
de projecto, que ira reunir todo o planeamento e controlo do mesmo ate ao seu encerramento. O gestor
de projecto define ainda o conjunto de responsabilidades no planeamento do projecto por parte dos
39
Figura 4.4: Fluxo do processo relativo a gestao de stakeholders, riscos e comunicacoes na fase deplaneamento.
elementos da sua equipa, sendo definido um plano de trabalho para esta fase.
A gestao de stakeholders do projecto e iniciada pela identificacao de indivıduos, grupos ou organizacoes
que afectam ou sao afectados pelo projecto. Esta actividade e especialmente importante tendo em
conta que estes elementos sao partes integrantes de todo o processo, possuindo informacao relevante
e um conjunto de interesses que sera fundamental para o sucesso do projecto. E realizado um levanta-
mento de informacao de stakeholders, que ira complementar toda a informacao ja recolhida durante a
fase de oportunidade. Apos o levantamento da informacao, sao realizadas um conjunto de entrevistas
e avaliacoes de stakeholders em termos de requisitos, expectativas e impacto no projecto de acordo
com os metodos de avaliacao adoptados pela organizacao. Considerando esta avaliacao, e possıvel
definir um perfil para cada stakeholder, identificando o seu posicionamento face ao projecto em termos
de participacao, resistencia ou apoio. No final da actividade sao realizadas reunioes de familiarizacao
com os stakeholders, com o objectivo de aproxima-los com a equipa e com todo o processo de desen-
volvimento do projecto, facilitando futuras comunicacoes.
Numa segunda fase, e elaborado o plano de gestao de stakeholders, que integrara o plano de
gestao de projecto e possibilitara compreender e gerir as necessidades e expectativas de cada um dos
stakeholders identificados. Sera realizada uma analise de participacao dos stakeholders nas fases de
projecto, identificando a sua importancia e em que termos esta participacao sera feita. Serao tambem
identificadas actividades de comunicacoes com os stakeholders, desde as previstas pelos mesmos
como requisitos de planeamento do projecto ate a sugestoes de novas comunicacoes identificadas
pela equipa de projecto. Tendo em conta que existem um conjunto de stakeholders distintos, com
diferentes objectivos e interesses, sera necessario realizar uma analise de relacoes entre stakeholders
e de impacto de alteracoes. Em momentos de negociacao com stakeholders e necessario uma grande
diplomacia e gestao de interesses, pelo que esta analise sera fundamental de forma a ir ao encontro
das expectativas de todos os interessados no projecto.
Nesta fase do processo e tambem definido o plano de gestao de riscos, assegurando que oportu-
nidades e ameacas que introduzam um grau de incerteza no projecto sejam geridas de acordo com os
objectivos da organizacao e dos stakeholders. Assim, e definido o metodo de gestao de risco a utilizar
no projecto, muitas vezes proprietario da propria organizacao que identifica todas as actividades a re-
alizar nas varias fases da gestao do risco e de que forma estas devem ser coordenadas entre si. Sao
definidas responsabilidades no processo de gestao de risco e realizada uma estimativa de orcamento
40
para a gestao de risco. Esta estimativa ira ser incluıda no orcamento global do projecto e tem como
objectivo cobrir todas as despesas envolvidas nas actividades de gestao de risco e nos planos de con-
tingencia. E tambem feita a calendarizacao de todas as actividades, sendo detalhadas a duracao e
periodicidade de actividades de identificacao, analise e tratamento de risco. Directamente relacionado
com o planeamento de comunicacoes, sera definido o metodo de registo e comunicacao do processo
de gestao de risco, que embora se encontre definido no metodo considerada, sera alvo de pequenos
ajustes de acordo com o projecto especıfico a que se destina.
Terminado o planeamento da gestao de stakeholders e do risco, e realizado o planeamento de
comunicacoes, com a definicao do plano de gestao de comunicacoes. Est actividade tem ja em conta
um conjunto de resultados em termos de comunicacao das actividades anteriores, nomeadamente no
planeamento de comunicacoes com os stakeholders e no processo de gestao de risco. Nesta actividade
sao definidos os requisitos, como a periodicidade e frequencia da comunicacao, intervenientes e canais
de comunicacao do projecto, bem como metodos e tecnologias a utilizar. Sera ainda definido um
conjunto de responsabilidades nas comunicacoes planeadas no projecto.
Apos o planeamento de comunicacoes, e dado inıcio ao procedimento de compra e posterior definicao
do plano de gestao de calendario e do plano de gestao de custos, como apresentado na figura 4.5.
Figura 4.5: Fluxo do processo relativo ao procedimento de compra e gestao de calendario e de custos.
Durante a compra, a execucao das actividades passam a ser responsabilidade da area de compras,
que actua de acordo com processos definidos e regulamentados pela organizacao. Importa destacar
que o procedimento de compra e intrınseco a cada organizacao, dependendo de aspectos organicos da
mesma. Organizacoes publicas e privadas, por exemplo, possuem processos de compra distintos na
medida em que sao alvo de diferentes regulamentacoes ou geridas de acordo com polıticas distintas.
O procedimento de compra desenhado possui como principais referencias os processos de compra
apresentados pela ISO 21500 e pelo PMBOK, sendo complementados pelo caso real considerado,
distanciando-se do praticado actualmente na organizacao e correspondendo a uma proposta generica
de um procedimento de compra. As actividades detalhadas sao apresentadas na tabela 4.6.
A preparacao das actividades de compra inicia-se com o planeamento da compra, sendo definida
41
Actividades
GPM-PL6 - Planeamento da compra - Preparacao das actividades de compra com a definicao da especificacaotecnica, criterios de avaliacao de propostas e plano de gestao de compra.
GPM-PL6.1 - Definicao e validacao da especificacao tecnica e dos requisitos da compra para integrar o procurement statementof work.
GPM-PL6.2 - Revisao do orcamento do projecto com a definicao do orcamento detalhado da compra de acordo com o planoanual de compras da direccao dos sistemas de informacao.
GPM-PL6.3 - Definicao do calendario da compra de acordo com as milestones de compras definidas no plano anual decompras da direccao dos sistemas de informacao.
GPM-PL6.4 - Identificacao e analise de riscos de compras.
GPM-PL6.5 - Definicao dos criterios de avaliacao das propostas de parceiros.
GPM-PL6.6 - Reuniao de validacao do procedimento de compra.
GPM-PL7 - Consulta ao mercado - Inıcio do perıodo de consulta ao mercado, com a recepcao de propostas de par-ceiros e realizacao de pedidos de esclarecimentos.
GPM-PL7.1 - Abertura do perıodo de consulta ao mercado de acordo com o calendario da compra.
GPM-PL7.2 - Criacao de carteira de propostas a adjudicar pela organizacao para a implementacao do projecto.
GPM-PL7.3 - Realizacao de pedidos de esclarecimentos relativos a propostas de parceiros.
GPM-PL8 - Seleccao da proposta - Avaliacao das propostas recebidas contra os criterios de avaliacao estabelecidos,resultando na escolha da proposta do parceiro a adjudicar.
GPM-PL8.1 - Avaliacao de propostas recebidas de acordo com criterios de avaliacao estabelecidos.
GPM-PL8.2 - Seleccao da proposta a adjudicar pela organizacao para implementacao do projecto.
GPM-PL8.3 - Actualizacao e validacao do orcamento da compra com a proposta seleccionada.
GPM-PL9 - Definicao do contracto de compra - Preparacao da minuta do contracto de compra e envio da nota deencomenda.
GPM-PL9.1 - Definicao da minuta de contracto de compra.
GPM-PL9.2 - Reuniao de validacao da minuta de contracto de compra.
GPM-PL9.3 - Adjudicacao da compra com envio da nota de encomenda.
Tabela 4.6: Actividades detalhadas do procedimento de compra.
e validada a especificacao tecnica de compra que apresenta, com detalhe variavel de acordo com o
ambito do projecto, uma analise tecnica da solucao a desenvolver, identificando que componentes de-
vem ser desenvolvidos e de que forma serao integrados. Esta especificacao pode corresponder apenas
ao statement of work, desenvolvido na fase de oportunidade e que apresenta apenas os produtos ou
servicos a disponibilizar pelo projecto, ou pode corresponder ja a uma analise tecnica deste documento,
caso a equipa de projecto possua elementos com os conhecimentos tecnicos necessarios. Neste pro-
cesso, consideramos que a area de projectos e capacitada do conhecimento necessario para analisar
o statement of work numa perspectiva mais tecnica e elaborar um desenho da solucao a desenvolver,
a partir do qual sera feita a especificacao tecnica da compra.
E tambem revisto o orcamento do projecto, definido durante a fase de oportunidade e integrado
no orcamento anual da organizacao como um projecto pertencente ao portfolio de projectos. Este
orcamento foi definido tendo em conta a compra da implementacao do projecto, razao pela qual e
definido nesta fase o orcamento da compra e incluıdo no plano de gestao de compra. A definicao deste
orcamento tem dois objectivos: garantir que o orcamento da compra se encontra de acordo com o
orcamento global do projecto definido no portfolio e definir um tecto orcamental para a compra, que
42
servira tambem como criterio de avaliacao de propostas.
O calendario das compras e definido nesta fase, sendo necessario alinhar as actividades de compra
do projecto com as restantes actividades de compra da organizacao, de acordo com um plano anual
de compras definido a nıvel da governacao da direccao dos sistemas de informacao. Este calendario
de compra define as principais milestones de compra na perspectiva da area de projectos, tendo em
conta que nao existe ainda qualquer parceiro responsavel pela implementacao. Normalmente este
calendario define apenas datas de inıcio de compra e datas expectaveis de entregas do parceiro, uteis
na definicao do procurement statement of work permitindo ao parceiro avaliar se tem capacidade para
cumprir o calendario.
De forma a avaliar o conjunto de futuras propostas de parceiros, sao tambem definidos um conjunto
de criterios de avaliacao de propostas, que identificam criterios para a escolha da proposta a adjudicar.
A identificacao dos criterios tem em conta aspectos intrınsecos ao ambito do projecto, podendo reflectir
criterios orcamentais ou tecnicos, entre outros. Antes de iniciar a compra, e realizada uma reuniao de
validacao do procedimento de compra, sendo validados o planeamento da compra e o procurement
statement of work. Esta revisao garante que todo o procedimento da compra foi definido em acordo
entre a area de projectos e a area de compras.
A abertura do perıodo de consulta ao mercado, com data definida no calendario da compra, marca
o inıcio de recepcao de propostas dos parceiros, que avaliaram o procurement statement of work
fornecido e definiram uma proposta de implementacao do projecto. Durante o perıodo de consulta
ao mercado e criada pela area de compras uma carteira de propostas, podendo estas propostas serem
alvo de pedidos de esclarecimentos promovidos tanto pela organizacao como pelos possıveis par-
ceiros. Apos o fim da consulta ao mercado, e realizada a avaliacao das varias propostas recebidas e
selecionada a proposta a adjudicar. Finalizada a escolha da proposta a adjudicar, a compra e oficial-
izada com a definicao da minuta do contracto de compra e com o envio da nota de encomenda por
parte da organizacao.
Apos o procedimento de compra finalizado, e possıvel a equipa de projecto detalhar o orcamento
e calendario do projecto, sendo definidos os planos de gestao de calendario e de gestao de custos.
Durante o planeamento de orcamento do projecto e definida a baseline de orcamento do projecto, que
correponde a primeira versao do orcamento detalhado do projecto, cujos tracos gerais ja se encontram
definidos no orcamento anual da direccao dos sistemas de informacao e integrado no portfolio de pro-
jectos, mas que necessita de ser detalhado tendo em conta todo o procedimento de compra e o custo
da implementacao do mesmo. E no planeamento de custos de projecto que tambem e desenvolvido o
plano de pagamentos, que define datas e valores monetarios a cobrar pelo parceiro de acordo com a
proposta seleccionada. O plano de pagamentos envolve apenas a compra da implementacao tendo em
conta que o projecto e interno a organizacao, sendo o seu custo parte do orcamento anual da mesma.
O planeamento de calendario do projecto define e calendariza detalhadamente as actividades a
realizar durante a execucao do projecto, sendo apresentadas as principais milestones do projecto em
termos de calendario e definida a baseline de calendario do projecto, que servira como ponto de re-
ferencia para todo o controlo de calendario do projecto. No final da fase de planeamento, o Plano de
43
gestao de projecto e revisto na sua totalidade antes do inıcio da implementacao do mesmo, sendo re-
visitados os planos de gestao de stakeholders, de gestao de risco e de gestao de comunicacoes com
a participacao do parceiro. De forma a dar inıcio a fase de implementacao e controlo, sao realizadas
duas reunioes de kick-off do projecto, uma interna com a equipa de projecto e a area de negocio e
outra externa da equipa de projecto com o parceiro.
4.3.2 Vista de Responsabilidades
Durante toda a fase de planeamento a area de projectos desempenha o principal papel em todas as
actividades, sendo responsavel pela execucao e controlo de progresso na revisao do planeamento de
projecto e na definicao dos planos de gestao de stakeholders, de comunicacoes, de riscos, de custos e
de calendario.
Na gestao de stakeholders, a area de projectos conta com a colaboracao da area de negocio, que
reune os principais stakeholders do projecto, sendo esta consultada em reunioes de familiarizacao e
entrevistas. O mesmo sucede na gestao de comunicacoes, contando tambem com a consulta as areas
de O&M, planeamento e controlo e ao director DSI de forma a definir todo o plano de comunicacao. Em
termos de gestao de risco, possui especial relevo a consulta a area de planeamento e controlo para a
definicao do orcamento a alocar para actividades de gestao de risco.
A gestao de custos do projecto e realizada em estrita colaboracao com a area de planeamento e
controlo, sendo esta consultada em todas as actividades pois e a area responsavel pelo orcamento
anual da direccao dos sistemas de informacao e qualquer posicao orcamental, tomada pela area de
projectos, necessita de ser tida em conta por esta area. Na gestao de calendario os principais interve-
nientes consultados sao o parceiro seleccionado para a implementacao do projecto e a area de negocio.
O parceiro, apesar de estar de acordo com um calendario de compra definido na proposta adjudicada,
fornece o feedback necessario para a calendarizacao de actividades a um nıvel de detalhe superior
ao que consta no plano de compra. Relativamente a area de negocio, e esta a principal entidade que
introduz constragimentos na calendarizacao de actividades e definicao de milestones, razao pela qual
e consultada.
O procedimento de compra apresenta uma definicao de responsabilidades distinta de toda a restante
fase, sendo a responsabilidade de execucao e controlo de progresso das actividades da area de Com-
pras. E esta a area que conta com os especialistas em todos os procedimentos de compra, desde
a seleccao de parceiros de implementacao ate a definicao de contractos. Na tabela 4.7 encontra-se
detalhada a vista de responsabilidades para todo o procedimento de compra desenhado.
No planeamento da compra a area de projectos assume a responsabilidade de execucao das activi-
dades e controlo de progresso, na medida em que todas as actividades estao directamente relacionadas
com o projecto em si e a area de compras nao possui o conhecimento especıfico do projecto para as
realizar. Importa destacar a consulta a area de compras na definicao do calendario de compras e dos
criterios de avaliacao das propostas, sendo necessarias trocas de informacao no processo entre es-
tas duas areas que permitirao a passagem de responsabilidade durante o procedimento de compra.
44
Actividades Projectos O&M P&C Compras Director
DSIParceiro Negocio
GPM-PL6 - Planeamento da Compra
GPM-PL6.1 X/P/D A A
GPM-PL6.2 X/P C I I
GPM-PL6.3 X/P I C A
GPM-PL6.4 X/P C C A
GPM-PL6.5 X/P A C A
GPM-PL6.6 X/P I I I I
GPM-PL7 - Consulta ao mercado
GPM-PL7.1 I X/P I
GPM-PL7.2 C X/P C
GPM-PL7.3 C X/P C
GPM-PL8 - Seleccao da proposta
GPM-PL8.1 C X/P I
GPM-PL8.2 C/d X/P/D I/d I I
GPM-PL8.3 X I P
GPM-PL9 - Definicao do contracto de compra
GPM-PL9.1 C C X/P/D C/d
GPM-PL9.2 C C X/P C C
GPM-PL9.3 I I X/P/D I I I
Tabela 4.7: Vista de responsabilidades detalhada do procedimento de compra na fase de planeamento.
A area de compras possui uma vasta experiencia, pelo que integra a identificacao e analise de riscos
bem como a definicao do calendario da compra. Em termos de definicao dos criterios de avaliacao,
a area de compras possui um papel ainda mais importante, embora mantido como consulta, podendo
ela propria definir criterios especıficos. Em termos da definicao de orcamento, a area de planemento e
controlo e consultada na revisao do orcamento da compra.
Na consulta ao mercado a area de projectos e consultada na criacao da carteira de portfolios e na
realizacao de pedidos de esclarecimento por ser ela a possuir os conhecimentos tecnicos necessarios
para avaliar potenciais falhas na proposta recebida ou aspectos nao definidos pelo parceiro. Na seleccao
da proposta, a decisao da proposta a adjudicar e tomada em colaboracao entre a area de compras,
o director DSI e a area de projectos. Devido a sua responsabilidade na direccao dos sistemas de
informacao, o director DSI possui sempre uma posicao de decisao na seleccao da proposta, embora
esta decisao seja, na grande maioria dos casos, de acordo com os restantes elementos tendo em conta
que nao possui o conhecimento detalhado do projecto. A area de projectos participa tambem na de-
cisao, numa perspectiva de analise tecnica da proposta. A decisao final e da area de compras, que de
acordo com os criterios de avaliacao definidos, selecciona a melhor proposta apresentada. A minuta
do contracto de compra e a nota de encomenda sao definidas e aprovadas pela area de compras, com
as areas de projectos e planeamento e controlo a serem consultadas e o director DSI a tomar parte da
decisao de aprovacao da minuta.
45
4.3.3 Vista de Informacao
A fase de planeamento e marcada pelo fecho do project charter e inıcio da definicao do plano de gestao
de projecto, que ira incluir todos os planos de gestao definidos ao longo desta fase e acompanhar
toda a gestao do projecto ate ao seu encerramento. Na revisao do planeamento de projecto e feita
a revisao e inclusao de toda a informacao do project charter no plano de gestao de projecto, que
ao longo de toda a fase ira contar tambem com a inclusao dos planos de gestao de stakeholders,
de comunicacoes, de riscos, de compra, de custos e de calendario. Todos estes planos de gestao sao
definidos individualmente, sendo depois incluıdos no plano de gestao de projecto de forma a possuir um
unico repositorio de informacao do projecto. Todos os documentos de suporte a fase de planeamento
do processo sao identificados na tabela A.2 do anexo A.2, sendo detalhados os objectivos da sua
utilizacao e a informacao constante em cada um deles.
Considerando a matriz de CRUF da fase de planeamento, representada na tabela 4.8, todos os
planos de gestao secundarios sao criados pela area de projectos, que executa tarefas relativas a sua
definicao, sendo tambem a responsavel pela actualizacao dos mesmos. As interacoes de consulta sao
da responsabilidade dos elementos que na vista de responsabilidades sao informados e consultados,
justificadas pela necessidade de conhecer toda a informacao disponıvel do projecto.
O caso de negocio, o statement of work e o project charter, criados na fase de oportunidade, sao
encerrados no inıcio da fase de planeamento pela area de projectos, deixando de existir como docu-
mentos individuais e sendo integrados no plano de gestao de projecto. Esta decisao e justificada pela
necessidade de criacao de um repositorio central de informacao, nao havendo qualquer tipo de van-
tagem em manter estes tres documentos individuais. Antes de serem integrados no plano de gestao de
projecto, e realizada a revisao e actualizacao de toda a informacao constante dos mesmos.
A definicao da proposta de compra e feita em colaboracao entre a area de compras, responsavel
pela regulamentacao de todo o procedimento de compra, a area de projectos e o parceiro, que apre-
senta a proposta. Como consequencia, estas tres entidades possuem interacoes de actualizacao na
medida em que a definicao da proposta de compra e feita iterativamente, com um conjunto de alteracoes
provenientes de qualquer uma destas tres entidades. Em termos da minuta do contracto de compra e
da nota de encomenda a situacao e semelhante, existindo varias entidades envolvidas no processo de
desenvolvimento do documento e que possuem interesses individuais na sua definicao.
4.4 Fase de Implementacao e Controlo
A fase de Implementacao e Controlo inicia-se com o inıcio da implementacao por parte do parceiro e
com o controlo de projecto por parte da area de projectos. Esta fase nao possui um fluxo unico, con-
sistindo num conjunto de processos individuais que permitem todo o controlo do projecto. Durante todas
as semanas sao feitas reunioes semanais de projecto, onde poderao surgir novos riscos, issues e pe-
didos de alteracao ao projecto. E tambem realizada, todos os meses, uma reuniao mensal do projecto,
que possui um caracter mais estrategico e procura analisar os riscos, issues e alteracoes com maior
46
Documentos de suporte Projectos O&M P&C Compras Director
DSIParceiro Negocio
Caso de negocio R/F R R
Statement of work R/F R
Project charter R/F R R R
Plano de gestao de projecto C/R/U R R R
Registo de stakeholders C/R/U R
Plano de gestao de stakeholders C/R/U R
Log de riscos C/R/U R R R
Plano de gestao de riscos C/R/U R R R
Plano de gestao de comunicacoes C/R/U R R R
Procurement statement of work C/R/U R R R R
Criterios de avaliacao de propostas C/R/U R R R
Plano de gestao de compra C/R/U R R R R
Proposta de compra R/U R/U R C/R/U
Minuta de contracto de compra R/U R C/R/U R/U R/U
Nota de encomenda R/U C/R/U R R
Plano de gestao de custos C/R/U R R
Plano de Gestao de calendario C/R/U R R R
Tabela 4.8: Matriz CRUF dos documentos de suporte ao processo na fase de planeamento.
impacto e prioridade bem como fazer uma revisao geral de calendario e orcamento do projecto. Sem-
pre que novos riscos, alteracoes ou issues sao identificados, sao iniciados os processos de gestao de
risco, gestao de alteracoes ou gestao de issues, respectivamente. A fase de implementacao e controlo
termina com a entrega da implementacao por parte do parceiro, iniciando-se a fase de handover.
Tendo em conta a nao existencia de um fluxo unico do processo nesta fase, a vista de processos
sera dividida nos processos individuais que dela fazem parte, sendo detalhados os que se consideram
com maior interesse no ambito deste trabalho.
4.4.1 Vista de Processos
4.4.1.1 Controlo Semanal do Projecto
O controlo semanal do projecto e constituido por uma so macro-actividade, identificada na figura 4.6,
podendo despoletar outros processos durante a sua execucao caso certas condicoes sejam verificadas.
Este controlo possui um caracter mais operacional, tendo como objectivos definir o conjunto de activi-
dades a executar pela equipa de projecto durante a semana e realizar o controlo de custos, calendario,
riscos, issues, alteracoes, comunicacoes e stakeholders, de forma a garantir o cumprimento dos re-
spectivos planos de gestao.
Durante o controlo semanal do projecto sao identificados novos riscos, issues e pedidos de alteracao
que tenham surgido durante a semana, dando inıcio aos respectivos processos de gestao. Esta macro-
47
Figura 4.6: Fluxo do processo de controlo semanal do projecto.
actividade tem a duracao da semana de trabalho da equipa, sendo iniciada no primeiro dia da semana e
culminando na elaboracao do relatorio de progesso semanal a ser disponibilizado ao director DSI, que
a cada semana recebe o feedback do progresso do projecto. Durante a semana e tambem realizado o
controlo do tratamento dos riscos identificados no projecto, com a analise dos prametros de probabili-
dade e risco residual dos mesmos, e o controlo dos pedidos de alteracao por aprovar, aprovados e em
implementacao.
E ainda necessario garantir que toda a informacao e disponibilizada de acordo com o plano de
comunicacoes, garantindo o seu cumprimento e a chegada da informacao a todos os interessados. Da
mesma forma, e necessario garantir que a participacao dos stakeholders e realizada de acordo com o
plano de gestao de stakeholders, sendo continuamente identificadas propostas de alteracoes, avaliado
o seu impacto e garantida a satisfacao dos seus principais concerns.
As actividades detalhadas de controlo semanal de projecto sao identificadas na tabela 4.9.
4.4.1.2 Controlo Mensal do Projecto
O controlo mensal do projecto, apresentado na figura 4.7, e iniciado no primeiro dia do mes, destacando-
se do controlo semanal no grau de detalhe analisado, pretendendo-se uma visao mais alto nıvel do
progresso do projecto. E realizada uma revisao do calendario do projecto tendo em conta o conjunto
de milestones definidas e a respectiva discrepancia face ao progresso actual. E tambem elaborado um
forecast de orcamento do projecto, que apresenta uma previsao do orcamento de projecto baseada em
estimativas futuras e que permite avaliar a discrepancia face a baseline de orcamento do projecto.
E tambem realizada a revisao do plano de gestao de comunicacoes, com ajustes a necessidades
de comunicacao, informacoes a disponibilizar ou intervenientes, mantendo este plano actualizado de
acordo com os requisitos de comunicacao do projecto. De forma semelhante, o plano de gestao de
48
Actividades
GPM-SE1 – Controlo semanal de projecto – Gestao operacional em formato semanal de orcamento, calendario, riscos,issues, alteracoes, comunicacoes e stakeholders do projecto.
GPM-SE1.1 - Controlo de orcamento do projecto face aos tresholds e a baseline de orcamento definidos no plano de gestaode custos do projecto;
GPM-SE1.2 - Controlo de calendario do projecto face aos tresholds e a baseline de calendario definidos no plano de gestaode calendario do projecto;
GPM-SE1.3 - Atribuicao de actividades de projecto pelo gestor de projecto a equipa;
GPM-SE1.4 - Identificacao de novos riscos do projecto que tenham surgido durante a semana;
GPM-SE1.5 - Controlo do tratamento de riscos planeado para o conjunto de riscos do projecto.
GPM-SE1.6 - Identificacao de alteracoes que tenham surgido durante a semana ao plano de projecto;
GPM-SE1.7 - Controlo de alteracoes para aprovar, aprovadas e em implementacao;
GPM-SE1.8 - Identificacao de issues de projecto que tenham surgido durante a semana;
GPM-SE1.9 - Gestao de comunicacoes com base no plano de gestao de comunicacoes, com a revisao da informacao adisponibilizar, intervenientes e metodos de comunicacao;
GPM-SE1.10 - Gestao de stakeholders do projecto com base no plano de gestao de stakeholders, com a revisao da suaparticipacao em actividades de projecto, comunicacoes e impacto de alteracoes;
GPM-SE1.11 – Elaboracao do Relatorio de Progresso semanal a ser disponibilizado pela equipa ao director DSI para registode progresso do projecto.
Tabela 4.9: Actividades detalhadas do processo de controlo semanal do projecto.
Figura 4.7: Fluxo do processo de controlo mensal do projecto.
stakeholders tambem e revisto com possıveis actualizacoes no registo de stakeholders. Por ultimo, e
realizada uma avaliacao dos riscos com maior prioridade identificados durante o mes, com o controlo
de tratamento desses mesmos riscos, garantindo que os mais crıticos sao geridos de forma a evitar
consequencias danosas para o projecto.
No final do controlo mensal do projecto, que possui uma duracao variavel face a extensao das
analises anteriores, e produzido o relatorio de progresso mensal do projecto para acompanhamento
do estado do projecto pelas areas de planeamento e controlo, director DSI e negocio. Ja com toda
a informacao disponıvel, e realizada uma reuniao de controlo mensal com a area de negocio, para
apresentacao do relatorio de progresso mensal do projecto, podendo desta reuniao surgir a identificacao
de novos riscos, issues ou alteracoes.
Tendo em conta o forecast de orcamento e o caso real da organizacao, na definicao da versao apli-
49
cada ao caso real da organizacao, foi considerada uma extensao ao controlo mensal do projecto. O
forecast de orcamento de projecto seria revisto pela area de planeamento e controlo, sendo realizada
uma analise de necessidade de alteracao ao orcamento do projecto tendo em conta a discrepancia
com a baseline. No caso de serem necessarias alteracoes, a area de planeamento e controlo seria re-
sponsavel por propor um conjunto de alteracoes ao orcamento, que seriam submetidas para aprovacao
ao director DSI, o qual iria proceder a uma analise e tomar a decisao de aprovacao. Apesar de ser um
processo comum em grande parte das organizacoes, optamos por nao detalhar estas actividades por
serem intrınsecas a organizacao, apresentando necessariamente variacoes se outro caso real de outra
organizacao fosse considerado.
As actividades detalhadas de controlo mensal de projecto sao identificadas na tabela 4.10.
Actividades
GPM-ME1 - Controlo mensal do projecto - Gestao estrategica em formato mensal de orcamento, calendario, riscos,alteracoes, comunicacoes e stakeholders do projecto.
GPM-ME1.1 - Revisao de milestones contratuais e etapas de projecto para revisao e actualizacao do calendario de projecto,de forma a avaliar nıvel de discrepancia com a baseline de calendario;
GPM-ME1.2 - Elaboracao de forecast de orcamento de forma a avaliar nıveis de discrepancia com a baseline de orcamento;
GPM-ME1.3 - Revisao dos riscos com maior prioridade identificados, com o controlo de tratamento desses riscos.
GPM-ME1.4 - Avaliacao da necessidade de pedido de alteracao de orcamento, calendario ou ambito de acordo com osforecasts e analises produzidas e os tresholds de controlo definidos nos respectivos planos.
GPM-ME1.5 - Revisao do plano de gestao de comunicacoes do projecto com ajustes a necessidades de comunicacao,informacao a disponibilizar, intervenientes e ferramentas de comunicacao.
GPM-ME1.6 - Revisao do plano de gestao de stakeholders com ajustes na identificacao de stakeholders, comunicacoes ouimpacto de alteracoes.
GPM-ME1.7 - Producao e envio de relatorio de progresso mensal do projecto para acompanhamento do estado do projectopelas areas de planeamento e controlo, director DSI e negocio.
GPM-ME1.8 - Reuniao de controlo mensal do projecto com a participacao da area de Negocio, para apresentacao do relatoriode progresso do projecto, com possıvel identificacao de novos riscos, issues e alteracoes.
Tabela 4.10: Actividades detalhadas do processo de controlo mensal do projecto.
4.4.1.3 Gestao de Riscos do Projecto
Sempre que um risco e identificado durante a fase de planeamento e as fases seguintes, e iniciado o
processo de gestao de riscos identificado na figura 4.8. O processo inicia-se com o registo do risco no
log de riscos, sendo definido o responsavel pelo mesmo e ainda realizada uma identificacao preliminar
das causas, consequencias, areas de impacto e possıveis medidas de tratamento do risco. Esta analise
preliminar tem como objectivo recolher a maxima informacao disponıvel no momento de identificacao
do risco, facilitando a posterior fase de analise em que alem de complementar todas as informacoes, o
risco e ainda prioritizado. A prioridade do risco e definida em termos da analise de impacto realizada,
a probabilidade do risco e ainda o nıvel de exposicao ao risco da organizacao, definido no plano de
gestao de riscos. Este nıvel de exposicao ao risco identifica, em funcao da probabilidade e impacto do
risco, qual o nıvel de risco maximo que a organizacao esta disposta a aceitar, aceitando esse mesmo
nıvel de risco como uma oportunidade de negocio.
O tratamento do risco e divido em tres macro-actividades. Em primeiro lugar sao levantadas um
50
Figura 4.8: Fluxo do processo de identificacao e analise do risco.
conjunto de medidas aplicaveis ao tratamento do risco, sendo realizada uma analise de orcamento
e calendario das mesmas. O objectivo e fazer um levantamento de todas as medidas disponıveis
para seleccionar um conjunto delas que, aplicadas, permitem reduzir o nıvel de risco ate a um nıvel
residual aceitavel pela organizacao. A ultima fase consiste na definicao do plano de tratamento, que e
adicionado ao log do risco e que define as medidas a aplicar e respectivas actividades, os responsaveis
e o orcamento para o tratamento do risco, entre outras informacoes. O fluxo do processo relativo as
actividades de seleccao das medidas de tratamento de risco e de definicao do plano de tratamento sao
apresentadas na figura 4.9.
Figura 4.9: Fluxo do processo de tratamento do risco.
O controlo do tratamento dos riscos nao e definido neste processo, fazendo parte dos controlos
semanais e mensais do projecto por ser variavel em funcao das medidas consideradas. Consiste na
avaliacao dos nıveis de risco residuais e da necessidade de aplicacao de novas medidas de tratamento
do risco. Na tabela 4.11 sao apresentadas as actividades detalhadas do processo de gestao de risco.
4.4.1.4 Gestao de Issues do Projecto
Assim que um issue de projecto e identificado, podendo ter um conjunto de origens distintas e normal-
mente associado a riscos que se concretizaram, e iniciado o processo de gestao de issues apresentado
51
Actividades
GPM-RI1 - Registo do risco - Registo, identificacao de responsavel e analise preliminar das causas, consequenciase impacto do risco identificado.
GPM-RI1.1 - Registo do risco no log de riscos;
GPM-RI1.2 - Definicao de responsavel pelo risco;
GPM-RI1.3 - Identificacao preliminar das causas, consequencias e areas de impacto do risco;
GPM-RI1.4 - Levantamento preliminar de possıveis medidas de tratamento do risco;
GPM-RI2 - Analise do risco - Identificacao das causas, consequencias, impacto, probabilidade e prioridade do riscoidentificado tendo em conta todo o plano de projecto.
GPM-RI2.1 - Identificacao das causas e consequencias do risco;
GPM-RI2.2 - Determinacao de probabilidade do risco;
GPM-RI2.3 - Analise de impacto do risco no orcamento, calendario e ambito do projecto;
GPM-RI2.4 - Prioritizacao do risco de acordo com analise de impacto realizada, prioridade do risco e exposicao ao risco daorganizacao de acordo com o plano de gestao de riscos;
GPM-RI3 - Identificacao de medidas de tratamento do risco - Levantamento de medidas de tratamento com analisede orcamento e calendario para a sua implementacao.
GPM-RI3.1 - Levantamento de conjunto de medidas aplicaveis ao tratamento do risco.
GPM-RI3.2 - Identificacao de estimativa de orcamento e calendario para a aplicacao de cada uma das medidas de tratamentodo risco identificadas.
GPM-RI4 - Seleccao de medidas de tratamento de risco - Escolha das medidas de tratamento de risco a aplicar deacordo com o orcamento e calendario definido e analise de risco residual.
GPM-RI4.1 - Seleccao de medida de tratamento de risco a aplicar, de acordo com a estimativa de orcamento e calendariodefinidas para a medida;
GPM-RI4.2 - Estimativa de nıvel de risco residual e decisao de aplicacao de novas medidas de tratamento de risco;
GPM-RI5 - Definicao de plano de tratamento de risco - Definicao do plano de tratamento do risco com a identificacaodas medidas a implementar, orcamento e calendario das actividades.
GPM-RI5.1 - Definicao de conjunto de medidas a implementar e responsavel para o tratamento do risco;
GPM-RI5.2 - Definicao e calendarizacao de actividades de tratamento de risco;
GPM-RI5.3 - Revisao do orcamento e calendario das medidas de tratamento aplicaveis com o calendario e orcamento doprojecto;
GPM-RI5.4 - Identificacao das condicoes trigger de probabilidade de ocorrencia do risco;
GPM-RI5.5 - Identificacao do nıvel de risco residual;
Tabela 4.11: Actividades detalhadas do processo de gestao de risco do projecto.
na figura 4.10. O issue e registado no log de issues e associado a um responsavel na area de projec-
tos, procedendo-se a uma analise preliminar em termos das suas causas, impacto e possıvel solucao.
Tendo em conta esta analise, e atribuida uma prioridade ao issue e analisada a necessidade de o
escalar para o director DSI. No caso desta organizacao consideramos que a decisao de escalar o is-
sue e tomada tendo em conta a prioridade e o impacto no projecto mas outros criterios podem ser
estabelecidos se considerarmos outra organizacao.
Caso o issue seja escalado para o director DSI, o processo e semelhante tendo apenas em conta
que a responsibilidade da sua execucao e do director DSI, que apos validar a resolucao do issue deve
comunica-lo a area de projectos, sendo esta a responsavel por realizar o seu fecho no log de issues.
Caso o issue nao seja escalado, como apresentado na figura 4.11, a area de projectos realiza o
seu diagostico, identiticando o conjunto de medidas necessarias a sua resolucao e respectiva analise
de calendario e orcamento dessas medidas. Tendo em conta o conjunto de medidas identificadas, sao
52
Figura 4.10: Fluxo do processo de identificacao e gestao de issues escalados.
seleccionadas as medidas a aplicar com possıveis alteracoes ao plano de projecto. Uma das medidas
de tratamento do issue pode ser inclusive a realizacao de um pedido de alteracao, sendo iniciado o
processo de gestao de alteracoes. As medidas seleccionadas sao aplicadas e testadas, sendo validada
a resolucao do issue ou identificada a necessidade de aplicacao de mais medidas de tratamento.
Figura 4.11: Fluxo do processo de gestao de issues nao-escalados e fecho do issue.
4.4.1.5 Gestao de Alteracoes do Projecto
Durante o planeamento e implementacao do projecto surgem alteracoes de ambito propostas pelos
stakeholders, com a apresentacao de novos requisitos ou alteracoes a requisitos ja existentes. Estas
alteracoes irao ter impacto em todo o planeamento do projecto ja realizado, especialmente em termos
de orcamento e calendario. E por isso necessario a orgnizacao garantir a posse de um processo para
a gestao de alteracoes de projecto.
Quando uma nova alteracao e identificada, e registada no log de alteracoes e identificado um re-
sponsavel para a sua gestao dentro da equipa de projecto. E ainda definido o ambito da alteracao, com
a identificacao dos respectivos requisitos e atribuicao de uma prioridade a mesma tendo em conta a sua
importancia no projecto. De forma a alinhar a analise da alteracao com os elementos responsaveis pela
53
implementacao do projecto, e feito um pedido de analise da alteracao ao parceiro relativo a questoes
tecnicas, de orcamento e de calendario. Apos a recepcao da analise do parceiro, a equipa de pro-
jecto procede a uma avaliacao da analise do parceiro e classifica a alteracao como minor ou major de
acordo com os criterios de classificacao da alteracao da organizacao. Esta classificacao esta muitas
vezes associada ao impacto no orcamento e calendario do projecto, embora outros criterios possam
ser considerados.
Caso a alteracao seja classificada como major, tera de ser realizada uma revisao do forecast do
orcamento do projecto por parte da area de planeamento e controlo, de forma a avaliar o impacto no
orcamento do projecto. Este impacto sera avaliado tambem pelo director DSI, o qual tomara a decisao
de aprovacao ou rejeicao do pedido de alteracao. Todo o processo de revisao nao sera detalhado,
tendo em conta que e intrınseco a organizacao e orientado a aspectos da sua governacao. A decisao
de aprovacao da alteracao possui um conjunto de variacoes que necessitariam de ser exploradas em
detalhe caso considerassemos abordar este tema. Tendo em conta que a alteracao ira ter impacto
no orcamento e todo o projecto e interno a organizacao, poderia ser necessario, por exemplo, rever
todo o orcamento do projecto e inclusive requisitar uma alocacao de verbas ao projecto por parte da
organizacao de forma a fazer face a implementacao da alteracao. Assim, considera-se apenas que o
pedido de aprovacao da alteracao e realizado pela area de projectos a area de planeamento e controlo
que, em parceria com o director DSI, toma a decisao de aprovacao ou rejeicao do pedido de alteracao.
O fluxo do processo ate esta fase e apresentado na figura 4.12.
Figura 4.12: Fluxo do processo de gestao de alteracoes relativo ao planeamento e aprovacao daalteracao.
Caso o pedido de alteracao seja aprovado, e dada continuidade ao planeamento da alteracao, com
a revisao da sua prioridade e de calendario, culminando no agendamento da alteracao. O controlo
da alteracao foca-se na contınua monitorizacao do progresso da implementacao da alteracao, com
controlo de orcamento, calendario e ambito. Terminada a implementacao, e apos possıveis pedidos
de pequenas correccoes por parte da area de negocio, e feita a aceitacao da alteracao com a area de
negocio, procedendo-se ao fecho da alteracao no log de alteracoes. O fluxo do processo de controlo e
54
fecho da alteracao e apresentado na figura 4.13.
Figura 4.13: Fluxo do processo de gestao de alteracoes relativo ao controlo e fecho da alteracao.
4.4.2 Vista de Responsabilidades
Relativamente a vista de responsabilidades da fase de implementacao e controlo, o principal interve-
niente e a area de projectos, que executa grande parte das actividades e e responsavel pelo controlo
do seu progresso. Na gestao de riscos esta area colabora com o negocio e parceiro na identificacao e
analise do risco, consultando-a tambem no levantamento e aplicacao de medidas de tratamento.
O parceiro possui uma grande importancia neste processo, na medida em que e o responsavel
pela implementacao do projecto, sendo um dos intervenientes que ira sentir de forma directa as con-
sequencias dos riscos. Por essa razao, deve ser envolvido em todo o processo de identificacao e
tratamento, sendo muitas vezes ele o proprio responsavel pela aplicacao das medidas de tratamento. A
area de negocio, por sua vez, podera ver os seus objectivos e interesses no projecto postos em causa
pelas consequencias dos riscos identificados, sendo necessaria a sua consulta em todo o processo,
especialmente na identificacao e seleccao das medidas de tratamento.
Em termos da gestao de alteracoes, a vista de responsabilidades assume um padrao semelhante
a gestao de riscos, embora neste caso o papel do parceiro seja ainda mais importante, na medida
em que e a entidade que realiza a analise da alteracao e a sua implementacao, estando directamente
envolvido em todo o processo e disponibilizando todo o feedback necessario ao controlo da alteracao.
A area de negocio possui um papel mais passivo neste processo, sendo responsavel pela identificacao
da alteracao e pela sua aceitacao final.
A gestao de issues possui um caracter volatil, podendo um issue ter origem num conjunto de
situacoes ocorridas durante a implementacao do projecto que nao se encontram bem definidas no
seu planeamento. Por essa mesma razao, a definicao de responsabilidades tambem e relativamente
generica, sendo a area de projectos a principal entidade responsavel pela execucao e controlo de pro-
gresso, embora no caso de necessidade de escalar um issue para o director DSI, a responsabilidade de
execucao e controlo de progresso das actividades seja da responsabilidade deste. O parceiro encontra-
se tambem envolvido em todo o processo, sendo consultado na identificacao, analise e resolucao do
55
issue, pelo facto de ser a entidade directamente ligada com a sua ocorrencia e o responavel, muitas
vezes, pela aplicacao concreta das medidas de resolucao.
A vista de responsabilidades relativa aos processos de controlo semanal e mensal do projecto e
detalhada na tabela 4.12. Importa destacar a diferente atribuicao de responsabilidades no controlo
semanal e mensal do projecto, directamente relacionado com os caracteres operacional e estrategico
destas actividades, respectivamente.
No controlo semanal de projecto a area de projectos e responsavel pela execucao e controlo de
progresso de todas as actividades, actuando em colaboracao sobretudo com o parceiro e com a area
de negocio, sendo estes consultados para a identificacao de riscos, issues e alteracoes, controlo de
calendario e orcamento e verificacao do cumprimento dos planos de gestao de stakeholders e de
comunicacoes. Estas actividades teem como objectivo assegurar um controlo de projecto de curto
prazo, garantindo que o planeamento realizado na fase de planeamento e cumprido.
Em termos de controlo mensal do projecto, todas as areas consideradas nesta vista sao envolvidas
nas actividades de controlo, sendo feito um controlo de projecto a longo prazo e inclusive revistos
os planos de gestao de comunicacoes e de stakeholders. Sao tambem elaborados os forecasts de
orcamento e revistas as milestones contratuais, informacoes sobre as quais todas as areas possuem
conhecimento e interesse. Nesta fase os riscos de maior prioridade tambem sao geridos.
Actividades Projectos O&M P&C Director
DSIParceiro Negocio
GPM-SE1 - Controlo semanal do projecto
GPM-SE1.1 X/P C I A
GPM-SE1.2 X/P A C C
GPM-SE1.3 X/P I
GPM-SE1.4 X/P A A C C
GPM-SE1.5 X/P A C C
GPM-SE1.6 X/P C C
GPM-SE1.7 X/P I C I
GPM-SE1.8 X/P C A
GPM-SE1.9 X/P C C C C
GPM-SE1.10 X/P I C C
GPM-SE1.11 X/P A A A A A
GPM-ME1 - Controlo mensal do projecto
GPM-ME1.1 X/P A A C C C
GPM-ME1.2 X/P C A
GPM-ME1.3 X/P A C C C
GPM-ME1.4 X/P C C C
GPM-ME1.5 X/P C C C C C
GPM-ME1.6 X/P C C C C
GPM-ME1.7 X/P I I I I I
GPM-ME1.8 X/P C C A C
Tabela 4.12: Vista de responsabilidades dos processos de controlo semanal e mensal do projecto.
56
4.4.3 Vista de Informacao
Os principais documentos de suporte do processo na fase de implementacao e iontrolo, alem do plano
de gestao de projecto que acompanha todas as fases do processo, sao os logs que resultam dos
processos de gestao de alteracoes e gestao de issues, o forecast de orcamento e os relatorios de
progresso semanais e mensais. O log de alteracoes possui um conjunto de registos de pedidos de
alteracao, sendo que cada registo reune todas as informacoes de identificacao, analise e planeamento
da alteracao. De forma semelhante, o log de issues reune toda a informacao de identificacao, plane-
mento e resolucao de cada issue do projecto.
O orcamento do projecto, definido na fase de planeamento e constante do plano de gestao de
custos, define a baseline do orcamento do projecto. Porem, ao longo da execucao de projectos, um
conjunto de acontecimentos leva a sua alteracao, sendo raras as excepcoes em que o orcamento do
projecto mantem-se inalterado ate ao seu encerramento. Assim, de forma a fazer face a alteracoes
de orcamento, todos os meses e produzido o forecast de orcamento de projecto que apresenta uma
estimativa do orcamento do projecto ate ao seu encerramento, considerando todas as actividades real-
izadas ate ao momento.
O relatorio de progresso semanal do projecto resulta das actividades de controlo semanal e tem
como objectivo fornecer a informacao de progresso de projecto ao director DSI, sendo apresentadas,
entre outras informacoes, as actividades realizadas durante a semana e as planeadas para a semana
seguinte. O relatorio de progresso mensal do projecto resulta das actividades de controlo mensal,
apresentando um resumo da informacao do conjunto dos relatorios semanais do mes. Entre outras
informacoes, apresenta um resumo do trabalho realizado durante o mes, o forecast de orcamento e
o planeamento de calendario do projecto. Este relatorio e enviado aos elementos da direccao dos
sistemas de informacao e a area de negocio, embora a informacao constante do mesmo seja adaptada
consoante o destinatario. Na tabela A.3 do anexo A.3 sao apresentados em detalhe estes documentos
de suporte.
Em termos da matriz CRUF dos documentos de suporte da fase de implementacao e controlo, esta
encontra-se dividida no cojunto de processos individuais identificados nesta fase, sendo detalhada a
matriz para os processos de controlo semanal e mensal do projecto e para o processo de gestao de
risco, de acordo com as vistas de processos e de responsabilidades apresentadas.
Relativamente a matriz CRUF da gestao semanal do projecto, apresentada na figura 4.13, importa
destacar as interaccoes apenas de consulta relativas a todos os planos de gestao indiviuais, sendo
apenas o plano de gestao de projecto alterado tendo em conta a definicao de actividades com impacto
no calendario do projecto e o controlo de orcamento realizado, com impacto no forecast de orcamento.
Os logs de riscos, alteracoes e issues de projecto tambem sao actualizados tendo em conta que o seu
controlo podera introduzir novas alteracoes e actualizacoes.
Comparando com a anterior, a matriz CRUF do processo de gestao mensal do projecto, apresentada
na tabela 4.14, distingue-se em termos das interacoes de actualizacao dos planos de gestao individuais
considerados, sendo actualizados, entre outros, os planos de gestao de comunicacoes e de gestao de
stakeholders. Estas alteracoes pretendem adequar de melhor forma os respectivos planos ao estado
57
Documentos de suporte Projectos O&M P&C Director
DSIParceiro Negocio
GPM-SE - Gestao semanal do projecto
Plano de gestao de projecto R/U
Registo de stakeholders R
Plano de gestao de stakeholders R
Log de riscos R/U
Plano de gestao de riscos R
Plano de gestao de comunicacoes R
Plano de gestao de custos R
Plano de gestao de calendario R
Relatorio de progresso semanal C/R/U R R
Log de alteracoes R/U
Log de issues R/U
Tabela 4.13: Matriz CRUF dos documentos de suporte do processo de gestao semanal do projecto.
actual de progresso do projecto. E tambem considerada a criacao do forecast de orcamento de projecto
todos os meses, embora este seja desenvolvido a partir do forecast de orcamento do mes anterior de
acordo com as novas estimativas de orcamento do projecto, bem como do conjunto de analises de
orcamento semanais.
Documentos de suporte Projectos O&M P&C Director
DSIParceiro Negocio
GPM-ME - Gestao mensal do projecto
Forecast do orcamento do projecto C
Plano de gestao de projecto R/U
Plano de gestao de Stakeholders R/U
Plano de gestao de riscos R/U
Plano de gestao de comunicacoes R/U
Plano de gestao de custos R/U
Plano de gestao de calendario R/U
Relatorio de progresso mensal C/U R R R R
Registo de stakeholders R/U
Log de riscos R/U
Log de alteracoes R/U
Tabela 4.14: Matriz CRUF dos documentos de suporte do processo de gestao mensal do projecto.
Relativamente a matriz CRUF dos documentos de suporte do processo de gestao de risco, apre-
sentada na tabela 4.15, os unicos documentos de suporte considerados neste processo sao o plano de
gestao de riscos e o log de riscos, sendo que o primeiro e apenas consultado pela area de projectos
enquanto o segundo e actualizado de acordo com os novos riscos identificados.
58
Documentos de suporte Projectos O&M P&C Director
DSIParceiro Negocio
GPM-RI - Gestao de riscos do projecto
Plano de Gestao de Riscos R
Log de Riscos R/U
Tabela 4.15: Matriz CRUF dos documentos de suporte do processo de gestao de riscos do projecto.
4.5 Fase de Handover
Na fase de handover e feita a revisao dos entregaveis do parceiro de acordo com especificacoes
tecnicas e testes de sistema executados pela area de projectos. E feita tambem a aceitacao com a
area de negocio para a aceitacao final do projecto e preparada a entrega do mesmo a area de O&M,
que sera responsavel pelo projecto a partir desta fase. A area de O&M sera ja responsavel pela pas-
sagem do projecto em ambiente de qualidade para ambiente de producao, apos a qual e realizado o
encerramento do projecto e terminado todo o fluxo do processo.
4.5.1 Vista de Processos
Apos a entrega da implementacao do projecto pelo parceiro a area de projectos, e necessario realizar
um conjunto de actividades de preparacao da aceitacao do projecto por parte da area de negocio
e tambem da area de O&M, apresentadas no fluxo do processo identificado na figura 4.14. Numa
primeira fase, e realizada a preparacao e a passagem do projecto para ambiente de qualidade, um
ambiente de execucao do projecto destinado a realizacao dos testes de aceitacao. E revista toda a
especificacao tecnica e realizados testes de sistema, com eventuais pedidos de correccao da area de
projectos ao parceiro. E tambem realizado o planeamento dos testes de aceitacao da area de negocio,
com a definicao do calendario, plano de testes e recursos necessarios, sendo estes realizados apos a
aceitacao dos testes de sistema pela area de projectos.
Apos aprovacao dos testes sistema, e realizada a aceitacao com o negocio, com a realizacao dos
testes de aceitacao. Caso os testes sejam realizados com sucesso, e feita a aceitacao do projecto
por parte da area de negocio e da area de projectos, assinando as duas o auto de aceitacao. Para a
aceitacao definitiva do projecto, e ainda necessario proceder a aceitacao por parte da area de O&M.
Esta aceitacao, por vezes nao considerada pelas organizacoes, foi considerada tendo em conta que
sera esta a area que ira lidar, no futuro, com eventuais pedidos de manutencao, sendo necessario
garantir que, alem de possuir todo o conhecimento necessario para gerir estes pedidos, o projecto
foi-lhe entregue de acordo com todo o planeamento e requisitos estabelecidos.
Na realizacao do plano de handover a manutencao, toda a documentacao do projecto e compilada
pela area de projectos para entrega a area de O&M, que prepara o ambiente de producao do projecto de
acordo com um conjunto de configuracoes disponibilizadas pela area de projectos e pelo parceiro. Sao
ainda realizados testes de aceitacao pela area de O&M, cuja extensao e complexidade sao definidas
de acordo com o ambito do projecto. Apos a aprovacao dos testes de aceitacao, e ainda necessario
59
Figura 4.14: Fluxo do processo relativo a aceitacao do projecto.
receber e aceitar os logs de riscos, issues e alteracoes do projecto, de forma a esta area possuir toda a
a informacao relativa a pedidos de alteracoes e problemas resolvidos durante a execucao do projecto e
nao previstos no plano de projecto. A aceitacao do projecto e consumada com a aceitacao por parte da
area de O&M e com a assinatura do auto de aceitacao pela mesma. A partir deste momento, o projecto
passa a ser da sua responsabilidade. As actividades detalhadas relativas a aceitacao do projecto pela
area de projectos, negocio e O&M sao apresentadas na tabela 4.16.
Apos a aceitacao do projecto e enviado o pedido de entrada em producao, sendo necessario realizar
a passagem do projecto para ambiente de producao, com a revisao de pedidos de alteracoes, issues e
riscos em ambiente de qualidade. Caso nao exista qualquer tipo de correccao ou alteracao a realizar,
e feita a passagem do projecto para ambiente de producao. Apos o projecto se encontrar em ambiente
de producao, e realizado o seu encerramento. A passagem a producao e comunicada a area de pro-
jectos, que inicia o encerramento do projecto em duas fases: o encerramento tecnico e o encerramento
administrativo.
Apos terminada a passagem do projecto a producao, realizada pela area de O&M e comunicada
formalmente a area de projectos, o encerramento do projecto e iniciado com o envio do pedido de
encerramento administrativo do projecto a area de planeamento e controlo, de forma a iniciar o conjunto
de actividades de fecho do contracto de implementacao realizado com o parceiro e de encerramento
do orcamento e do plano de pagamentos.
Apos ser feito o pedido de encerramento administrativo, a propria area de projectos da inıcio ao
encerramento tecnico, no qual e compilada e arquivada a ultima versao do plano de gestao de projecto,
coleccionadas as licoes aprendidas, elaborado o relatorio de fecho do projecto e realizada uma reuniao
de fecho com as areas de projectos e O&M, juntamente com a area de planeamento e controlo e com
a area de negocio, apos a qual sao libertados os recursos do projecto. O fluxo do processo relativo a
passagem a ambiente de producao e encerramento do projecto e apresentado na figura 4.15.
Apos esta fase, o projecto encontra-se encerrado e a area de O&M munida de toda a informacao
60
Actividades
GPM-HA1 – Revisao da entrega do parceiro – Revisao por parte da equipa de projectos dos entregaveis do parceiro,com a passagem para ambiente de qualidade, revisao da especificacao tecnica, planeamento dos testes de aceitacaoe execucao de testes sistema ao projecto.
GPM-HA1.1 – Preparacao do ambiente de qualidade com o auxılio do parceiro para a execucao de testes de sistema e testesde aceitacao.
GPM-HA1.2 – Passagem do projecto para ambiente de qualidade sob a supervisao do parceiro.
GPM-HA1.3 – Revisao da especificacao tecnica e ajuste de detalhes/decisoes de implementacao com possıveis pedidos decorreccao/alteracao.
GPM-HA1.4 – Planeamento dos testes de aceitacao, com a definicao do plano de testes (calendario, recursos necessarios,responsaveis e testes de aceitacao).
GPM-HA1.5 – Execucao de testes de sistema do projecto.
GPM-HA1.6 – Aceitacao dos testes de sistema do projecto.
GPM-HA2 – Testes de aceitacao com a area de negocio – Execucao dos testes de aceitacao com a area de negociopara a aceitacao final do projecto.
GPM-HA2.1 – Execucao dos testes de aceitacao pela area de negocio.
GPM-HA2.2 – Aprovacao dos testes de aceitacao.
GPM-HA2.3 – Formalizacao da aceitacao do projecto pela area de negocio com a assinatura do auto de aceitacao.
GPM-HA2.4 – Aceitacao do projecto pela area de projectos com a assinatura do auto de aceitacao por parte da area deprojectos.
GPM-HA3 – Realizacao do plano de handover a area de O&M – Preparacao do handover do projecto a area de O&Mcom passagem de documentacao, preparacao de ambientes e aceitacao de logs de riscos, issues e alteracoes quepassam a ser responsabilidade da area de O&M.
GPM-HA3.1 – Compilacao e passagem de documentacao tecnica e de gestao do projecto.
GPM-HA3.2 – Preparacao dos ambientes de producao pela area de O&M de acordo com as configuracoes disponibilizadaspela area de projectos e pelo parceiro.
GPM-HA3.3 – Execucao dos testes de aceitacao da area de O&M para inıcio do handover.
GPM-HA3.4 – Aprovacao dos testes de aceitacao pela area de O&M.
GPM-HA3.5 - Aceitacao de log de riscos.
GPM-HA3.6 - Aceitacao de log de issues.
GPM-HA3.7 - Aceitacao de log de alteracoes.
GPM-HA3.8 – Formalizacao do handover do projecto com a producao e assinatura do documento de handover e do auto deaceitacao;
Tabela 4.16: Actividades detalhadas de aceitacao do projecto.
necessaria para lidar com futuros pedidos de manutencao que possam surgir, garantindo que nao
existirao questoes em aberto a tratar com recursos da area de projectos, que nessa fase se encontrarao
alocados a outros projectos e ja sem capacidade para enderecar este tipo de questoes.
4.5.2 Vista de Responsabilidades
A vista de responsabilidades da fase de handover possui um interesse especial nesta arquitectura na
medida em que define de que forma e feita a transicao do projecto da area de projectos para a area
de O&M, a qual ira passar a ser responsavel pelo mesmo. Alem disso, e tambem nesta fase que a
participacao do parceiro no projecto, responsavel pela sua implementacao, termina com a aceitacao do
projecto.
Na revisao da entrega do parceiro, a area de projectos e responsavel pela realizacao de todas
61
Figura 4.15: Fluxo do processo relativo a passagem a producao e encerramento do projecto.
as actividades em estrita colaboracao com o parceiro, nomeadamente na preparacao e passagem do
projecto para ambiente de qualidade que, embora realizada pela area de projectos, necessita de apoio
por parte do parceiro. Dependendo da complexidade do projecto, podera variar de uma actividade
de simples supervisao ate a partilha de responsabilidades na sua execucao. Apos a passagem a
ambiente de qualidade, embora o parceiro seja consultado num conjunto de outras actividades, as suas
responsabilidades diminuem ate a sua saıda no encerramento do projecto.
A situacao da area de O&M e inversa a do parceiro, tendo em conta que o conjunto de respons-
abilidades da mesma aumenta a partir da realizacao do plano de handover, onde a area de projectos
e responsavel apenas pela passagem da documentacao e pelo inıcio do processo de passagem de
conhecimento e responsabilidades. A area de O&M aceita todos os logs do projecto, entregues pela
area de projectos e formaliza o handover com a assinatura do auto de aceitacao, garantindo assim es-
tar na posse de toda a informacao necessaria para gerir futuros pedidos de manutencao. A passagem
do projecto para ambiente de producao e ja realizada pela area de O&M, com a consulta da area de
projectos e do parceiro para resolucao de eventuais questoes que possam surgir.
Nas actividades de aceitacao do projecto, a area de negocio desempenha o principal papel com a
aprovacao dos testes de aceitacao do projecto, na medida em que correspondem ao principal stake-
holder do projecto e a origem do mesmo. A area de projectos aceita a implementacao do projecto pelo
62
parceiro e a area de O&M aceita o handover do projecto feito pela area de projectos, ja depois de aceite
pela area de negocio. As responsabilidades relativas a aceitacao do projecto encontram-se detalhadas
na tabela 4.17.
Actividades Projectos O&M P&C Director
DSIParceiro Negocio
GPM-HA - Revisao da entrega do parceiro
GPM-HA1.1 X/P C C
GPM-HA1.2 X/P I C I
GPM-HA1.3 X/P A C
GPM-HA1.4 X/P I I I C
GPM-HA1.5 X/P I C
GPM-HA1.6 X/P/D d C I
GPM-HA2 - Testes de aceitacao com a area de negocio
GPM-HA2.1 X/P I I C
GPM-HA2.2 X/P/d I I D
GPM-HA2.3 X/P I I I I C
GPM-HA2.4 X/P/d I D I
GPM-HA3 - Realizacao do plano de handover a manutencao
GPM-HA3.1 X/P C C
GPM-HA3.2 P X I C
GPM-HA3.3 P X I I
GPM-HA3.4 P X/d D I
GPM-HA3.5 P X/d D I
GPM-HA3.6 P X/d D I
GPM-HA3.7 P X/d D I
GPM-HA3.8 P X I I I
Tabela 4.17: Vista de responsabilidades das actividades de aceitacao do projecto.
O encerramento do projecto e da responsabilidade das areas de projectos e de planeamento e
controlo pelo facto de serem as areas que acompanharam todo o projecto e que desempenharam
as principais actividades, estando a partir deste momento desalocadas de actividades do projecto. A
area de projectos realiza o encerramento tecnico, com a compilacao da informacao mais relacionada
com a gestao do projecto, e a area de planeamento e controlo realiza o encerramento administrativo,
directamente ligado com o encerramento de contractos, orcamento e plano de pagamentos.
4.5.3 Vista de Informacao
Relativamente a vista de informacao da fase de handover, importa destacar dois dos documentos de
suporte provenientes desta fase, o auto de aceitacao e o documento de handover. O auto de aceitacao
reune toda a informacao relativa ao processo de aceitacao do projecto, reunindo os logs de projecto e
os testes de aceitacao realizados. E produzido pela area de projectos e assinado por esta em conjunto
com a area de O&M e a area de negocio. O documento de handover formaliza a passagem do projecto
63
da area de projectos para a area de O&M, apresentando, entre outra informacao que a organizacao
considere relevante, os logs do projecto aceites pela area e os responsaveis pela sua aceitacao.
No encerramento do projecto sao ainda definidos o relatorio de fecho do projecto, que compila um
conjunto de documentacao relativa ao encerramento do projecto, e as licoes aprendidas, documento
que resulta do feedback dos varios intervenientes em todo o processo de gestao do projecto juntamente
com a experiencia adquirida pelo gestor de projecto. O conjunto de documentos de suporte relativos a
fase de handover sao detalhados na tabela A.4 do anexo A.4.
Em termos da matriz CRUF da fase de handover, apresentada na tabela 4.18, destaca-se a criacao
dos documentos de suporte relativos a esta fase e a actualizacao e fecho do plano de gestao de pro-
jecto, dos logs de riscos, issues e alteracoes e do contracto de compra. O fecho dos restantes doc-
umentos, pertencentes apenas a fase de handover nao foi considerado tendo em conta o seu curto
ciclo de vida e osbjectivos especıficos a que sao aplicados. E ainda possıvel destacar o conjunto de
interacoes de actualizacao relativas ao relatorio de fecho de projecto e das licoes aprendidas, docu-
mentos que resultam do feedback e da informacao manipulada por um conjunto de areas da direccao
dos sistemas de informacao.
Documentos de suporte Projectos O&M P&C Compras Director
DSIParceiro Negocio
Plano de gestao de projecto R/U/F R/U R R
Log de riscos R/U R/U/F
Log de issues R/U R/U/F
Log de alteracoes R/U R/U/F
Auto de aceitacao C/R/U R/U R R/U
Documento de handover C/R/U R/U R
Relatorio de fecho de projecto C/U R/U R/U R/U R/U
Licoes aprendidas C/U R/U R/U R/U R/U
Contracto de compra R/U/F R
Tabela 4.18: Matriz CRUF dos documentos de suporte da fase de handover do processo.
64
Capıtulo 5
Avaliacao
Neste capıtulo e apresentada a avaliacao da arquitectura de processos, de acordo com a fase de
avaliacao do DSRM. Tendo em conta o conjunto de questoes identificadas na definicao do problema
como guias para o desenvolvimento desta arquitectura, e apresentado um conjunto de resultados que
vai ao encontro da resposta a essas questoes:
1. Questao 1 - Que processos (e correspondentes actividades) devem ser executados para a gestao
de pedidos de execucao de projectos e manutencoes?
A arquitectura de processos desenvolvida, dividida nas fases de oportunidade, de planeamento,
de implementacao e controlo e de handover, de acordo com o ciclo de vida dos projectos consid-
erado, apresenta o conjunto de actividades a realizar por uma direccao de sistemas de informacao
de forma a gerir pedidos de projectos e manutencoes que lhe sao propostos.
A vista de processos de cada uma das fases apresenta o fluxo do processo, identificando ainda
um conjunto de actividades detalhadas a executar em cada macro-actividade. O conjunto das
vistas de processos desta arquitectura cobre todo o ciclo de vida de um pedido de projecto, desde
a sua classificacao ate a entrega do projecto a area de negocio, passando pelo seu planeamento
e controlo. Relativamente a pedidos de manutencao, estes podem ser integrados em servicos de
manutencao, cuja implementacao e realizada externamente por um parceiro, ou agendados para
manutencao interna, assumindo-se que toda a sua posterior gestao sera realizada de acordo com
um processo ja definido na organizacao.
Todo o desenho foi realizado a partir dum caso real de uma organizacao, de forma a permitir
uma visao mais detalhada do problema e de possıveis solucoes bem como ter consciencia dos
aspectos mais crıticos na gestao dos pedidos em casos reais. Apesar de baseada num caso
real, a arquitectura apresentada neste documento generaliza aspectos do processo intrınsecos a
organizacao, mantendo-se apenas as actividades genericas passıveis de serem adoptadas por
qualquer direccao de sistemas de informacao que esteja alinhada com os constrangimentos ap-
resentados pelo problema considerado.
65
2. Questao 2 - Quais as responsabilidades dos varios elementos da direccao dos sistemas de
informacao em todo o processo?
De acordo com a estrutura organizacional considerada no caso real, foram definidas, para cada
actividade detalhada na vista de processos, um conjunto de responsabilidades dos intervenientes
do processo, pertencentes a direccao dos sistemas de informacao. Esta definicao de responsabil-
idades foi realizada, numa primeira fase, de acordo com a actual definicao de responsabilidades
na organizacao, sendo posteriormente analisada e alinhada com a vista de processos definida e
proposto um conjunto de alteracoes as responsabilidades incialmente definidas.
Todas as alteracoes foram revistas e aprovadas em reunioes de validacao com os stakeholders
de forma a garantir que a definicao de responsabilidades se encontra tanto alinhada com a vista
de processsos como com os intervenientes em todo o processo. Apesar de algumas referencias
analisadas no capıtulo 2 apresentarem abordagens a definicao de responsabilidades, todo o tra-
balho apresentado nesta vista foi realizado originalmente.
3. Questao 3 - Quais os documentos que suportam todo o processo?
A vista de informacao agrega um conjunto de documentos de suporte ao processo, detalhando-os
de acordo com a informacao que disponibilizam e com os seus objectivos. Sao definidos os princi-
pais documentos de suporte considerados no processo, inicialmente identificados de acordo com
as referencias analisadas no capıtulo 2 e mais tarde adicionados e adaptados novos documentos
de acordo com as necessidades da vista de processos.
De forma a integrar esta vista com as anteriores, foi proposta e validada uma definicao de matriz
CRUF dos documentos de suporte, que para cada documento apresenta o conjunto de interacoes
realizadas pelos intervenientes do processo.
A solucao foi desenvolvida num espaco de tempo limitado, razao pela qual foi necessario tomar
varias decisoes de desenho, nomeadamente o conjunto de processos a cobrir pela arquitectura. Considerou-
se um conjunto limitado de processos, em detrimento de cobrir todos os apresentados pelas referencias
em menor detalhe, de forma a definir uma arquitectura com relevancia para o problema e que enderece
um conjunto de tematicas que os stakeholders consideram as mais importantes.
Outro objectivo definido para esta arquitectura era a sua conformidade com as melhores praticas
em gestao de projectos e manutencoes de acordo com as referencias consideradas no capıtulo 2.
Dessa forma, durante todo o desenho da arquitectura foram analisados e seleccionados um conjunto
de processos apresentados nas referencias, procedendo-se a algumas adaptacoes de forma a ir ao
encontro dos nossos objectivos.
Tendo em conta o caso real de uma organizacao como ponto base para a definicao desta arquitec-
tura, foi necessario ir ao encontro de todas as expectativas dos stakeholders relativas a arquitectura a
desenhar. Ao longo do processo de desenvolvimento foram realizadas reunioes de validacao da arqui-
tectura com os stakeholders, de forma a garantir a sua satisfacao. Apesar da sua importancia em todas
66
as vistas, foi na vista de responsabilidades que o feedback dos stakeholders foi mais importante pelo
facto de se tratar de trabalho original que nao se encontrava contemplado em nenhuma referencia.
Foi tambem estabelecido como objectivo generalizar aspectos intrınsecos a organizacao, razao pela
qual a arquitectura de processos apresentada neste documento difere da arquitectura desenvolvida
considerando apenas o caso real da organizacao. Aspectos especıficos a organizacao nao foram con-
templados nesta versao da arquitectura, optando-se por nao os detalhar e apresentar apenas a sua
generalizacao. Porem, a arquitectura apresentada obedece a um conjunto de constrangimentos, moti-
vados pela extensao do tema e impossibilidade de cobrir o problema na sua forma mais generica.
5.1 Avaliacao com Stakeholders
Tendo em conta o alinhamento com o caso real de uma organizacao, foi necessario considerar os
principais stakeholders durante o desenho da arquitectura. Foi desenvolvido um documento designado
por manual do processo, que apresenta toda a arquitectura de acordo com os objectivos e as normas
da organizacao, atraves de um processo iterativo, no qual a arquitectura de processos foi avaliada e o
feedback proveniente dessa avaliacao utilizado para a producao de versoes melhoradas da mesma.
Tendo em conta a disponibilidade reduzida dos principais stakeholders desta arquitectura, considerou-
se um representante dos mesmos em todo o processo de avaliacao, que possui um conhecimento
profundo de toda a organica da organizacao e dos objectivos que a mesma procura ver alcancados
na gestao de projectos e manutencoes. Este representante ira ser designado apenas por stakeholder,
tendo em conta que representa o conjunto de todos os stakeholders. Numa primeira fase, foi necessario
interagir directamente com o stakeholder de forma a compreender de que forma a organizacao realiza a
gestao dos pedidos de projectos e manutencoes e quais as actividades actualmente realizadas, identifi-
cando aspectos que nao se encontram devidamente contemplados no processo as-is e que necessitam
de melhorias.
Face a todo o levantamento de informacao realizado e as referencias consideradas, foram definidas
a vista de processos e a vista de informacao das quatro fases, procedendo-se para cada fase a uma
sessao de apresentacao e validacao das vistas. Nestas sessoes foram apresentadas versoes destas
vistas e levantado um conjunto de alteracoes e sugestoes resultantes do feedback do stakeholder.
Apos cada sessao, foi produzida uma nova versao da arquitectura de acordo com o feedback recebido,
sujeita a nova sessao de validacao ate ser aceite pelo stakeholder e tornada a versao final.
Apos a versao final das vistas de processos e de informacao definida, iniciou-se a definicao da vista
de responsabilidades. Para cada fase foi definida uma versao inicial da vista de responsabilidades que
foi depois apresentada, alinhada e validada em sessoes de revisao com o stakeholder. Esta vista foi
aquela que exigiu um maior esforco de desenvolvimento, na medida em que foram necessarias mais
alteracoes e negociacoes de forma a alinha-la tanto com os objectivos de desenho da arquitectura como
com os objectivos do stakeholder.
A arquitectura de processos definida no manual do processo, bem como a versao generalizada
apresentada nesta dissertacao, apresentam assim uma arquitectura que foi alvo de um conjunto de
67
sessoes de avaliacao e validacao com os stakeholders, alcancando-se uma solucao alinhada com os
seus objectivos e com os principais principios de gestao de projectos e manutencoes apresentados
pelas referencias consideradas.
5.2 Mapeamento com Referencias
De acordo com a fase de avaliacao do metodo DSRM aplicado, um dos metodos de avaliacao pro-
postos foi o mapeamento com referencias, que pretende demonstrar de que forma foi garantida a
conformidade da arquitectura de processos com as melhores praticas na area de gestao de projec-
tos e manutencoes. Assim, este metodo estabelece um correspondencia entre os processos definidos
na arquitectura e aqueles que sao identificados no conjunto de referencias analisadas, garantindo a
existencia de evidencias concretas desta conformidade.
5.2.1 Fase de Oportunidade
Em termos da fase de oportunidade, a actividade de identificacao da oportunidade encontra-se apenas
contemplada na ISO 21500 e no PMBOK, embora nao fazendo parte do ambito de nenhuma delas.
Segundo a ISO 21500, as oportunidades devem ser avaliadas de forma a decisao da sua aceitacao ser
suportada e informada. O PMBOK assume apenas a existencia do caso de negocio e do statement
of work nos processos identificados, nao apresentando quaisquer processos para a sua definicao. A
actividade de classificacao de oportunidade e semelhante a de identificacao, sendo apenas considerada
na ISO 21500 como um conjunto de actividades que levam a obtencao de autorizacao para iniciar um
novo projecto, tendo a organizacao de encontrar um elemento responsavel pelo mesmo. Por essa
razao, e nesta fase que e realizada a classificacao da oportunidade em oportunidade de projecto ou de
manutencao, sendo posteriormente entregue a uma das respectivas areas.
Terminada a classificacao da oportunidade, todas as actividades encontram uma correspondencia
com processos identificados tanto na ISO 21500 como no PMBOK. A actividade de analise de opor-
tunidade corresponde as actividades de desenvolvimento do project charter considerada pelas duas
referencias, onde e feita a identificacao das responsabilidades e autoridades do projecto e documen-
tadas as necessidades de negocio, os objectivos a atingir, os entregaveis esperados e os aspectos
economicos do projecto. Como extensao a esta actividade, optou-se ainda por considerar a analise de
calendario e de riscos, aspectos importantes na posterior avaliacao da oportunidade no contexto do
portfolio.
Apos a oportunidade analisada, toda a integracao da oportunidade em portfolio e justificada pela
definicao de gestao de portfolio apresentada pela ISO 21500 e pelo PMBOK, definida como uma gestao
centralizada de um conjunto de projectos e programas em conjunto, de forma a atingir objectivos es-
trategicos. A definicao de prioridade, orcamento e calendario e justificada pela sua relevancia para os
planos estrategicos da organizacao. A integracao em portfolio encontra-se ainda apresentada no CO-
BIT nos processos PO1 - Define a strategic IT plan e PO5 - Manage IT investment, que apresentam a
68
analise de portfolios de projectos e servicos e a manutencao do portfolio de projectos, respectivamente.
Em termos da analise de oportunidades de manutencao e integracao em portfolio de servicos,
realizou-se uma correspondencia directa com as oportunidades de projecto, sendo identificadas as
mesmas referencias. Relativamente ao planeamento da manutencao, o trabalho realizado foi sobre-
tudo original considerando o caso real da organizacao.
Os processos identificados pela ISO/IEC 14764, orientada a processos de manutencao, tambem
poderiam ter sido considerados como referencia. Porem, esta referencia possui um caracter mais op-
eracional, optando-se por manter o processo de identificacao da oportunidade de manutencao generico
e semelhante ao das oportunidades de projecto. Na tabela 5.1 e apresentada o mapeamento com re-
ferencias relativo a fase de oportunidade.
Actividades ISO 21500 PMBOK COBIT ITIL ISO 31000
GPM-OP1 - Identificacao da oportunidade
GPM-OP2 - Classificacao da oportunidade
GPM-OP3 - Analise da oportunidade de projecto
GPM-OP4 - Integracao em portfolio de projectos
GPM-OP5 - Analise da Oportunidade de manutencao
GPM-OP6 - Planeamento da manutencao evolutiva
GPM-OP7 - Integracao em portfolio de servicos de manutencao
Tabela 5.1: Mapeamento com referencias relativo a fase de oportunidade.
5.2.2 Fase de Planeamento
A ISO 21500 apresenta um grupo de processos referentes a esta fase, identificando processo utiliza-
dos para desenvolver todo o detalhe do planeamento do projecto, sendo suficiente para definir todas as
baselines de gestao sobre as quais o mesmo ira ser desenvolvido. O PMBOK apresenta o planeamento
do projecto como o processo de definicao, preparacao e coordenacao de um conjunto de planos sub-
sidiarios e individuais a serem integrados num plano de gestao de projecto. O COBIT por sua vez define
o processo PO10 - Manage Projects que reune um conjunto de actividades necessarias a definicao do
plano de gestao de projecto.
A revisao do plano de gestao de projecto e justificada no PMBOK e na ISO 21500 com a utilizacao
dos documento de suporte da fase de oportunidade (statement of work, project charter e caso de
negocio) como inputs para a definicao do plano de gestao de projecto, sendo necessario rever toda a
informacao constante nestes documentos. Estas referencias consideram ainda como input do plano de
gestao de projecto todos os planos de gestao individuais definidos ao longo da fase, razao pela qual
tambem existe uma revisao do plano de projecto no final da fase de planeamento, com o objectivo de
rever todos os planos indiviuais e dar inıcio a implementacao do projecto.
As duas revisoes do plano de gestao do projecto sao ainda justificadas pelo COBIT, que apresenta
a necessidade de revisao e aceitacao de todos os entregaveis da fase anterior para aprovacao de
entrada numa nova fase do projecto. Assim, no inıcio da fase de planeamento e necessario rever toda
69
a informacao recolhida durante a fase de oportunidade e no final da fase garantir que todos os planos
desenvolvidos se encontram devidamente definidos para inıcio da implementacao do projecto.
O PMBOK e a ISO 21500 apresentam a identificacao de stakeholders como um processo inicial a
considerar na gestao dos mesmos. Em termos de definicao do plano de gestao de stakeholders, a ISO
21500, ao contrario do PMBOK, nao considera a definicao de um plano de gestao individual, apresen-
tando apenas um processo dividido em duas fases, a fase de planeamento e a fase de implementacao
e controlo, esta ultima com o objectivo de controlar e monitorizar as expectativas dos stakeholders.
Optou-se, a imagem do que e apresentado pelo PMBOK, manter o plano de gestao de stakeholders
individualmente, de forma a englobar toda a informacao relativa a sua gestao. O COBIT tambem apre-
senta actividades orientadas a garantia de participacao dos stakeholders na definicao e execucao do
projecto.
Em termos de gestao de risco, a ISO 21500 e o PMBOK apresentam abordagens semelhantes com
a definicao do plano de gestao de riscos. Porem, a gestao de risco e vista como um processo vital na
organizacao pelos principais stakeholders, com consequencias graves em situacoes onde os riscos nao
sao devidamente controlados. Por essa mesma razao, considerou-se tambem a norma internacional
orientada a gestao de risco, a ISO 31000, que alem de apresentar a definicao do plano de gestao de
risco identifica tambem actividades detalhadas relativamente ao tratamento e controlo de riscos. O
COBIT tambem dedica um processo exclusivo a gestao de risco, o PO9 - Assess and Manage Risks.
Em termos de gestao de risco, a principal referencia e a ISO 31000, sendo tambem considerado o
PMBOK e o COBIT.
O planeamento de comunicacoes e justificado pelos processos apresentados pela ISO 21500 e pelo
PMBOK, sendo o ultimo a principal referencia na medida em que apresenta uma grande extensibilidade
nesta area com o processo de planeamento da gestao de comunicacoes. O COBIT apresenta ape-
nas actividades de monitorizacao e comunicacao da performance do projecto, directamente ligadas a
aspectos de comunicacao do projecto.
Em termos de todo o processo de compra, as principais referencias consistem nos processos de
gestao de compras apresentados pea ISO 21500 e pelo PMBOK, a primeira dividindo o processo no
planeamento da compra e na seleccao de parceiros e a segunda no planeamento e no controlo da
compra. O COBIT apresenta tambem um conjunto de referencias uteis no procedimento de compra no
processo AI5 - Procure IT Resources, semelhante aos processsos referidos anteriormente e apresen-
tando um foco na definicao do contracto de compra, com as actividades AI5.2 e AI5.4 de gestao de
contractos com o parceiro e de aquisicao de recursos de tecnologias de informacao, respectivamente.
Relativamente a gestao de custos, a ISO 21500 e o PBMOK correspondem as principais referencias,
a primeira com os processos de estimativa de custos e definicao de orcamento e a segunda com
os processos de desenvolvimento do plano de gestao de custos, estimativa de custos e definicao do
orcamento. Em termos de gestao de calendario, a ISO 21500 apresenta um conjunto de processos
mais operacionais, com o sequenciamento de actividades, a estimativa de duracao dessas actividades
e a definicao do calendario de projecto. Por seu lado, o PMBOK apresenta apenas os processos de
gestao do plano de calendario e de definicao do calendario de projecto. Na tabela 5.2 e apresentado o
70
mapeamento com referencias relativo a fase de Planeamento.
Actividades ISO 21500 PMBOK COBIT ITIL ISO 31000
GPM-PL1 - Revisao do planeamento de projecto
GPM-PL2 - Identificacao de stakeholders
GPM-PL3 - Definicao do plano de gestao de stakeholders
GPM-PL4 - Definicao do plano de gestao de riscos
GPM-PL5 - Definicao do Plano de Gestao de Comunicacoes
GPM-PL6 - Planeamento da compra
GPM-PL7 - Consulta ao mercado
GPM-PL8 - Seleccao de proposta
GPM-PL9 - Definicao do contracto de compra
GPM-PL10 - Planeamento de custos do projecto
GPM-PL11 - Planeamento de calendario do projecto
GPM-PL12 - Revisao do plano de gestao de projecto
Tabela 5.2: Mapeamento com referencias relativo a fase de planeamento.
5.2.3 Fase de Implementacao e Controlo
A gestao semanal e mensal do projecto possui as principais referencias na ISO 21500 e no PMBOK,
na medida em que sao apresentados grupos de processos dedicados ao controlo de todo o projecto.
Nenhuma das referencias apresenta a distincao entre o controlo semanal e mensal, apresentando sem
distincao processos de controlo mais operacionais e outros mais estrategicos. A ISO 21500 apresenta
os grupos de processos de implementacao e processos de controlo, estando os primeiros mais ligados
ao controlo semanal com a definicao de actividades a realizar pela equipa durante a semana e o se-
gundo ligado aos controlos semanais e mensais com controlo de orcamento, calendario, comunicacao,
stakeholders, riscos e alteracoes. O PMBOK tambem apresenta um grupo de processos dedicado
ao controlo e monitorizacao do projecto, com processos para a gestao de custos, calendario, riscos,
comunicacoes e stakeholders.
O processo de gestao de alteracoes e identificado na ISO 21500 no processo de controlo de
alteracoes e no PMBOK no processo de controlo integrado de alteracoes. O processo identificado
e identico nas duas referencias, nao apresentando um grande detalhe mas cobrindo todo o ciclo de
vida da alteracao ate ao seu encerramento.
Relativamente a gestao de risco, a principal referencia e a ISO 31000, que apresenta um maior
detalhe neste processo que a ISO 21500 e o PMBOK. A ISO 21500 divide o processo na identficacao,
avaliacao e tratamento dos riscos enquanto que o PMBOK apresenta a identificacao, a analise quan-
titativa e qualitativa do risco e o planeamento das respostas aos riscos. Ja a ISO 31000, apresenta
actividades de identificacao, analise, avaliacao, seleccao de medidas de tratamento e definicao do
plano de tratamento de riscos, apresentando um maior detalhe e coesao entre todas as actividades
apresentadas.
71
A gestao de issues nao e considerada em nenhuma das principais referencias analisadas, considerando-
se por isso o processo para a gestao de incidentes apresentado pelo ITIL para a definicao do processo
de gestao de issues, possuındo um ambito e objectivos semelhantes. Os processos de categorizacao,
prioritizacao, diagostico e escalamento do incidente foram directamente aplicados a analise do issue,
correspondendo o processo de investigacao e diagnostico do incidente ao aplicado no diagnostico do
issue. A resolucao e recuperacao do incidente e o seu fecho foram aplicados na resolucao e fecho do
issue, respectivamente. Na tabela 5.3 e apresentado o mapeamento com referencias relativo a fase de
implementacao e controlo.
Actividades ISO 21500 PMBOK COBIT ITIL ISO 31000
GPM-SE - Gestao semanal do projecto
GPM-SE1 - Controlo semanal do projecto
GPM-ME - Gestao mensal do projecto
GPM-ME1 - Controlo mensal do projecto
GPM-AL - Gestao de alteracoes
GPM-AL1 - Definicao de ambito da alteracao
GPM-AL2 - Analise da alteracao
GPM-AL3 - Planeamento da alteracao
GPM-AL4 - Controlo da alteracao
GPM-AL5 - Fecho da alteracao
GPM-RI - Gestao de riscos
GPM-RI1 - Registo do risco
GPM-RI2 - Analise do risco
GPM-RI3 - Identificacao de medidas de tratamento do risco
GPM-RI4 - Seleccao de medidas de tratamento do risco
GPM-RI5 - Definicao do plano de tratamento do risco
GPM-IS - Gestao de issues
GPM-IS1 - Registo do issues
GPM-IS2 - Analise preliminar do issues
GPM-IS3/5 - Diagnostico do issues
GPM-IS4/6 - Resolucao do issues
GPM-IS7 - Fecho do issues
Tabela 5.3: Mapeamento com referencias relativo a fase de implementacao e controlo.
5.2.4 Fase de Handover
A fase de handover possui como principal referencia o COBIT, que cobre todos os aspectos de aceitacao
do projecto, entrega a manutencao, passagem a ambiente de producao e encerramento do projecto. A
ISO 21500 e o PMBOK abordam superficialmente alguns destes aspectos, nomeadamente o encerra-
mento do projecto, sendo importante para complementar os processos apresentados pelo COBIT.
Em termos da revisao da entrega do parceiro e dos testes aceitacao com o negocio, a ISO 21500
apresenta a necessidade de garantir que todos as actividades e entregaveis do projecto foram termi-
72
nados, de forma a assegurar que as varias fases do projecto se encontram completas. Ja o PMBOK
identifica nesta fase a realizacao de actividades de revisao de toda a informacao proveniente de fases
anteriores do projecto e a realizacao de actividades de aceitacao do projecto pelo cliente de forma a
garantir que o projecto reune todos os requisitos para o seu encerramento. Ja o COBIT apresenta
uma abordagem mais fina, apresentando processos de revisao apos a implementacao do projecto, de
planeamento de testes e de execucao de testes de aceitacao final.
Relativamente a realizacao do plano de handover a manutencao e a passagem do projecto para
ambiente de producao, o PMBOK afirma apenas que devem ser realizadas actividades com o objectivo
de transferir os produtos e servicos do projecto para a proxima fase ou para ambiente de producao,
referindo ainda a possibilidade de estes passarem para a area de operacoes e manutencao. O COBIT
apresenta um conjunto de processos para o handover a manutencao, nomeadamente o planeamento
do handover, a transferencia de conhecimento para a area de manutencao e a definicao de procedimen-
tos e tarefas a serem executadas pela area de manutencao de forma a assegurar que esta se encontra
preparada para as tarefas a realizar no futuro. Em termos da passagem do projecto para producao, o
COBIT apresenta um processo dedicado, com a realizacao de actividades que consideramos pertencer
ao processo de planeamento do handover mas tambem com novas actividades relativas a execucao do
projecto em ambiente de producao.
O encerramento tecnico do projecto faz parte das tres principais referencias consideradas nesta
fase, todas elas apresentando a coleccao das licoes aprendidas e o encerramento de todas as activi-
dades de projecto como as principais tarefas a realizar para o seu fecho. O encerramento administrativo
do projecto encontra-se especialmente enderecado pelo PMBOK, que identifica directamente o encer-
ramento das actividades de compra e de todos os contractos estabelecidos, embora se considere estas
actividades parte da actividades de encerramento do projecto identificadas tambem pela ISO 21500 e
pelo COBIT. Na tabela 5.4 e apresentado o mapeamento com referencias relativo a fase de handover.
Actividades ISO 21500 PMBOK COBIT ITIL ISO 31000
GPM-HA1 - Revisao da entrega do parceiro
GPM-HA2 - Testes de aceitacao com o negocio
GPM-HA3 - Realizacao do plano de handover a manutencao
GPM-HA4 - Transferencia de ambiente de qualidade para producao
GPM-HA5 - Encerramento tecnico do projecto
GPM-HA6 - Encerramento administrativo do projecto
Tabela 5.4: Mapeamento com referencias relativo a fase de handover.
73
Capıtulo 6
Conclusao e Trabalho Futuro
Neste capıtulo sao apresentadas as principais conclusoes relativas ao trabalho desenvolvido bem como
identificado um conjunto de propostas futuras a desenvolver de forma a dar continuidade a todo o
trabalho realizado.
Este trabalho teve como principal objectivo a definicao de um processo de gestao de pedidos de
projectos e manutencoes nas direccoes de sistemas de informacao, tendo como referencia um caso
real de uma organizacao. Tendo em conta este caso real, foram definidas duas versoes da arquitectura,
uma aplicada ao caso real considerado e apresentada por um manual do processo, e uma versao gen-
eralizada da arquitectura aplicavel a um conjunto de direccoes de sistemas de informacao, apresentada
neste documento.
Considerando as principais referencias na gestao de projectos e manutencoes nas organizacoes,
foram identificados os principais processos a definir para a correcta gestao de pedidos de projectos e
manutencoes, sendo definida uma arquitectura de processos dividida em tres vistas: a vista de proces-
sos, a vista de responsabilidades e a vista de informacao.
A arquitectura desenvolvida foi divida em quatro fases, de acordo com o ciclo de vida dos projectos
considerado. A fase de oportunidade, comum a pedidos de projectos e manutencao, termina com a
integracao da oportunidade num portfolio de projectos ou de servicos de manutencao, podendo tambem
terminar com o agendamento da manutencao, caso se trate de um pedido deste tipo. Apos esta fase,
sao detalhadas as fases de planeamento, de implementacao e controlo e de handover, confinadas a
oportunidades de projecto.
Para cada fase da arquitectura de processos foram definidas a vista de processos, que apresenta
o fluxo do processo em termos de actividades a realizar, a vista de responsabilidades, que identifica
as principais responsabilidades dos intervenientes no processo durante a respectiva fase e a vista de
informacao, que apresenta os principais documentos de suporte da fase do processo. Estas tres vistas,
em conjunto, definem toda a arquitectura de processos para a gestao de pedidos de projectos e de
manutencoes nas direccoes de sistemas de informacao.
A avaliacao da arquitectura foi realizada de acordo com dois metodos propostos e inseridos na
fase de avaliacao do metodo DSRM aplicado. De forma a ir ao encontro do caso real da organizacao
74
considerado, foi conduzida uma avaliacao com stakeholders, de forma a garantir o cumprimento de
um conjunto de requisitos e objectivos dos principais interessados na arquitectura. Tendo em conta
as principais referencias na gestao de projectos e manutencoes, foi tambem considerado o metodo de
mapeamento com referencias, que estabelece um conjunto de correspondencias entre os processos
definidos na arquitectura e aqueles que sao definidos pelas referencias, obtendo-se, para todos os
processos, um conjunto de correspondencias com as referencias consideradas.
A escolha dos processos a incluir na arquitectura foi definida tendo em conta o conjunto de pro-
cessos que iam ao encontro dos interesses dos stakeholders, sendo necessario definir um conjunto de
processos limitado. Processos como a gestao de ambito e a gestao de qualidade nao foram considera-
dos na arquitectura, embora apresentados no conjunto de referencias analisadas, sendo interessante,
no futuro, considerar um conjunto adicional de processos.
As oportunidades de manutencao sao consideradas apenas na fase de oportunidade, a partir da
qual sao integradas em servicos de manutencao ou agendadas para implementacao. Esta decisao
cria uma lacuna na gestao dos pedidos de manutencao posterior a fase de oportunidade, caso a
organizacao nao possua nenhum processo para o efeito. Esta decisao foi tomada de acordo com
o nıvel de granularidade pretendido para a arquitectura, considerando-se a gestao dos pedidos de
manutencao a um nıvel de granularidade demasiado fino apos a fase de oportunidade. Podera, no
entanto, ser definido um processo de gestao de pedidos de manutencao de acordo com o processo ja
definido.
75
Bibliografia
[1] E.S. Andersen, K. Grude, and T. Haug. Goal Directed Project Management: Effective Techniques
and Strategies. Kogan Page, 2009.
[2] Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK R©
Guide). PMI Standard. Project Management Institute, Incorporated, 2013.
[3] ISACA. COBIT 5: A Business Framework for the Governance and Management of Enterprise IT.
COBIT R© 5. ISACA, 2012.
[4] ISACA. COBIT 5: Enabling Processes. COBIT R© 5. ISACA, 2012.
[5] ISO. Risk management – principles and guidelines. ISO 31000:2009, International Organization
for Standardization, 2009.
[6] ISO. Guidance on project management. ISO 21500:2012, International Organization for Standard-
ization, 2012.
[7] ISO/IEC. Software engineering – software life cycle processes - maintenance. ISO/IEC
14764:2006, International Organization for Standardization and International Electrotechnical Com-
mission, 2006.
[8] ISO/IEC. Systems and software engineering – software life cycle processes. ISO 12207-1:2008, In-
ternational Organization for Standardization and International Electrotechnical Commission, 2008.
[9] ISO/IEC. Systems and software engineering - architecture description. ISO/IEC 42010:2011, In-
ternational Organization for Standardization and International Electrotechnical Commission, 2011.
[10] Great Britain. Cabinet Office. ITIL Continual Service Improvement. Best management practice.
TSO, The Stationery Office, 2011.
[11] Great Britain. Cabinet Office. ITIL Service Design. Best Management Practice. TSO, The Stationery
Office, 2011.
[12] Great Britain. Cabinet Office. ITIL Service Operation. Best Management Practice. TSO, The Sta-
tionery Office, 2011.
[13] Great Britain. Cabinet Office. ITIL Service Strategy. Best management practice. TSO, The Sta-
tionery Office, 2011.
76
[14] Great Britain. Cabinet Office. ITIL Service Transition. Best management practice. TSO, The Sta-
tionery Office, 2011.
[15] Great Britain. Cabinet Office. The Official Introduction to the ITIL Service Lifecycle. Best manage-
ment practice. TSO, The Stationery Office, 2011.
[16] Ken Peffers, Tuure Tuunanen, Marcus A Rothenberger, and Samir Chatterjee. A design science
research methodology for information systems research. Journal of management information sys-
tems, 24(3), 2007.
77
Appendix A
Apendices
A.1 Documentos de Suporte da Fase de Oportunidade
Documentos de
SuporteDescricao
Registo da
Oportunidade
- Registo da oportunidade em sistema de tracking da organizacao;
- Identifica a origem, o responsavel pela recepcao e o conjunto de informacao disponibilizada;
- Documento de referencia para o inıcio da analise da oportunidade;
Caso de Negocio - Apresenta a avaliacao, numa perspectiva de negocio, do conjunto de mais-valias da oportunidade;
- Identifica a necessidade de negocio e os custos e benefıcios que justificam e definem as fronteiras do projecto;
Statement of Work- Descricao dos servicos, produtos ou resultados esperados pela oportunidade;
- Identifica, entre outros aspectos: Necessidade de negocio; Descricao do ambito da oportunidade; Plano estrategico
da organizacao (visao, objectivos e metas definidas);
Project
Charter
- Atribui a autoridade ao gestor de projecto para a gestao das actividades de projecto;
- Utilizado para obter a aprovacao necessaria para inıcio do planeamento do projecto;
- Identifica: Razoes da realizacao do projecto; Objectivos mensuraveis e criterios de sucesso relacionados; Lista de
requisitos de alto nıvel; Assumpcoes e constrangimentos; Descricao de alto nıvel do projecto; Identificacao de riscos
de alto nıvel; Sumario das principais milestones do projecto; Sumario de orcamento; Lista de stakeholders; Abordagem a
solucao tecnica;
Maintenance Charter
- Atribui a autoridade ao gestor de manutencao para a gestao de actividades;
- Utilizado para obter aprovacao da manutencao;
- Identifica: Razoes da realizacao da manutencao; Objectivos mensuraveis e criterios de sucesso relacionados;
Lista de requisitos; Calendario da manutencao; Orcamento da manutencao; Recursos necessarios a manutencao; Abordagem a
solucao tecnica;
Portfolio de Projectos/
Manutencoes
- Reune conjunto de oportunidades de projectos e manutencoes geridos em conjunto para alcancar objectivos estrategicos.
- Para cada oportunidade identifica: Responsaveis; Ambito; Calendario; Orcamento; Prioridade;
Tabela A.1: Documentos de suporte ao processo relativos a fase de oportunidade.
78
A.2 Documentos de Suporte da Fase de Planeamento
Documento
de SuporteDescricao
Plano de Gestao
de Projecto
- Tem como objectivo descrever de que forma o projecto sera executado, monitorizado e controlado;
- E composto por um conjunto de baselines definidas durante a fase de planeamento: baseline de orcamento e baseline de calendario;
- Reune ainda um conjunto de planos de gestao individuais: plano de gestao de stakeholders, plano de gestao
de comunicacoes, plano de gestao de riscos, plano de gestao de orcamento, plano de gestao de calendario e plano de gestao de compras;
- Apresenta ainda um conjunto de documentos de auxilio a gestao de projecto, nomeadamente: registo de stakeholders, log de issues,
log de alteracoes, log de riscos e plano de pagamentos.
Registo
de Stakeholders
- Reune todas as informacoes de cada um dos stakeholders do projecto, nomeadamente:
- Identificacao (Nome, cargo na organizacao, papel no projecto, informacao de contacto);
- Avaliacao (Principais requisitos e expectativas para o projecto, impacto no projecto, fase do projecto em que possui maior interesse);
- Classificacao (Interno, externo, neutro - de acordo com a classificacao de stakeholders da organizacao);
- Perfil (Analise de perfil realizada atraves de entrevistas);
Plano de Gestao
de Stakeholders
- Define toda a gestao de stakeholders do projecto, identificando: Nıvel desejavel e actual de compromisso e participacao no projecto
por parte dos stakeholders; Relacoes entre stakeholders; Impacto de alteracoes para os stakeholders; Requisitos de comunicacao por fase
de projecto; Informacao a disponibilizar;
Log de Riscos
- Reune a informacao dos varios riscos identificados no projecto, nomeadamente: Identificacao do risco (causas, consequencias,
impacto e probabilidade); Medidas de tratamento do risco (Lista de medidas de tratamento aplicaveis e as medidas efectivamente aplicadas);
Responsaveis;
Plano de Gestao
de Riscos
- Define toda a gestao de riscos do projecto, identificando: Metodologia para a gestao de risco; Orcamento para a gestao de risco;
Calendarizacao das actividades de gestao de risco; Definicao de probabilidade e impacto de risco; Responsaveis;
Plano de Gestao
de Comunicacoes
- Define toda a gestao de comunicacoes do projecto, identificando: Requisitos de comunicacao; Informacao a comunicar; Canais de
comunicacao e intervenientes; Metodos de comunicacao; Calendario de comunicacao; Responsaveis pela comunicacao;
Procurement
Statement of Work
- Reune conjunto de requisitos do projecto que permitem ao parceiro avaliar se tem capacidade de implementar o projecto;
- Constitui o ponto de partida para o parceiro elaborar uma proposta;
Criterios de
Avaliacao de Propostas
- Conjunto de criterios de avaliacao que permitem avaliar e atribuir uma classificacao concreta a cada proposta recebida;
- Devera ser o mais objectivo possıvel de forma a garantir igualdade no processo de avaliacao;
Plano de Gestao
de Compra
- Documento interno que define aspectos de gestao do procedimento de compra, nomeadamente: Definicao do calendario de compra;
Definicao do orcamento de compra; Identificacao de responsabilidades no processo da compra; Analise de risco da compra;
Proposta de Compra
- Define a proposta do parceiro de acordo com o conjunto de requisitos definidos no procurement statement of work. Identifica: Orcamento
da compra; Calendario da compra; Analise de requisitos; Proposta de solucao; Plano de pagamentos da compra;
- Corresponde ao documento base para a definicao do contracto de compra;
Minuta de
Contracto de Compra
- Documento a assinar pela organizacao e pelo parceiro no momento da formalizacao do contracto;
- Corresponde a aceitacao por parte de ambas as partes (organizacao e parceiro) dos termos da proposta elaborada pelo parceiro.
- Identifica direitos, deveres e obrigacoes de ambas as partes;
Nota de Encomenda - Formalizacao da proposta de compra apresentada pelo parceiro e adjudicada pela organizacao;
- Apresenta o conjunto de entregaveis a fornecer pelo parceiro detalhando-se o prazo de entrega e o plano de pagamentos para cada um deles;
Plano de Gestao
de Custos
- Define o plano de gestao de custos do projecto, identificando: Metodologia de gestao e controlo de orcamento; Informacao a disponibilizar
(conteudo e frequencia); Thresholds de controlo de custos; Descricao dos processos e intervenientes da gestao de custos;
Plano de Gestao
de Calendario
- Define o plano de gestao de calendario do projecto, identificando: Metodos e ferramentas de calendarizacao e controlo do projecto;
Informacao a disponibilizar (conteudo e frequencia); Thresholds de controlo de calendario; Intervenientes da gestao de calendario;
Tabela A.2: Documentos de suporte ao processo relativos a fase de Planeamento.
79
A.3 Documentos de Suporte da Fase de Implementacao e Con-
trolo
Documento de Suporte Descricao
Relatorio de
Progresso Semanal
- Reune um conjunto de informacao do progresso do projecto durante a semana, nomeadamente: Trabalho realizado na semana anterior;
Identificacao e atribuicao de actividades a realizar na semana seguinte; Revisao de orcamento e calendario; Revisao de riscos; Identificacao de
alteracoes; Controlo de alteracoes; Revisao do plano de comunicacoes; Revisao de actividades de gestao de stakeholders; Revisao de issues;
Relatorio de
Progresso Mensal
- Reune um conjunto de informacao do progresso do projecto durante o mes, nomeadamente: Trabalho realizado durante o mes; Planeamento
de calendario do projecto; Forecast de orcamento de projecto; Revisao e analise de riscos prioritarios; Revisao e analise de alteracoes;
Revisao e analise de issues; Revisao do plano de gestao de stakeholders; Analise de eficacia do plano de comunicacoes;
Forecast de Orcamento
- Resulta do progresso do orcamento do projecto do projecto face a baseline de orcamento;
- Apresenta a estimativa de orcamento ate ao fim do projecto com base em previsoes mensais do orcamento;
- Utilizado para controlo de orcamento por parte das areas de projectos, planeamento e controlo e director DSI.
- Permite avaliar discrepancia relativa a baseline de orcamento e cumprimento de tresholds de controlo de orcamento.
Log de Alteracoes - Identifica o conjunto de pedidos de alteracoes, em termos de: Responsaveis; Ambito; Abordagem a solucao tecnica; Orcamento; Calendario;
Recursos; Prioridade;
Log de Issues - Identifica o conjunto de issues do projecto, em termos de: Responsaveis; Causas; Impacto; Prioridade; Medidas de resolucao; Recursos;
Tabela A.3: Descricao dos documentos de suporte ao processo relativos a fase de implementacao econtrolo.
80
A.4 Documentos de Suporte da Fase de Handover
Documentos
de SuporteDescricao
Auto
de Aceitacao
- Reune toda a informacao necessaria para a aceitacao do projecto pela area de projectos,
O&M e negocio, nomeadamente: Entregaveis aceites; Lista de requisitos do projecto; Logs de Alteracoes,
Riscos e Issues; Testes de sistema/aceitacao/outros testes realizados;
Documento
de Handover
- Reune conjunto de documentacao necessaria para o handover da area de projectos a area
de O&M, nomeadamente: Responsaveis pelo Handover ; Log de riscos; Log de issues; Log de alteracoes;
Relatorio de
Fecho de Projecto
- Documento formal que indica o fecho do projecto;
- Reune o fecho de contractos com parceiros;
- Apresenta conjunto de entregaveis aceites do projecto;
- Reune documento de handover e auto de aceitacao do projecto;
- Apresenta o conjunto de logs de risco, issues e alteracoes do projecto;
Licoes Aprendidas
- Resulta do feedback fornecido pela area de negocio, parceiro e todas as areas da direccao de sistemas
de informacao que participaram no projecto, complementado pela experiencia adquirida pelo gestor de projecto.
- Apresenta feedback em aspectos tecnicos do projecto;
- Apresenta feedback em aspectos de gestao do projecto;
- Apresenta feedback em aspectos de qualidade do processo de gestao do projecto;
- Podera ser utilizado pela organizacao para aspectos de melhoria contınua de processos de gestao de projecto;
Tabela A.4: Descricao dos documentos de suporte ao processo relativos a fase de handover.
81
A.5 PMBOK - Processos de Gestao de Projecto
O PMBOK identifica um conjunto de processos para a gestao de projecto, divididos por fases de projecto
e a areas de conhecimento. A divisao dos processos e apresentada na figura A.1, extraıda do PMBOK.
Figura A.1: Processos definidos pelo PMBOK. Extraıdo de [2].
82