Embed Size (px)
Citation preview
FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Recolha, integração e apresentação de
informação de projectos
PTSIPortfolio
Hugo César Maciel Martins
VERSÃO DEFINITIVA
Relatório de Projecto
Mestrado Integrado em Engenharia Informática e Computação
Orientador: Eng. Gil Manuel Magalhães de Andrade Gonçalves
Junho de 2009
PTSIPortfolio
Hugo César Maciel Martins
Relatório de Projecto
Mestrado Integrado em Engenharia Informática e Computação
Aprovado em provas públicas pelo Júri:
Presidente: Eng. João Francisco de Sousa Cardoso
____________________________________________________
Arguente: Eng. Luís Manuel Borges Gouveia
Vogal: Eng. Gil Manuel Magalhães de Andrade Gonçalves
29 de Junho de 2009
i
Resumo
O presente documento pretende servir como prelúdio ao desenvolvimento do
projecto “Recolha, Integração e Apresentação de Informação de Projectos”. Deste
modo, ao longo deste documento serão apresentados os principais detalhes da
elaboração deste projecto e fundamentada toda e qualquer especificação inerente ao
processo de implementação do sistema.
Este trabalho enquadra-se numa perspectiva de contribuição para o melhoramento
da gestão de projectos, enquanto prática decisiva e imprescindível para o sucesso de
qualquer projecto. Com efeito, ao longo do ciclo de vida de um projecto sucedem-se
situações de incertezas e ambiguidades que podem, desde logo, comprometer todo o seu
desenvolvimento ao mesmo tempo que podem deitar por terra todas as aspirações de
dezenas de recursos envolvidos. Assim, este projecto, denominado PTSIPortfolio, visa
intervir nesta área de uma forma benéfica e significativa, ao servir o interesse dos
gestores do projecto com o provimento de informações relevantes e oportunas sobre os
seus projectos em curso, sob a forma de um relatório integrado de projectos. Este
relatório integrado conjuga ainda a utilização de métricas de software, que fornecem
medidas bem definidas e fiáveis para a gestão e avaliação quer do produto em si, quer
dos próprios processos de concepção e desenvolvimento. A melhoria da actividade de
gestão nesta área passa pela capacidade de identificar, medir e controlar os principais
parâmetros que afectam o processo de desenvolvimento de software, numa óptica de
prevenção e de sinalização atempada das áreas mais problemáticas de cada projecto.
Apesar de actualmente existirem várias soluções de software muito conceituadas e
utilizadas para a gestão de projectos no mundo empresarial, o PTSIPortfolio prima por
uma perspectiva inovadora de consolidação de informações de todas essas ferramentas,
devendo ser utilizado em conjunto com estas e não como alternativa. A sua mais-valia
assenta precisamente na consulta rápida, simples e intuitiva de informação dos projectos
a vários níveis, privilegiando a apresentação de informação gráfica e a sinalização clara
de tendências e das áreas que requerem maior atenção.
O trabalho aqui exposto enquadra-se então na descrição da evolução contínua de
um projecto de desenvolvimento tecnológico, aplicável num ambiente profissional
conjunto entre o aluno e a empresa. Aproveitando os conhecimentos do aluno, inclusive
os adquiridos no seio da empresa, e tendo em consideração a possibilidade de
exploração da área de concepção do projecto e a criação de soluções inovadoras com
valor acrescentado para a empresa, apresenta-se seguidamente o resultado final do
cumprimento progressivo das várias fases do projecto.
ii
iii
Abstract
This document is intended to serve as a prelude to the development of the project
“Recolha, Integração e Apresentação de Informação de Projectos” (Collection,
Integration and Presentation of Project‟s Information"). Therefore, throughout this
document it will be presented the main details of this project‟s development and will be
justified any specification inherent to the system‟s implementation process.
This work falls within a sight of contributing to the improvement of project
management as a crucial and essential practice for the success of any project. As a fact,
throughout a project‟s life cycle there are situations of uncertainty and ambiguity, which
may commit all of its development while vanishing all the efforts of dozens of resources
involved. Thus, this project, entitled PTSIPortfolio, seeks to intercede in this area in a
meaningful and beneficial way, serving the interest of the project managers by
providing relevant and suitable information about their ongoing projects, in the outline
of a projects‟ integrated report. This integrated report also combines the use of software
metrics, providing clear and reliable measures for the management and evaluation of
both the product itself and its design and development processes. Improving business
management in this area involves the ability to identify, measure and control the main
parameters that affect the software development process, in terms of prevention and
early awareness of the most problematic spots of each project.
Although there are currently many software solutions, awfully distinguished and
used for project management in enterprise business, the PTSIPortfolio arises in an
innovative sight by consolidating information from all of these tools, settling on that it
should be used in conjunction with these and not as an alternative. Its added value is
precisely based on a quick, simple and intuitive consultation of the project‟s data at
several levels, focusing the presentation of graphical information and of trends and
areas needing further attention.
The work outlined here is then based on the description of a technologic project
continuous progress, which is applicable in a professional environment set between the
student and the corporation. Using the student‟s knowledge, including those acquired
within the company, and taking into account the possibility of exploiting the project‟s
area and the development of innovative value-added solutions to the company, the rest
of this document shows the final result of the project‟s several progressive phases.
iv
v
“Deus quer, o homem sonha, a obra nasce” in „Mensagem‟ de Fernando Pessoa, 1934.
vi
vii
Agradecimentos
Pela sua natureza académica, na realização de um projecto como este, existem
contributos de natureza diversa que não podem nem devem deixar de ser realçados.
Por essa mesma razão demonstro primeiramente um especial agradecimento ao
Eng. Anselmo Silva (PT-SI) e ao Eng. Gil Gonçalves (FEUP), pela orientação prestada
a todos os níveis, que foi decisiva para o sucesso deste projecto, e ainda pela
disponibilidade e amizade que sempre me demonstraram.
Aproveito para agradecer aos restantes elementos da PT-SI envolvidos neste
projecto, em especial ao Eng. Ruben Marinho e à Eng.ª Rita Rodrigues, de quem obtive
sempre um total apoio e auxilio, fundamentais para a elaboração deste projecto.
Por fim, mas não menos importante, não poderia deixar de agradecer à minha
família e ao meu grupo de amigos, em especial a Soraia Pereira, José Vale, André
Meneses, Carlos Fernandes, Ricardo Vieira, João Marques, António Alves e Marc
Gonçalves, por toda a compreensão, amizade e suporte moral ao longo da realização do
projecto, que permitiram ultrapassar as maiores adversidades e atingir sempre os
objectivos propostos.
A todos, e por todos, os meus mais profundos e sinceros agradecimentos.
Hugo César Maciel Martins
viii
ix
Conteúdo
1 Introdução............................................................................................................. 1
1.1 Enquadramento ................................................................................................ 1
1.2 A Instituição .................................................................................................... 1
1.3 Projecto ........................................................................................................... 3
1.4 Motivação ........................................................................................................ 4
1.5 Estrutura do Relatório ...................................................................................... 5
2 Análise do Problema ............................................................................................. 7
2.1 O Problema ...................................................................................................... 7
2.1.1 Métricas .................................................................................................. 8
2.1.2 Sistemas ............................................................................................... 10
2.1.3 Integração ............................................................................................. 11
2.2 Objectivos ..................................................................................................... 13
2.3 Metodologias ................................................................................................. 14
2.4 Planeamento .................................................................................................. 14
2.5 Resumo e Conclusões .................................................................................... 18
3 Estudo do Estado da Arte ................................................................................... 19
3.1 Sistemas Relacionados ................................................................................... 19
3.2 Oportunidade de Desenvolvimento ................................................................ 20
3.3 Revisão Tecnológica ...................................................................................... 20
3.3.1 Identificação das Tecnologias ............................................................... 21
3.3.2 Decisões Tecnológicas .......................................................................... 21
3.3.3 Web Services ........................................................................................ 23
3.3.4 Windows Services ................................................................................. 23
3.4 Resumos e Conclusões ................................................................................... 24
x
4 Especificação da Solução .................................................................................... 25
4.1 Contexto do Produto ...................................................................................... 25
4.2 Funções do Produto ....................................................................................... 26
4.2.1 Funções do Serviço de Actualização ..................................................... 26
4.2.2 Funções do Serviço de Apresentação .................................................... 26
4.3 Características dos Utilizadores ..................................................................... 26
4.4 Restrições ...................................................................................................... 27
4.5 Pressupostos e Dependências ......................................................................... 27
4.6 Requisitos Funcionais .................................................................................... 27
4.6.1 Visão Geral do Sistema ......................................................................... 28
4.6.2 Pacote Serviço de Actualização ............................................................ 28
4.6.3 Pacote Serviço de Apresentação ............................................................ 29
4.6.3.1 Visão Geral ................................................................................ 29
4.6.3.2 Actores ....................................................................................... 30
4.6.3.3 Módulo Project MasterList ......................................................... 31
4.6.3.4 Módulo Perspectivas .................................................................. 32
4.6.3.5 Módulo Administração ............................................................... 33
4.7 Requisitos Não Funcionais ............................................................................. 34
4.7.1 Requisitos do Produto ........................................................................... 34
4.7.2 Requisitos Externos .............................................................................. 36
4.7.2.1 Interfaces com o Utilizador ......................................................... 36
4.7.2.2 Interfaces de Hardware ............................................................... 36
4.7.2.3 Interfaces de Software ................................................................ 36
4.7.2.4 Interfaces de Comunicação ......................................................... 36
4.8 Resumo e Conclusões .................................................................................... 36
5 Implementação.................................................................................................... 38
5.1 Arquitectura do Sistema ................................................................................. 38
5.1.1 Visão Geral ........................................................................................... 39
5.1.2 Visão Conceptual .................................................................................. 40
5.1.3 Visão Estática ....................................................................................... 41
5.1.3.1 Serviço de Actualização ............................................................. 42
5.1.3.2 Serviço de Apresentação ............................................................. 43
5.1.4 Visão Dinâmica .................................................................................... 45
5.1.4.1 Serviço de Actualização ............................................................. 45
5.1.4.2 Serviço de Apresentação ............................................................. 46
5.2 Arquitectura dos Dados .................................................................................. 48
5.2.1 Especificação da Informação ................................................................ 48
5.2.1.1 Modelo Conceptual de Dados ..................................................... 48
5.2.1.2 Descrição das Classes ................................................................. 50
xi
5.2.2 Especificação da Base de Dados ........................................................... 52
5.2.2.1 Esquema Relacional de Dados .................................................... 52
5.3 Serviço de Actualização ................................................................................. 53
5.3.1 Camada de Dados ................................................................................. 54
5.3.2 Camada de Lógica de Negócio .............................................................. 55
5.4 Serviço de Apresentação ................................................................................ 57
5.4.1 Camada de Dados ................................................................................. 58
5.4.2 Camada de Lógica de Negócio .............................................................. 59
5.4.3 Camada de Apresentação ...................................................................... 60
5.5 Resumos e Conclusões ................................................................................... 71
6 Testes ................................................................................................................... 73
6.1 Âmbito dos Testes ......................................................................................... 73
6.2 Estratégia de Testes ....................................................................................... 74
6.2.1 Teste Unitário ....................................................................................... 74
6.2.2 Teste Integração.................................................................................... 74
6.2.3 Teste de Sistema ................................................................................... 74
6.2.4 Teste de Aceitação ................................................................................ 74
6.3 Abordagem .................................................................................................... 74
6.4 Cobertura dos Testes ...................................................................................... 76
6.5 Realização dos Testes e Resultados Obtidos................................................... 78
6.6 Resumos e Conclusões ................................................................................... 78
7 Avaliação dos Resultados e Melhoramentos ...................................................... 79
7.1 Optimização da Velocidade do Serviço de Actualização ................................ 79
7.2 Inclusão de logfile no Serviço de Actualização ............................................... 80
7.3 Optimização da Velocidade do Serviço de Apresentação ............................... 81
7.4 Melhoramento do Módulo de Visualização .................................................... 81
7.5 Optimização da Interacção com o Utilizador .................................................. 81
8 Conclusões........................................................................................................... 82
Referências................................................................................................................. 83
A. Planeamento........................................................................................................ 85
A.1 Fases 1, 2 e 3 do Projecto ............................................................................... 85
A.2 Fases 4, 5 e 6 do Projecto ............................................................................... 86
B. Casos de Uso ....................................................................................................... 87
B.1 Módulo Serviço de Actualização (act) ........................................................... 87
xii
B.2 Módulo Project Master List (pml) .................................................................. 88
B.3 Módulo Perspectivas (per) ............................................................................. 91
B.4 Módulo Administração (adm) ........................................................................ 93
C. Protótipos gráficos .............................................................................................. 96
C.1 Perspectiva Geral ........................................................................................... 96
C.2 Perspectiva Financeira ................................................................................... 97
C.3 Perspectiva Plano ........................................................................................... 97
C.4 Perspectiva Problemas ................................................................................... 98
C.5 Perspectiva Defeitos ...................................................................................... 98
C.6 Perspectiva Stakeholders ................................................................................ 99
C.7 Perspectiva Recursos ..................................................................................... 99
C.8 Perspectiva Riscos ....................................................................................... 100
D. Especificação dos Web Services .......................................................................... 101
D.1 Sistema Externo EPM .................................................................................. 101
D.2 Sistema Externo Sharepoint ......................................................................... 103
E. Prova de Conceito ............................................................................................... 105
F. Especificação de Desenhos de Teste .................................................................... 106
F.1 Acesso e utilização da Base de Dados .......................................................... 106
F.2 Funções do Serviço de Actualização ............................................................ 107
F.3 Funções do Serviço de Apresentação ........................................................... 107
xiii
Lista de Figuras
Figura 1.1: Vantagens competitivas e valores corporativos da PT-SI....................... 2
Figura 1.2: Principais áreas de actuação da PT-SI ................................................... 3
Figura 1.3: Caracterização do sucesso dos projectos [PTS091] ............................... 4
Figura 2.1: Dimensões envolvidas na gestão de projectos ....................................... 8
Figura 2.2: Métricas para controlo de cumprimento de prazos e
orçamentos ............................................................................................................. 9
Figura 2.3: Métricas para o controlo do progresso a nível do âmbito,
prazo e custo ........................................................................................................... 9
Figura 2.4: Métricas para a classificação das tarefas ao longo do
tempo ................................................................................................................... 10
Figura 2.5: Métricas para a avaliação dos recursos consumidos ao
longo do tempo ..................................................................................................... 10
Figura 2.6: Ferramentas empresariais de gestão de projectos da
Microsoft .............................................................................................................. 11
Figura 2.7: Ferramentas de bug tracking ............................................................... 11
Figura 2.8: Principais áreas dos projectos ............................................................. 12
Figura 2.9: Funcionamento de um Relatório Integrado de Projectos ...................... 12
Figura 2.10: Principais módulos do projecto ......................................................... 13
Figura 2.11: Planificação geral do projecto ........................................................... 15
Figura 2.12: Planificação das Milestones do projecto ............................................ 15
Figura 2.13: Planificação das Actividades do projecto .......................................... 16
Figura 2.14: Fases de desenvolvimento do projecto .............................................. 17
Figura 3.1: Ferramentas OpenSource para gestão de projectos .............................. 20
Figura 3.2: Modelo de funcionamento dos Web Services ....................................... 23
Figura 4.1: Visão geral do Sistema........................................................................ 28
Figura 4.2: Casos de utilização do Serviço de Actualização .................................. 29
Figura 4.3: Visão geral do pacote Serviço de Apresentação .................................. 30
xiv
Figura 4.4: Actores do sistema .............................................................................. 31
Figura 4.5: Casos de uso para Project Master List (pml) ....................................... 32
Figura 4.6: Casos de uso para Perspectivas (per) ................................................... 33
Figura 4.7: Casos de uso para Administração (adm) .............................................. 34
Figura 5.1: Arquitectura física do sistema ............................................................. 39
Figura 5.2: Arquitectura de componentes do sistema............................................. 40
Figura 5.3: Arquitectura conceptual em camadas .................................................. 41
Figura 5.4: Visão geral das classes do Serviço de Actualização ............................. 42
Figura 5.5: Classes que implementam a Interface IExternalSystems ...................... 43
Figura 5.6: Visão geral das classes do Serviço de Apresentação ............................ 44
Figura 5.7: Classes que implementam a Interface IShowPageData ....................... 44
Figura 5.8: Diagrama de funcionamento do Serviço de Actualização .................... 46
Figura 5.9: Diagrama de funcionamento do Serviço de Apresentação
(apresentação de página) ....................................................................................... 47
Figura 5.10: Diagrama de funcionamento do Serviço de Apresentação
(gestão de comentários) ........................................................................................ 48
Figura 5.11: Modelo Conceptual de Dados ........................................................... 49
Figura 5.12: Esquema Relacional de Dados .......................................................... 53
Figura 5.13: DataSet para EPM, com as tabelas necessárias para
armazenamento ..................................................................................................... 55
Figura 5.14: Funcionamento geral do Serviço de Actualização ............................. 57
Figura 5.15: Logótipo do PMO - PTSIPortfolio .................................................... 60
Figura 5.16: Menus de navegação – a partir de uma perspectiva de
projecto (esquerda), a partir da PML (centro) e a partir da
Administração (direita) ......................................................................................... 61
Figura 5.17: Página inicial da aplicação Web (PML – Vista Agregada) ................. 62
Figura 5.18: PML – Vista Plano............................................................................ 63
Figura 5.19: PML – Vista Financeira .................................................................... 63
Figura 5.20: Ordenação da PML por atributos....................................................... 63
Figura 5.21: Selecção de um projecto a partir da PML .......................................... 64
Figura 5.22: Perspectiva Geral – Informação geral do projecto ............................. 64
Figura 5.23: Perspectiva Geral – Velocímetros das várias perspectivas ................. 65
Figura 5.24: Perspectiva Financeira ...................................................................... 65
Figura 5.25: Perspectiva Plano – Milestones do projecto ....................................... 66
Figura 5.26: Perspectiva Plano – Evolução da Data Fim e do
Progresso do projecto ........................................................................................... 66
Figura 5.27: Perspectiva Problemas – lista de problemas ...................................... 67
Figura 5.28: Perspectiva Problemas/ Defeitos – Distribuição de itens
por urgência .......................................................................................................... 67
Figura 5.29: Perspectiva Problemas/ Defeitos – Evolução de itens ao
longo do tempo ..................................................................................................... 67
Figura 5.30: Perspectiva Stakeholders – Action Items do projecto ......................... 68
xv
Figura 5.31: Perspectiva Stakeholders – Action Items por estado e
responsável ........................................................................................................... 68
Figura 5.32: Perspectiva Stakeholders – Change Requests do projecto .................. 68
Figura 5.33: Perspectiva Stakeholders – Evolução do estado dos
Change Requests ao longo do tempo ..................................................................... 69
Figura 5.34: Perspectiva Recursos – Staffing e avaliação do índice de
risco pela equipa ................................................................................................... 69
Figura 5.35: Perspectiva Riscos – Riscos do projecto ............................................ 70
Figura 5.36: Perspectiva Riscos – Distribuição de riscos na matriz PxI
e evolução destes ao longo do tempo .................................................................... 70
Figura 5.37: Perspectiva Administração – Listagem dos projectos ........................ 71
Figura 5.38: Perspectiva Administração – Edição da classe de um
projecto ................................................................................................................ 71
xvi
xvii
Lista de Tabelas
Tabela 4.1: Requisitos não funcionais (produto) ................................................... 35
Tabela 6.1: Especificação dos casos de teste ......................................................... 76
Tabela 6.2: Traceability Matrix ............................................................................ 78
xviii
xix
Abreviaturas e Símbolos
MIEIC
FEUP
PT
PT-SI
PMI
GP
SI
TI
SQL
BI
ERP
EPM
CRM
BPM
CPI
SPI
FDD
SGBD
BDC
IIS
WS
WSDL
UML
PML
Mestrado Integrado em Engenharia Informática e Computação
Faculdade de Engenharia da Universidade do Porto
Portugal Telecom
Portugal Telecom Sistemas de Informação
Project Management Institute
Gestor de Projectos
Sistemas de Informação
Tecnologias de Informação
Structured Query Language
Business Intelligence
Enterprise Resource Planning
Enterprise Project Management
Customer Relationship Management
Business Process Management
Cost Performance Index
Schedule Performance Index
Feature Driven Development
Sistema de Gestão de Base de Dados
Base de Dados Central
Internet Information Services
Web Services
Web Services Description Language
Unified Modeling Language
Project Master List
1
1 Introdução
Este capítulo visa servir de introdução a todo o contexto do projecto, focando
aspectos relacionados com o âmbito e enquadramento, o ambiente em foi desenvolvido,
a necessidade de desenvolvimento do mesmo, e as principais motivações para a sua
realização.
1.1 Enquadramento
O desenvolvimento deste projecto foi proposto para a realização do estágio final,
integrado no actual plano de estudos do Mestrado Integrado em Engenharia Informática
e Computação, leccionado na Faculdade de Engenharia da Universidade do Porto.
A sua realização decorreu maioritariamente em ambiente empresarial, ao longo do
ano lectivo de 2008/2009, com ponto de início a 25 de Fevereiro de 2009 e termo a 29
de Junho de 2009.
Este projecto conta com a Portugal Telecom Sistemas de Informação (PT-SI) como
proponente do projecto, enquanto empresa do Grupo Portugal Telecom responsável pelo
fornecimento de Soluções de Tecnologias e Sistemas de Informação ao mercado
empresarial [PTS09]. Conta ainda com a orientação e supervisionamento do Eng. Gil
Gonçalves (da parte da FEUP) e do Eng. Anselmo Silva (da parte da PT-SI).
1.2 A Instituição
Este projecto foi proposto por uma empresa do Grupo PT, mais especificamente a
PT-SI, tendo sido nas suas instalações no Porto que decorreu a maior parte da sua
implementação.
A principal missão da PT-SI é fornecer ao Grupo PT soluções de Sistemas de
Informação (SI)/ Tecnologias de Informação (TI) de excelência e, aproveitando a
experiência adquirida abordar o restante mercado, procurando continuamente a
eficiência de sistemas, processos e recursos na promoção, desenvolvimento e
implementação de Soluções integradas com Telecomunicações [PTS09].
2
Figura 1.1: Vantagens competitivas e valores corporativos da PT-SI
Beneficiando da vasta experiência e know-how do Grupo PT, a PT-SI procura
contribuir para a competitividade dos seus Clientes, criando valor através da integração
de Tecnologias e Sistemas de Informação com Telecomunicações, tendo sempre em
conta as melhores práticas existentes no mercado, a inovação e assegurando sempre a
melhoria contínua e a natural evolução tecnológica [PTS09]. Por estas razões, a PT-SI
aspira a ser a empresa portuguesa líder na oferta de soluções de SI/TI e sua integração
com Telecomunicações, sendo esta a sua visão [PTS09]. A PT-SI aposta igualmente em
valores como a relação preço/qualidade e a flexibilidade de resposta como as suas
principais vantagens competitivas, direccionando o seu esforço principalmente para o
mercado empresarial.
As principais áreas de actuação da PT-SI passam então apenas pela integração
SI/TI, estendendo-se a domínios como Business Intelligence (BI), Enterprise Resource
Planning (ERP), Enterprise Project Management (EPM), Costumer Relationship
Management (CRM), Business Process Management (BPM) ou mesmo a Gestão de
Conhecimentos e o desenvolvimento de Portais [PTS09].
A PT-SI conta ainda com importantes clientes, tanto pertencentes ao Grupo PT,
como a PT Comunicações, PT PRO ou TMN, ou clientes externos bastante prestigiados
como é o caso de FC Porto, Ikea, MCDonald‟s, Moviflor, Staples Office Center, AIP,
ADSE, Galp Energia, Medicamentos Genéricos, Ok! Teleseguro, Museu Serralves,
RTP, Renault, entre muitos outros, repartindo as suas áreas de actuação um pouco por
todos [PTS09].
3
Figura 1.2: Principais áreas de actuação da PT-SI
1.3 Projecto
A PT-SI é uma empresa com uma gestão comprometida com a excelência,
reconhecida por desenvolver soluções inovadoras utilizando as melhores práticas na
área de Engenharia de Software [PTS09]. Apresentando como missão o melhoramento
contínuo dos seus processos e a aplicação de técnicas e metodologias que permitam
entregar produtos nos prazos e orçamentos estipulados [PTS09], este projecto enquadra-
se numa perspectiva de desenvolvimento de ferramentas que auxiliem os gestores de
projecto (GP) a tomarem as melhores decisões.
A gestão de projectos é há muito considerada indiscutivelmente como uma matéria
essencial para o sucesso dos projectos. No entanto, mesmo com uma significativa
evolução nesta área nos últimos anos, a taxa de sucesso da realização dos projectos
continua a ser bastante reduzida (como demonstrado na Figura 1.3), e mesmo
considerando que a tendência seja para um melhoramento contínuo e progressivo, o
certo é que esta taxa ainda se encontra longe do que seria desejável. E isto acontece
porque ao longo do ciclo de vida do projecto sucedem-se situações de incertezas, que
podem desde logo comprometer todo o desenvolvimento deste, como é o caso da
especificação ambígua ou incompleta dos requisitos, o planeamento insuficiente, a
monitorização insuficiente, baixo envolvimento dos utilizadores finais ou mesmo com a
criação de expectativas irrealistas.
4
Figura 1.3: Caracterização do sucesso dos projectos [PTS091]
Como é do domínio público, o Grupo PT alberga projectos de enorme envergadura,
não só em Portugal como no estrangeiro, e a PT-SI enquadra uma participação activa e
preponderante em muitos desses projectos actualmente.
Por estes motivos, é essencial a detenção de uma boa prática de gestão de
projectos, no sentido de credibilizar o seu trabalho e de contribuir para uma maior
afirmação da sua «brand» no mercado.
Nesse sentido, este projecto visa contribuir precisamente para esse fim, através da
implementação de uma aplicação que apresente informação relativa aos projectos que se
encontram em curso e que estão afectados a cada GP, numa óptica simplista e intuitiva,
mas ao mesmo tempo eficiente e segura. Com esta aplicação os GP podem adquirir uma
maior omnisciência do estado corrente de cada projecto ao mesmo tempo que podem
perspectivar o estado geral do conjunto dos projectos, adquirindo maior propensão para
atentar aos projectos/áreas mais problemáticas.
1.4 Motivação
As aplicações empresariais, nomeadamente os Sistemas de Informação,
representam hoje em dia uma das principais ferramentas de suporte aos processos de
negócio das empresas. Com uma tendência natural e constante para a automatização e
informatização dos processos de negócio, as empresas procuram cada vez assegurar um
conjunto de requisitos que permitam melhorar a sua eficiência e eficácia, recorrendo
para isso às mais recentes tecnologias e serviços.
É com base nestes conceitos que as empresas procuram soluções inovadoras, que
permitam a criação de novas aplicações, mais adaptadas às suas necessidades
específicas.
A motivação central para a realização deste projecto resulta precisamente desta
importância que o mundo empresarial atribui à inovação e ao empreendedorismo. A
concepção deste trabalho despertou interesse ao viabilizar a concretização de uma ideia
potencialmente nova e com capacidade para ajudar as empresas num dos pontos mais
5
críticos do sector empresarial: a gestão de projectos. Nesse sentido, as potencialidades
de um projecto desta índole podem aliar a elaboração de uma ferramenta prática,
simples e intuitiva a um melhoramento significativo na organização e processamento
das operações de negócio, oferecendo serviços que levem os GP a acreditar no produto
e assim desenvolver uma base sólida assente na qualidade.
1.5 Estrutura do Relatório
Este documento pretende dar a conhecer, de uma forma estruturada, todas as etapas
da realização deste projecto pelo que foi seguida uma estruturação adequada a essa
finalidade.
Assim, o presente capítulo – a Introdução – pretende servir como prelúdio ao
projecto, demonstrando de uma forma geral a sua essência a nível da instituição onde
foi desenvolvido, do seu âmbito e dos seus objectivos
No segundo capítulo será explicado com mais detalhe o projecto, através de uma
abordagem ao problema a resolver. Serão igualmente explicitados os principais
objectivos do produto a desenvolver e as metodologias e planificações seguidas para o
seu desenvolvimento.
Seguidamente será apresentada toda a investigação que foi efectuada em torno
deste projecto, quer a nível teórico, quer a nível tecnológico, de forma a fundamentar as
decisões de implementação seguidas. Será portanto demonstrado um estudo do estado
da arte, a nível de soluções idênticas já existentes, assim como será efectuada a
introdução deste projecto como oportunidade de desenvolvimento, enquanto possível
projecto de inovação. A nível tecnológico serão apresentadas as ferramentas e
tecnologias de desenvolvimento que melhor se adequariam a este projecto, com especial
destaque para o estudo de soluções a nível da Web de Sistemas de Gestão de Base de
Dados.
No quarto capítulo será efectuada uma especificação inicial da solução, incluindo
uma descrição geral das funcionalidades do produto e dos seus requisitos específicos, a
nível de requisitos funcionais e não funcionais.
A implementação propriamente dita da aplicação será exposta no quinto capítulo.
Neste capítulo efectua-se uma abordagem segmentada pelos módulos do projecto e,
dentro de cada um, pelas várias camadas que os constituem. Será igualmente abordada a
questão da arquitectura, com destaque para as várias visões do produto, tendo em conta
os seus módulos constituintes.
No sexto capítulo o assunto principal será a especificação dos testes, sendo
definidos o seu âmbito, as principais estratégias para a sua realização, o modo de
abordagem e a cobertura dos testes a nível do projecto. Serão igualmente apresentados
os testes já realizados e os principais resultados obtidos.
O sétimo capítulo tem como finalidade uma análise deste projecto a nível dos
resultados obtidos e do cumprimento dos objectivos propostos no início do projecto.
Serão igualmente apresentadas algumas considerações tendo em conta o trabalho que
poderá ainda ser desenvolvido na sequência deste projecto, no sentido de melhorar em
todas as suas vertentes.
No oitavo e último capítulo serão apresentadas algumas ilações que se podem
retirar do desenvolvimento deste projecto, destacando os seus aspectos mais positivos e
6
os mais negativos, as principais dificuldades encontradas. Por fim será analisado o
impacto que um projecto desta índole pode provocar num estudante ao longo do seu
desenvolvimento.
De realçar que em cada um dos capítulos deste relatório existe uma pequena
secção, localizada sempre no final de cada um, onde se apresentam pequenas
considerações sobre o que foi tratado nesse mesmo capítulo.
7
2 Análise do Problema
A metodologia seguida para a abordagem a este problema envolve numa primeira
fase a análise do problema, de forma a identificar os principais grupos de informação a
ser considerados.
No estabelecimento de um planeamento de projectos orientado aos objectivos, a
sua apropriada análise deve preceder a definição desses objectivos. Assim, antes da
realização de qualquer acção centrada no desenvolvimento deste projecto, é crucial
estudar a situação actual da sua área de aplicação e identificar em que circunstâncias os
problemas a resolver podem ocorrer. Uma adequada análise do problema pode ajudar
igualmente a estabelecer limites para o projecto, permitindo estabelecer que problemas
poderão e deverão ser considerados e que problemas deverão ser remetidos para outras
áreas. Deste modo a limitação dos termos do projecto limita também o problema,
permitindo encontrar uma solução mais específica, e consequente mais adaptada ao
projecto.
Também a definição dos objectivos é importante para o desenvolvimento de um
projecto desta índole, já que apenas estes poderão ditar o sucesso ou insucesso do
mesmo.
2.1 O Problema
A gestão de projectos pode ser entendida como a aplicação de conhecimentos,
habilidades, ferramentas e técnicas às actividades de um projecto, a fim de alcançar os
seus objectivos [PMI04]. Neste caso concreto, a gestão de projectos assume um tom
mais conotativo ao envolver todo o processo de planeamento, execução e controlo dos
projectos, desde o seu início até à sua conclusão, com vista à consecução de um
objectivo final num certo prazo, com um certo custo e qualidade, através da mobilização
recursos técnicos, financeiros e humanos [Nun07]. Em termos sucintos, a gestão de
projectos integra áreas tão diversas como a gestão da integração do projecto, a gestão
dos custos, a gestão da qualidade, a gestão do tempo, a gestão dos recursos humanos ou
a gestão das comunicações (entre os membros e com o exterior) [Nun07].
É por tudo isto que na PT-SI a gestão de projectos representa um dos principais
aspectos a considerar no seu ambiente corporativo, já que actua no sentido de optimizar
8
os seus recursos ao mesmo tempo que diminui as incertezas e os riscos e aumenta as
possibilidades de sucesso dos seus projectos. Mas o assunto assume um contorno mais
preocupante quando se entra com dados estatísticos dos últimos anos e se percebe que a
PT-SI conta com cerca de 150 GP, enquanto por ano desenvolve cerca de 2500
projectos [INT09]. Em média cada projecto envolve entre 15 e 20 recursos,
apresentando uma duração de 4/ 5 meses, podendo haver extremos de pequenas
encomendas que apenas envolvem 2/ 3 recursos e duram 1/ 2 semanas, ou de grandes
projectos que duram mais do que um ano e envolvem mais de duas dezenas de recursos
[INT09]. Percebe-se pois, através da interpretação destes números, que em média cada
GP lida com 16 projectos por ano, sendo que muitos devem estar sobrepostos entre si, o
que dificulta ainda mais todo o processo de gestão e de controlo das áreas mais
problemáticas.
Portanto, dada a importância desta matéria para a PT-SI e tendo em conta o que foi
referido na secção 1.3, torna-se compreensível que é imperativo o alcance de uma boa
prática de gestão de projectos, adequada aos projectos em causa e que aumente as suas
probabilidades de sucesso. Com efeito, a PT-SI segue linhas de actuação específicas,
que envolvem quatro dimensões principais:
Metodologias – aplicação de uma metodologia integrada de gestão de
projectos, adoptando as melhores práticas do Project Management Institute
(PMI);
Pessoas – aposta contínua na formação de GP, com capacidades
comprovadas de gestão e liderança;
Métricas – utilização de métricas objectivas e consistentes para medir e
monitorizar a performance dos projectos;
Sistemas – utilização de sistemas informáticos de suporte à decisão e
partilha de informação entre os colaboradores do projecto. [PTSI091]
Figura 2.1: Dimensões envolvidas na gestão de projectos
O âmbito deste projecto enquadra-se fundamentalmente nas últimas duas
dimensões, numa perspectiva de aliar e estandardizar o uso de métricas nos projectos ao
uso de soluções informáticas de suporte à gestão.
2.1.1 Métricas
O uso de métricas objectivas e sistemáticas permite o acompanhamento da
execução dos projectos em tempo real, através da aplicação de templates e indicadores e
da utilização de metodologias de controlo dos projectos.
Estas métricas podem ser aplicadas nas mais diversas áreas afectas a um projecto,
como por exemplo na análise dos índices de prazos Schedule Performance Index (SPI) e
9
dos índices de custo Cost Performance Index (CPI), que permitem avaliar ao longo do
tempo as suas tendências, facilitando a detecção atempada de desvios e aumentando a
capacidade de reacção (Figura 2.2). Outro exemplo é a sua aplicação no controlo do
progresso do projecto a vários níveis, dando uma perspectiva geral do seu estado em
termos de limites e aproximação da conclusão (Figura 2.3).
Figura 2.2: Métricas para controlo de cumprimento de prazos e orçamentos
Figura 2.3: Métricas para o controlo do progresso a nível do âmbito, prazo e custo
Similarmente, a nível das tarefas do projecto é possível e primária a aplicação de
métricas, não só para a sua caracterização e consequente avaliação de necessidade de
atenção, mas também para a sua organização, permitindo um direccionamento da
concentração de gestão para as tarefas mais problemáticas. Com estas métricas seria
possível, a título de exemplo, obter num determinado momento, e de forma gráfica, o
top ten das tarefas mais atrasadas (Figura 2.4). O mesmo se aplica na área dos recursos,
em que seria possível visualizar os recursos que foram consumidos ao longo do tempo,
até à data actual. Seria igualmente possível obter, com base em dados históricos, uma
previsão do consumo futuro dos mesmos (Figura 2.5), oferecendo desde logo um
mecanismo útil no suporte à decisão.
10
Figura 2.4: Métricas para a classificação das tarefas ao longo do tempo
Figura 2.5: Métricas para a avaliação dos recursos consumidos ao longo do tempo
2.1.2 Sistemas
A nível de sistemas informáticos, são utilizadas ferramentas empresariais de gestão
de projectos como o Office Project ou o Sharepoint da Microsoft (Figura 2.6), que
auxiliam no planeamento, gestão e controlo dos projectos, proporcionando consistência
e capacidade de resposta a níveis elevados de serviço. São ferramentas que garantem
vantagens a diversos níveis, como na disponibilidade, capacidade, segurança,
operacionalidade, recuperabilidade e suporte dos processos de negócio.
Para além destas ferramentas, são ainda utilizadas ferramentas de bug tracking
(Figura 2.7), que auxiliam na detecção de erros dos projectos. Estes sistemas registam
todos os bugs, evoluções e correcções dos projectos, permitindo saber, entre outras
coisas, quais os problemas que aconteceram, porque aconteceram, como foram
resolvidos, os actualmente existentes e os que se encontram em correcção.
Estas também apresentam diversas vantagens, fundamentalmente a nível da
facilidade de detecção automática de erros de código e na superação face a erros
humanos recursivos.
11
Figura 2.6: Ferramentas empresariais de gestão de projectos da Microsoft
Figura 2.7: Ferramentas de bug tracking
2.1.3 Integração
Tendo em conta todas os tipos de métricas e todos os tipos de sistemas que poderão
ser utilizados, a gestão de projectos pode começar a pecar por uma descentralização do
processo de análise e controlo dos projectos. É neste sentido que se torna necessária e
indispensável a existência de um relatório integrado com todos os projectos, que
permita saber quais os projectos que estão ou poderão eventualmente estar em
dificuldades e compreender a causa dessas dificuldades, numa tentativa de prevenir
situações futuras da mesma natureza. Este relatório integrado poderia igualmente servir
aos GP ao fornecer um método rápido e eficaz de “fazer um raio X” aos projectos,
permitindo a sua introspecção segundo diferentes perspectivas, privilegiando áreas
como as finanças ou o planeamento do projecto e a própria gestão de problemas e
defeitos, dos stakeholders, dos recursos e dos riscos associados.
Porém, a existência de um relatório desta índole pressupõe uma recolha periódica
de informação a partir dos mecanismos de reporting já existentes (como o Project e o
Sharepoint), conjecturando uma necessidade de integração entre todos esses sistemas.
Existe ainda a necessidade de uma posterior análise e processamento dessa informação
de modo a gerar nova informação, quer de carácter quantitativo, quer de carácter
qualitativo, que proporcione um novo nível de observação dos projectos, mais focado e
ajustado às dificuldades mais verosímeis.
12
Figura 2.8: Principais áreas dos projectos
Figura 2.9: Funcionamento de um Relatório Integrado de Projectos
É por todas estas razões que hoje em dia, na área de gestão de projectos torna-se
imprescindível a utilização de uma ferramenta que auxilie na organização e no controlo
dos projectos em curso, tanto a um panorama geral como a nível mais individual. Esta
necessidade de superintendência dos projectos acentua-se quando se procura apostar na
prevenção de problemas, através por exemplo da sinalização atempada das áreas mais
problemáticas ou contingentes de cada projecto.
13
2.2 Objectivos
Dado o âmbito do problema, e tendo em conta os limites estabelecidos para o
desenvolvimento deste projecto, torna-se agora necessário definir quais os objectivos a
atingir com a realização deste projecto.
Com a introdução de um relatório integrado de projectos, neste caso denominado
portfolio de projectos, a gestão de projectos ganha uma ferramenta que alia o uso das
métricas à aplicação de sistemas informáticos para análise e suporte à decisão. Deste
modo, o principal objectivo deste projecto passa pela implementação de um protótipo
funcional, constituído por dois principais módulos, divididos pelas suas especificidades
e diferenças de âmbito:
Módulo de recolha de informações a partir dos mecanismos de reporting já
existentes, que contêm todas as informações relevantes dos projectos em
progresso. Este módulo deve ainda ser capaz de processar estas
informações, produzindo outro tipo de informações úteis mais direccionado
e adaptado às métricas estabelecidas, e de as armazenar de forma
consistente, permitindo a sua posterior consulta. Este módulo será, daqui
em diante, designado Serviço de Actualização;
Módulo de consulta e apresentação das informações recolhidas pelo Serviço
de Actualização, proporcionando aos GP um modo de visualização
integrado dessas informações sob a forma de uma Web Application. Este
módulo será, daqui em diante, designado Serviço de Apresentação.
Figura 2.10: Principais módulos do projecto
A principal meta a atingir com a elaboração deste projecto passa essencialmente
pelo aumento da taxa de sucesso dos projectos ao permitir um maior controlo e
capacidade de antecipação de problemas dos mesmos. Para isso, este projecto deve
enquadrar diversas vantagens para a gestão de projectos, nomeadamente ao reduzir:
o número de pirâmides inversas entre o que é vendido e o que é deveras
executado;
a falta de alteração e adaptação dos planos de projecto;
a estagnação nos 99% de conclusão dos projectos;
14
a insuficiência na gestão de riscos;
a pobreza da gestão de âmbito;
a escassez de controlo de qualidade nos produtos entregues
a repetição sistemática dos mesmos erros de gestão.
A actuação em cada um destes aspectos por parte deste projecto passa
essencialmente pela postura activa que permite manter a gestão de topo informada,
através do fornecimento de informação actualizada e útil no controlo dos projectos, e
pela promoção da partilha de informação entre os vários intervenientes no projecto.
2.3 Metodologias
O desenvolvimento deste projecto seguiu uma abordagem bastante metódica,
baseada num processo de desenvolvimento de software orientado às funcionalidades –
Feature Driven Development (FDD). Esta técnica faz parte das metodologias ágeis e
permite um desenvolvimento iterativo e incremental do projecto, ao mesmo tempo que
permite a aplicação de um conjunto de boas práticas, com o objectivo funcional de
proporcionar a implementação de software funcional em espaços de tempo pré-
determinados [Amb07].
Assim sendo, todo o processo de desenvolvimento deste projecto foi subdividido
em 4 fases distintas, ordenadas pelo seu grau de precedência em relação a outras, já que
todo este processo de desenvolvimento se encontra totalmente encadeado:
Análise dos requisitos – esta fase tem como objectivo endereçar as várias
linhas de desenvolvimento do projecto, identificando os seus principais
requisitos e resolvendo eventuais ambiguidades ou inconsistências;
Design – esta fase representa o primeiro passo na concepção do produto,
sendo realizada toda a especificação funcional deste, com base nos
requisitos identificados na fase anterior, e elaborada a arquitectura do
sistema. Nesta fase será igualmente contemplada a elaboração de dois
pequenos protótipos, spikes, que representam cada um dos módulos do
projecto e que pode ajudar a comprovar a viabilidade de cada parte do
projecto, validando-o como um todo;
Implementação – nesta fase será implementado tudo o que foi especificado
nas duas fases anteriores, de acordo com as ilações tiradas da realização dos
protótipos;
Testes – após a implementação é importante realizar testes que validem e
verifiquem se o produto se encontra de acordo com as suas especificações e
se cumpre todos os requisitos. [Fis01]]
2.4 Planeamento
Antes de iniciar a primeira fase do projecto, com o levantamento de requisitos, foi
elaborado um planeamento que permite ir verificando o estado do projecto ao longo do
15
tempo, assegurando uma correcta ordem de progresso e auxiliando no controlo da
conclusão de cada fase.
Como uma das ferramentas de reporting a incluir para a construção do relatório
integrado é precisamente o MSProject, esta parecia uma boa ferramenta para a
planificação do projecto. Assim, para além das vantagens inatas ao trabalho com esta
ferramenta para a gestão do projecto, seria possível efectuar uma “introdução” ao seu
funcionamento, facilitando a sua posterior integração no projecto.
Deste modo, seguindo a metodologia mais comum para o planeamento e controlo
do projecto, foram criados quatro nós principais:
Milestones;
Actividades;
Dependências;
Reuniões e documentos periódicos.
Figura 2.11: Planificação geral do projecto
As milestones englobam as datas mais importantes do projecto, marcando
fundamentalmente as principais deliverables.
Figura 2.12: Planificação das Milestones do projecto
As actividades representam as tarefas propriamente ditas do projecto. Estas
englobam as 4 fases referidas no capítulo 2.3, dando a perspectiva fundamental do
progresso do projecto ao longo do tempo. No anexo A. Planeamento encontra-se
um diagrama de Gantt com a esquematização das durações previstas para cada fase,
incluindo o contraste entre uma perspectiva optimista e uma perspectiva pessimista.
16
Figura 2.13: Planificação das Actividades do projecto
Como é perceptível pela observação da Figura 2.13, as actividades encontram-se
divididas em 6 fases, contemplando a especificação, a implementação da base de dados
e dos dois módulos do projecto e a produção de documentação e realização de testes.
A conjunção entre estas 6 fases do planeamento e as 4 fases da metodologia são
perceptíveis na Figura 2.14.
17
Figura 2.14: Fases de desenvolvimento do projecto
No processo de análise e especificação de requisitos foram realizadas diversas
reuniões com o cliente e com os utilizadores finais, de forma a obter uma visão o mais
realista possível do produto pretendido. Com base nos dados obtidos nesta
especificação, foi desenvolvido um documento de especificação de requisitos e um
documento de especificação funcional, que inclui a arquitectura e as decisões
tecnológicas. No final desta fase foram realizadas as duas provas de conceito (spikes)
que serviram para validar os requisitos e parte da especificação funcional. Na fase
seguinte e com base em toda a informação recolhida anteriormente procedeu-se à
implementação do sistema, dividida em 4 fases que correspondem a cada parte do
sistema (Figura 2.14). Ao longo do desenvolvimento foram sendo feitas diversas
validações pelo cliente e respectivos ajustes ao sistema, principalmente a nível de
usabilidade da interface gráfica.
Nas dependências enquadram-se todas as tarefas que não dependem directamente
da implementação, ou seja, as dependências externas. Estas podem ser aprovações de
documentação, das provas de conceito ou de partes do produto, ou pedidos externos
como a disponibilização de ambientes para testes.
Nas reuniões e documentos periódicos inclui-se toda a documentação que é
produzida semanalmente ou mensalmente (como os Pontos de Situação do projecto
semanais), as reuniões de Ponto de Situação internas e as reuniões com a orientação da
FEUP.
18
2.5 Resumo e Conclusões
Neste capítulo foi analisado o modo de abordagem ao problema, com vista ao
correcto desenvolvimento do projecto. Para isso foram traçados os seus principais
objectivos, as metodologias e o planeamento a serem seguidos para que os objectivos
sejam concluídos em tempo oportuno.
As principais ilações que se retiram deste capítulo enquadram-se na percepção do
que este projecto significa para a gestão de projectos e em especial para a PT-SI. Numa
altura em que a taxa de sucesso dos projectos desenvolvidos, apesar de melhorar nos
últimos anos, ronda valores que continuam a não ser os mais desejados, urge uma acção
de optimização deste processo, segundo quatro dimensões principais, das quais se
destacam as métricas e os sistemas. O PTSIPortfolio enquadra-se precisamente numa
perspectiva de conciliação destas dimensões, ao representar uma mais-valia para os GP
a vários níveis. É também perceptível pela leitura deste capítulo que o desenvolvimento
deste projecto seguirá uma estrutura iterativa, com um planeamento bem definido e
segmentado em várias fases, que se adequam a cada vertente do projecto ao mesmo
tempo que servem os interesses de todos os stakeholders do projecto.
19
3 Estudo do Estado da Arte
Depois de toda a contextualização e enquadramento do projecto, torna-se
necessário, antes de avançar para a especificação da solução, compreender o impacto da
sua realização no mundo real. Para isso é fundamental conhecer o que já existe a nível
da sua área de desenvolvimento, considerando outros projectos relacionados que
possuam o mesmo âmbito ou finalidade. O estudo deste ponto implica a realização de
uma investigação nesse sector, oferecendo a oportunidade de perceber até que ponto a
realização deste projecto pode ou não ser uma oportunidade de desenvolvimento, e em
que sentido. Com este estudo é igualmente relevante efectuar uma análise das
tecnologias que seriam mais propícias a utilizar no projecto, tendo em conta as
tecnologias enquadradas por outros produtos semelhantes e as próprias potencialidades
de tecnologia, tendo em consideração as necessidades impostas pela própria PT-SI.
3.1 Sistemas Relacionados
Um portfolio de projectos é, actualmente, uma necessidade primária de qualquer
empresa e dos seus GP para a gestão e controlo dos seus projectos. Como tal, este é um
ponto crucial na estratégia competitiva destas empresas, contribuindo de uma forma
significativa para a criação de valor ao maximizar as taxas de sucesso dos projectos. Por
estes motivos é compreensível e natural que exista alguma dissimulação a este nível por
parte das próprias empresas, havendo uma carência de divulgação deste tipo de
informação.
Todavia, existe conhecimento em domínio público que muitas empresas do ramo
de desenvolvimento da PT-SI possuem o seu próprio portfolio de projectos, adaptado e
adequado às suas necessidades, enquanto outras (a grande maioria) se cinge a soluções
mais genéricas, embora também mais reconhecidas e certificadas. Os exemplos mais
comuns destas soluções passam muitas vezes por ferramentas OpenSource (Figura 3.1),
já que não implicam quaisquer tipos de encargos monetários [Tin09]. Outros exemplos,
eventualmente ainda mais abundantes, são as soluções da Miscrosoft, como o já referido
MSProject, já que são ferramentas bastante práticas e flexíveis que, apesar de envolver
custos significativos de manutenção, são bastante credenciadas nesta área e muitas
vezes justificam o custo de investimento [OFF09].
20
Figura 3.1: Ferramentas OpenSource para gestão de projectos
Acontece que, mesmo considerando todas estas ferramentas, que se adaptam a
pequenas, médias e grandes empresas e ajudam a acompanhar os projectos, os recursos,
os clientes, os contactos, o planeamento e mesmo o agendamento diário de tarefas, todas
elas são genéricas e abstraídas, fugindo muitas vezes da verdadeira essência da gestão
nas empresas. Ora, o PTSIPortfolio vai um pouco mais longe na sua especificidade,
apesar de ficar aquém nas funcionalidades. E isto porque reúne toda a informação útil
em relação aos projectos, e consolida-a tendo em conta as métricas e metodologias
internas da empresa, não sendo por isso uma ferramenta de gestão de projectos, mas
uma solução para monitorização dos mesmos. Inclusivamente o seu objectivo é assentar
noutras ferramentas e recolher os seus dados para os uniformizar. E o que é certo é que
não existem actualmente ferramentas acessíveis no mercado com este nível de
funcionamento.
3.2 Oportunidade de Desenvolvimento
Tendo em consideração os aspectos referidos na secção anterior, é perceptível que
o desenvolvimento deste projecto é, de facto, uma oportunidade de concretizar uma
ideia potencialmente nova, com um carácter mais específico e mais adaptado às
necessidades da empresa, proporcionando consequentemente um valor acrescentado aos
produtos desenvolvidos. Por esta razão, o PTSIPortfolio representa uma mais-valia a
nível da gestão de projectos, viabilizando a utilização de métricas, sinais, indicadores e
metodologias da «casa», privilegiando a sua própria definição de gestão de projectos
com base nas melhores práticas definidas pelo PMI [PMI04].
3.3 Revisão Tecnológica
Nesta fase do projecto torna-se necessário efectuar algumas pesquisas sobre as
tecnologias a utilizar para a implementação do sistema. Assim, primeiramente é
necessário seleccionar um subconjunto das tecnologias passíveis de serem utilizadas, de
modo a reduzir o universo de procura. Numa segunda fase será preciso considerar o
modo como cada tecnologia se adequa ao que se pretende fazer tendo em conta as suas
potencialidades e os objectivos que são propostos a atingir e, então, seleccionar as que
mais se adequam.
21
3.3.1 Identificação das Tecnologias
Seguidamente são apresentadas as tecnologias que foram identificadas com
potencial para serem utilizadas no sistema, tendo em conta os requisitos impostos para o
desenvolvimento do projecto.
Para o ambiente de desenvolvimento:
o Visual Studio 2008
Para o Servidor:
o .Net Framework
Para os Clientes Web:
o ASP.NET
o Dundas Chart
o Dundas Gauge
Para Sistema de Gestão de Bases de Dados (SGBD):
o MySQL
o Oracle
o SQL Server
o PostgreSQL
Desde logo denota-se uma tendência acentuada para o uso de tecnologias
Microsoft, já que este é precisamente um dos requisitos especificados no início para o
desenvolvimento do projecto. Na maior parte das áreas inclusivamente não se podem
colocar alternativas, já que as tecnologias Microsoft são incompatíveis com as restantes
tecnologias de desenvolvimento existentes. Apenas no caso dos SGBD é que existem
mais alternativas de escolha, já que qualquer um dos actuais sistemas poderá ser
utilizado, mesmo que todas as restantes áreas sejam tecnologias Microsoft.
3.3.2 Decisões Tecnológicas
A justificação para a escolha das tecnologias é decorrente das funcionalidades e da
relação custo/benefício de cada uma, tendo sempre presente as restrições impostas para
o desenvolvimento do projecto.
Assim, a nível de tecnologias Web é necessário considerar que este é o ponto de
contacto com o utilizador da aplicação, e que por isso mesmo deve ser um aspecto
importante a considerar. Já a nível dos SGBD a interacção com o utilizador não é tão
valorizada, já que a forma de armazenamento e manuseamento dos dados será invisível
22
para este. De qualquer modo é necessário considerar a maneira como estas tecnologias
irão interagir entre si, de forma a maximizar performance e capacidade destes.
Como se compreende pela secção 3.3.1, o desenvolvimento encontra-se
especificamente virado para tecnologias Microsoft, o que por si só justifica a maioria
das escolhas e os requisitos impostos. Mesmo sendo uma tecnologia imposta pela PT-
SI, são vários os motivos que levariam à escolha deste tipo de tecnologias, mas
principalmente devido à sua interoperabilidade com qualquer tipo de componente
Windows e com todas as plataformas da PT-SI mencionadas nos capítulos anteriores.
Também o facto de os webservers da PT-SI operarem com o Windows Server 2000 com
a plataforma Internet Information Services (IIS) leva a que a melhor escolha para o
desenvolvimento seja de facto a .NET Framework.
Outro factor preponderante para a escolha desta tecnologia foi precisamente a
facilidade de desenvolvimento e integração Web Services e Windows Services. De entre
as linguagens de programação fornecidas pela framework foi seleccionada o C# pela
qualidade da linguagem e pela rapidez que proporciona para o desenvolvimento do
código. Assim sendo, as tecnologias a utilizar neste projecto são:
Para o ambiente de desenvolvimento:
o Visual Studio 2008 – tendo em conta a Framework a utilizar, que
será necessariamente da Microsoft, esta parece a melhor solução
como ferramenta para o desenvolvimento do projecto, pela sua
óptima integração com .Net Framework.
Para o Servidor:
o .Net Framework - a linguagem de programação a utilizar será a
linguagem C#, sendo por isso também preferencial para o
desenvolvimento na Framework .NET em versão 3.5.
Para os Clientes Web:
o ASP.NET – sendo o restante projecto realizado em .Net C#, é de
todo adequado que a interface Web seja igualmente desenvolvida
com codebehind em C#, utilizando para tal a tecnologia APS.NET.
o Dundas Chart e Gauge para ASP.NET- o software Dundas oferece
uma fácil e eficiente integração com ASP.NET, apresentando-se
como uma considerável solução para a criação de gráficos e de
indicadores visuais.
Para o SGBD:
o SQL Server – a escolha recaiu por esta tecnologia não apenas pela
sua integração com as restantes tecnologias Microsoft, mas também
por ser um sistema robusto e fiável, com garantias de desempenho e
integridade dos dados adequadas e com um extenso suporte de
funcionalidades.
23
3.3.3 Web Services
Para a integração entre o projecto PTSIPortfolio e os sistemas de reporting optou-
se pela tecnologia Web Services (WS). Isto porque os WS fornecem um método
standard de interoperabilidade entre diferentes aplicações de software, podendo ser
executadas em variadas plataformas e/ou frameworks.
Os WS são caracterizados pela sua grande interoperabilidade e extensibilidade,
facilitando assim o multi-processamento com a utilização do XML como formato de
troca de dados. Serviços simples podem então ser combinados entre si para realizar
operações complexas [W3C02].
Figura 3.2: Modelo de funcionamento dos Web Services
Associado aos serviços dos WS existe uma descrição dos métodos (Web methods)
suportados pelos mesmos (service contract). Para tratamento desses contratos optou-se
por utilizar a Web Services Description Language (WSDL). Um WSDL descreve os
serviços de duas formas, sendo que a primeira, mais abstracta, descreve o WS a nível do
protocolo das mensagens que são trocadas entre o fornecedor de serviços e o futuro
cliente, enquanto na segunda, mais concreta, é especificado o formato do transporte de
dados de acordo com as definições do servidor onde os serviços são disponibilizados.
Com estes dois tipos de descrições são definidas as interfaces públicas para os WS
[W3C07].
3.3.4 Windows Services
O projecto de desenvolvimento do Serviço de Actualização será um Windows
Service, que no fundo é uma forma de criar um executável que executa funções
específicas sem necessidade de interferência dos utilizadores. Este tipo de serviços pode
ser configurado para iniciar com o arranque do sistema operativo Windows, ou num
horário predefinido, e pode correr em background ao mesmo tempo que o Windows está
a correr, sem interferência com outros programas [MIC09].
Isto é precisamente o que se pretende que aconteça com o Serviço de Actualização,
já que este deve ter uma execução automática e não deve necessitar de interferência
humana. Assim pode, periodicamente e de forma automática, recolher as informações
dos sistemas externos, sem qualquer necessidade de manutenção.
24
3.4 Resumos e Conclusões
Depois de compreendido o problema, e antes de passar à especificação da sua
solução, foi efectuado um estudo relativo a aplicações já existentes que apresentem um
funcionamento ou finalidade iguais ao PTSIPortfolio, incluindo outros trabalhos
relacionados, de forma a apurar possíveis pontos importantes para essa especificação.
Concluí-se que actualmente não existe no mercado empresarial uma ferramenta com o
mesmo âmbito de foco deste projecto, pelo que é realçada a realização deste como
oportunidade de desenvolvimento, representando uma solução inovadora que pode
ajudar a empresa, em especial os GP a atingir mais e melhores resultados nos projectos
que desenvolvem. Foi também efectuada uma análise das principais tecnologias que
poderiam servir os interesses do projecto, ao potenciar as suas funcionalidades tendo em
vista os melhores resultados possíveis. As principais conclusões rondam as tecnologias
Microsoft, tanto a nível de base de dados (SQL Server), a nível Web (C# ASP.NET), e
mesmo a nível da própria plataforma de desenvolvimento, que junta Visual Studio 2008
e .NET FrameWork. Será igualmente utilizada a tecnologia Web Services, que permite a
integração do PTSIPortfolio com os Sistemas Externos de onde será feita a recolha de
dados.
25
4 Especificação da Solução
O processo de especificação de requisitos do sistema decorreu entre o início de
Março e prolongou-se sensivelmente até meio do mesmo mês. Durante todo este
processo foram realizadas diversas reuniões com o cliente, com o objectivo de obter
uma visão realista e específica das necessidades deste projecto, ao mesmo tempo que se
efectuaram estudos de documentos pré-concebidos que apresentavam o produto e as
suas funcionalidades finais aos GP. Após um período de análise e processamento desta
informação, foi elaborado o Caderno de Requisitos, cujo conteúdo mais específico se
encontra parcialmente reproduzido neste capítulo. De forma a fornecer uma visão de
como o projecto evoluiu desde essa especificação inicial, o capítulo foi ligeiramente
adaptado, passando a estar mais coerente com os ajustes e necessidades dos GP que
foram reportadas. Esta especificação é efectuada com recurso à técnica de recolha de
requisitos use cases (casos de utilização) [Gor06], de forma a obter uma visão geral das
principais funcionalidades do sistema. Para melhor percepção dos requisitos
especificados, são apresentados diagramas elaborados segundo a linguagem de
modelação UML (Unified Modeling Language) [OMG08], sempre acompanhados de
descrições textuais.
Uma especificação mais completa dos casos de utilização identificados encontra-se
no anexo B. Casos de Uso.
4.1 Contexto do Produto
Ambos os módulos do sistema estarão alojados nos servidores da PT-SI, sendo o
seu funcionamento controlado pelos gestores destes servidores. O Serviço de
Actualização deve funcionar sem qualquer necessidade de interferência de um
utilizador, correndo como Windows Service, enquanto o Serviço de Apresentação será
uma aplicação Web podendo, por isso mesmo, ser acedido através de um Web browser.
Os seus principais utilizadores serão os GP, que poderão aceder a esta aplicação com o
intuito de visualizar informação sobre os seus projectos em curso.
26
4.2 Funções do Produto
Uma vez que o sistema se divide segundo duas unidades funcionais distintas, as
funcionalidades de cada uma também se encontram subdivididas.
4.2.1 Funções do Serviço de Actualização
O Serviço de Actualização deve possuir o seguinte leque de funcionalidades:
acesso aos sistemas externos de integração – o Serviço de Actualização
deve estar dotado de processos que consigam aceder a um conjunto de
sistemas externos que contêm informações relevantes sobre os projectos;
recolha e armazenamento de informações dos projectos – os processos do
Serviço de Actualização devem recolher informações relevantes sobre os
projectos e armazená-las na Base de Dados Central (BDC).
processamento da informação armazenada – os processos do Serviço de
Actualização devem ainda processar a informação que armazenaram, de
modo a inferir informações pertinentes sobre os projectos e que não se
encontram directamente acessíveis nos sistemas externos. Estas
informações devem ser igualmente armazenadas na BDC e terão como
principal objectivo o seu posterior uso para fins estatísticos.
4.2.2 Funções do Serviço de Apresentação
O Serviço de Apresentação deve possuir o seguinte leque de funcionalidades:
apresentação da informação armazenada – o Serviço de Apresentação deve
ser capaz de processar a informação armazenada e de a apresentar, textual
ou graficamente, sob a forma de uma página Web;
interacção com o utilizador – o Serviço de Apresentação deve promover a
interacção com os diversos utilizadores do sistema, privilegiando a
navegação entre páginas, a gestão de conteúdos e a realização de outras
operações cujo âmbito se enquadre no funcionamento do sistema.
4.3 Características dos Utilizadores
Os utilizadores do sistema poderão usufruir das funcionalidades do sistema através
da interacção com o Serviço de Apresentação, que poderá ser acedido através da
utilização de um browser instalado numa máquina com acesso à Intranet da PT. É,
portanto, necessário que os utilizadores possuam as infra-estruturas necessárias, bem
como privilégios de acesso.
Tratando-se de um sistema que se pretende simples e eficaz para tarefas de gestão,
é imperativo a simplificação das suas funcionalidades, no sentido de excluir a
necessidade de formação por parte dos utilizadores. Assim sendo, a nível técnico estes
devem apenas possuir conhecimentos básicos de utilização de browsers Web.
27
4.4 Restrições
São aplicáveis ao funcionamento do sistema todas as restrições externas que não
estejam directamente relacionadas com o mesmo, como é o caso de:
Cortes de energia;
Indisponibilidade da intranet.
4.5 Pressupostos e Dependências
Para assegurar um correcto funcionamento do sistema (de acordo com o que
encontra especificado), pressupõe-se que:
o servidor que alberga o Serviço de Actualização encontra-se ligado em
horário de execução;
o servidor que alberga o Serviço de Apresentação encontra-se ligado em
horário de execução;
o sistema operativo dos servidores que albergam o Serviço de Actualização
e o Serviço de Apresentação possui capacidade para garantir o
funcionamento sem falhas destas aplicações;
os utilizadores e administradores do sistema possuem conhecimentos
necessários para utilizar um browser Web;
a interface de apresentação e configuração será acedida por um dos
seguintes browsers Web:
o Internet Explorer 7;
o Mozilla Firefox 3;
o Qualquer browser Web que ofereça compatibilidade com os
standards Web actuais definidos pela entidade W3C [W3C09];
o servidor possui capacidade de armazenamento de dados ilimitada;
a ligação de dados entre o Serviço de Actualização e os sistemas externos é
segura e fiável;
os parâmetros de configuração para acesso aos sistemas externos não serão
alterados sem o prévio ajuste do Serviço de Actualização.
4.6 Requisitos Funcionais
Os requisitos funcionais visam descrever as funcionalidades do sistema, de um
modo geral. Para maior facilidade de percepção, irá ser efectuada uma divisão em
pacotes e em módulos de casos de utilização, começando por uma visão geral do
sistema a nível global, e depois passando para cada um dos componentes do sistema.
28
4.6.1 Visão Geral do Sistema
Dado que o sistema se subdivide em dois segmentos principais – o Serviço de
Actualização e o Serviço de Apresentação – também os requisitos devem estar divididos
segundo estas duas vertentes. Assim sendo, a nível de requisitos funcionais do sistema
evidenciam-se dois pacotes:
Utilizadores
PTSIPortfolio
Pacote Serviço de
Actualização
Pacote Serviço de
Apresentação
Figura 4.1: Visão geral do Sistema
4.6.2 Pacote Serviço de Actualização
Tendo em conta as funcionalidades previstas para o Serviço de Actualização, é
perceptível que este módulo não compreende interacção com qualquer utilizador (no seu
normal funcionamento, salvo operações pontuais de manutenção). Assim sendo, não
existirão actores a este nível.
No que respeita aos seus casos de utilização, estão contemplados dois, que se
enquadram nas suas principais funcionalidades. É então compreensível que o
funcionamento desejado do Serviço de Actualização se reflicta numa execução
automática, com uma sequência de serviços que envolvem duas fases, que são
precisamente os casos de uso referidos.
Assim o primeiro caso de uso envolve uma integração com os Sistemas Externos,
através dos Web Services1, permitindo a recolha dos dados mais actualizados dos
projectos em curso a partir de cada um desses sistemas. O segundo caso de uso implica
a integração com a BDC, representando o devido armazenamento das informações
recolhidas nessa base de dados.
1 O desenvolvimento destes Web Services não faz parte do projecto, sendo que estes foram facultados por outros elementos do mesmo departamento. A integração com os Sistemas Externos foi, portanto, efectuada unicamente pela integração destes Web Services no projecto do Serviço de Actualização
29
Recolher Dados
Armazenar Dados
Serviço de Actualização
Figura 4.2: Casos de utilização do Serviço de Actualização
4.6.3 Pacote Serviço de Apresentação
4.6.3.1 Visão Geral
Por uma questão de simplificação de inteligibilidade e de especificação, o Serviço
de Apresentação foi modularizado, dividindo os seus requisitos pelas principais áreas
afectadas. Existem portanto três módulos principais:
o módulo Project Master List (PML),
o módulo Perspectivas e
o módulo Administração,
que serão acedidos por dois tipos de actores diferentes:
o Utilizador Registado e
o Administrador.
A interacção entre os módulos e os actores é perceptível pela interpretação da
Figura 4.3.
De notar que a aplicação será utilizada no contexto de um sistema Single Sign-On,
pelo que as operações relacionadas com autenticação (iniciar sessão, terminar sessão,
mudar palavra-chave, entre outras) não são contempladas. Da mesma forma, também
não é considerado o actor «Utilizador Não Registado», já que este não intervém
directamente com o sistema. Ao iniciar sessão na máquina através da rede PT, o Active
Directory reconhecerá o utilizador e concederá, ou não, o acesso à aplicação. Desta
forma tudo o que será efectuado a nível de autenticação é a integração com o Active
Directory da PT.
30
Utilizador Registado
Administrador
Serviço de Apresentação
Módulo Project Master List
Módulo Perspectivas
Módulo administração
Figura 4.3: Visão geral do pacote Serviço de Apresentação
4.6.3.2 Actores
O sistema enquadra fundamentalmente dois tipos de actores, segundo os seus
privilégios de acesso e operações que podem realizar (Figura 4.4).
Estes actores são:
Utilizador Registado - Representa todos os utilizadores registados do
sistema e que podem efectuar operações de visualização da informação e de
gestão de conteúdos. Podem ser gestores ou colaboradores de um projecto,
líderes de domínios ou sub-domínios, directores, ou membros de outras
equipas relacionadas com a gestão de projectos;
Administrador – Representa os utilizadores registados que possuem
privilégios adicionais de moderação no sistema. Podem desempenhar
funções de gestão a nível:
o dos utilizadores;
o dos parâmetros de configuração e funcionamento do sistema;
o dos projectos, indicando o nível da classe e da visibilidade de um
projecto.
31
Utilizador Registado
Administrador
Actores do Sistema
Figura 4.4: Actores do sistema
4.6.3.3 Módulo Project MasterList
Neste módulo consideram-se todas as operações que se podem realizar na chamada
Project Master List, onde se encontra listados todos os projectos, e possui três modos de
visualização:
Vista Agregada;
Vista Plano;
Vista Financeira.
As operações passíveis de serem realizadas nesta lista são várias, e incluem, para
além da sua consulta, a alternância de vistas (em que são mostrados atributos diferentes
para os mesmos projectos, consoante o âmbito da vista respectiva) e a ordenação da lista
nas várias vistas pelos seus atributos, de modo ascendente ou descendente e a consulta
ou criação de comentários relativos a cada projecto. Para poder fazer um comentário é
necessário abrir uma janela para leitura dos comentários existentes até à data.
É também possível consultar informações mais específicas de cada um dos
projectos listados, seleccionando a linha correspondente ao mesmo.
32
Consultar Project
Master List
Utilizador Registado
Ordenar Projectos
Consultar
comentários de um projecto
Efectuar comentário
a um projecto
«extends»
Módulo Project Master List
Seleccionar
projecto para consulta
Alternar entre
vistas
Figura 4.5: Casos de uso para Project Master List (pml)
4.6.3.4 Módulo Perspectivas
Este módulo considera todas as perspectivas de introspecção de um projecto,
depois de ter sido seleccionado na PML. Estas perspectivas podem ter âmbito Geral,
Financeiro, Plano, Problemas, Defeitos, Stakeholders, Recursos ou Riscos. Para além da
sua consulta, ao visualizar uma perspectiva para um projecto é também possível, de
forma semelhante à PML, consultar e criar comentários. Estes comentários serão
sempre relativos ao respectivo projecto, e poderão estar relacionados com um qualquer
item integrante da perspectiva ou com a própria perspectiva de um modo geral.
33
Consultar dados da
Perspectiva
Utilizador Registado
Consultar comentários de
uma Perspectiva/
Subperspectiva
Efectuar comentário a
uma Perspectiva/
Subperspectiva
«extends»
Módulo Perspectivas
Figura 4.6: Casos de uso para Perspectivas (per)
4.6.3.5 Módulo Administração
Este módulo enquadra as tarefas de administração relativas aos projectos existentes
no sistema.
As operações que se podem realizar são, na sua maioria, de especificação de
atributos internos de um projecto, como a sua pertença ou não ao Radar, os valores da
sua taxonomia, ou o seu nível de classe e de visibilidade. É possível igualmente
adicionar um novo projecto ao sistema, para que o Serviço de Actualização possa
recolher informações sobre o mesmo (no entanto não é possível eliminar projectos do
sistema, apenas poderão ser definidos como não actualizáveis) ou especificar quais os
projectos visíveis, i.e., que deverão aparecer na PML.
À semelhança dos módulos anteriores, também neste módulo é possível consultar e
efectuar comentários relativos a cada projecto, mas desta feita de um âmbito mais
restrito à administração e manutenção do próprio projecto no sistema.
34
Utilizador Registado
Especificar
Projectos visíveis
Módulo Administração
Alterar atributos
de um Projecto
Adicionar novo
projecto
Adionar observações
de administração
Figura 4.7: Casos de uso para Administração (adm)
4.7 Requisitos Não Funcionais
Os requisitos não funcionais apresentam como principal objectivo a especificação
de como o sistema se deve se comportar de modo geral. Assim, tendo em conta o
âmbito do projecto, os seguintes requisitos especificam as características e o
comportamento desejável que o sistema deve possuir.
4.7.1 Requisitos do Produto
Os requisitos do produto são requisitos inerentes ao sistema de software a
desenvolver, de modo a assegurar que o seu modo de funcionamento é o mais
adequado. Estes requisitos reflectem aspectos como a facilidade de uso, a eficiência
(tanto a nível de desempenho como de ocupação de espaço), a confiabilidade e a
portabilidade.
35
Tabela 4.1: Requisitos não funcionais (produto)
ID Nome Descrição Prioridade
rnf_001 Fiabilidade O sistema deve providenciar dados
actualizados e garantir a sua integridade
através da actualização sistemática dos seus
dados. A robustez do software deve ser a
mais apurada possível, evitando perdas de
informação.
Essencial
rnf_002 Usabilidade O sistema deve privilegiar uma fácil
interacção com os utilizadores,
disponibilizando uma interface simples,
agradável e intuitiva, sem comprometer o seu
propósito.
Essencial
rnf_003 Eficiência O sistema deve efectuar operações de
consulta, pesquisa e edição o mais rápido e
eficientemente possível e assegurar que as
comunicações efectuadas não sofrem atrasos
inadequados.
Desejável
rnf_004 Segurança O sistema deve garantir a integridade dos
seus dados segundo duas vertentes: controlo
de acessos, com a verificação dos privilégios
de cada utilizador para uma determinada
operação e protecção contra danos acidentais
ou maliciosos, com a criação de backups de
dados de forma recorrente.
Desejável
rnf_005 Portabilidade A execução do sistema deve ser de
compatibilidade universal, tanto a nível de
Hardware como de Software, correndo em
diferentes Sistemas Operativos e em
diferentes browsers.
Opcional
36
rnf_006 Escalabilidade O sistema deve ser concebido de uma forma
modularizada, permitindo uma fácil
manipulação e alteração dos seus
componentes, bem como a adição de novas
funcionalidades.
Opcional
4.7.2 Requisitos Externos
Os requisitos externos representam requisitos derivados do ambiente onde o
sistema estará inserido, estando relacionados com restrições impostas por factores
externos ao sistema.
4.7.2.1 Interfaces com o Utilizador
A interacção com o utilizador deve ser um dos pontos fulcrais do sistema, já que
vai mediar todo o contacto com este para a realização de consultas, pesquisas e edições
de conteúdos da aplicação. Tendo em conta as características dos utilizadores do
sistema, a interface deve privilegiar características como a simplicidade, acessibilidade,
celeridade, facilidade e eficácia de uso. Deve, portanto, ser directa e intuitiva,
promovendo a interacção com o rato mesmo a utilizadores com conhecimentos básicos
na utilização de browsers.
4.7.2.2 Interfaces de Hardware
A nível de Hardware apenas é necessário assegurar a existência de uma máquina
com capacidade adequada (processamento e memória) e ligação permanente à intranet.
4.7.2.3 Interfaces de Software
No que respeita a componentes de Software, é necessário um sistema de gestão de
bases de dados (SGBD) no servidor que albergar a BDC, e a instalação de um sistema
operativo que suporte o uso de um browser para acesso ao sítio Web.
4.7.2.4 Interfaces de Comunicação
O processo de comunicação entre o Serviço de Actualização / Serviço de
Apresentação e a BDC deve efectuar-se através de uma ligação de rede (no caso de
correrem em máquinas diferentes) ou através de uma ligação entre módulos (no caso de
correrem na mesma máquina).
4.8 Resumo e Conclusões
O capítulo quarto enquadra uma especificação completa dos requisitos do sistema,
incluindo uma descrição geral das funcionalidades do produto, as características dos
seus utilizadores, as suas restrições e os seus pressupostos de dependências. Inclui
igualmente a análise dos seus requisitos específicos, tanto a nível de requisitos
funcionais como não funcionais, tendo sempre em consideração a segmentação do
sistema segundo os seus principais módulos: o Serviço de Actualização e o Serviço de
Apresentação. Foram identificados os principais casos de uso da aplicação Web, quer a
nível da PML, quer a nível das perspectivas específicas do projecto.
37
As principais ilações que se retiram deste capítulo residem no facto de perceber que
o Serviço de Actualização será um serviço automático, sem necessidade de interferência
de utilizadores, que recolhe as informações de determinados projectos a partir de
determinados Sistemas Externos, num período de tempo pré-definido. Deve também dar
especial atenção à escalabilidade de arquitectura. O Serviço de Apresentação, por sua
vez, deve privilegiar a interacção com o utilizador, apresentando as suas informações de
um modo claro e intuitivo e dando atenção a aspectos como a usabilidade, a fiabilidade,
a eficiência e a portabilidade.
38
5 Implementação
Concluída a especificação de requisitos, que representa “o que se pretende fazer,” e
antes de iniciar a implementação propriamente dita, é necessário desenvolver um
processo de especificação funcional, que representa “como fazer”. Este processo
iniciou-se sensivelmente a meio do mês de Março e terminou no final do mesmo mês.
Ao longo desta fase foi elaborado o Relatório de Concepção Técnica que documenta e
especifica a estrutura com que o sistema PTSIPortfolio foi desenvolvido e o modo da
sua concepção e evolução ao longo do tempo. O seu conteúdo mais importante
encontra-se parcialmente reproduzido neste capítulo, onde é descrito com o maior rigor
de detalhe possível o Modelo Físico do Sistema nas suas duas vertentes, Sistema e
Dados. Mais uma vez, são apresentados diagramas elaborados segundo a linguagem de
modelação UML (Unified Modeling Language) [OMG08], sempre acompanhados de
descrições textuais para facilitar a compreensão do processo.
Depois desta especificação funcional, seguiu-se a fase de implementação. Esta fase
englobou o desenvolvimento dos vários módulos do sistema, incluindo a BDC, o
Serviço de Actualização e o Serviço de Apresentação, seguindo para isso a
especificação funcional realizada na fase anterior, tanto a nível do sistema em si como a
nível de dados. Os principais pormenores e detalhes de implementação serão igualmente
apresentados ao longo deste capítulo, abordando e justificando, sempre que necessário,
quaisquer decisões técnicas não especificadas.
5.1 Arquitectura do Sistema
A arquitectura a implementar terá, fundamentalmente, de contemplar as funções
inerentes ao sistema PTSIPortfolio devendo estar estruturada de modo a que eventuais
alterações de regras de gestão ou mesmo novos requisitos sejam rápida e eficazmente
cobertos pela solução.
Para garantia destas características, a fase de concepção foi conduzida de forma a
examinar pormenorizadamente todos os módulos e estruturas de informação a
contemplar, especificando cada um deles e as suas inter-relações.
39
5.1.1 Visão Geral
A Figura 5.1 representa uma visão física do sistema, realçando as diversas
entidades envolvidas. A partir da sua interpretação compreende-se que o sistema
consiste num produto de software que irá interagir com vários sistemas externos e com
vários clientes externos. De facto, tendo em conta o âmbito do sistema é perceptível que
as operações envolvidas partem de uma recolha de dados dos diferentes sistemas
externos utilizados para a gestão de projectos, passando pelo seu processamento e
armazenamento numa base de dados e culminando com a sua apresentação de modo
adequado aos utilizadores do sistema através de um browser Web.
Figura 5.1: Arquitectura física do sistema
Diminuindo o nível de abstracção, é possível analisar cada componente
individualmente de forma a compreender a sua composição interna e os modos de
interacção com as restantes entidades (Figura 5.2). Assim sendo, dadas estas duas
figuras, são evidentes 3 módulos distintos:
Sistemas Externos – representam um agrupamento de sistemas já existentes,
que são usados para tarefas relacionadas com a gestão de projectos a
diversos níveis. O acesso a estes sistemas será efectuado através de uma
camada de Web Services, especificados no anexo D. Especificação dos Web
Services deste documento. Com esta tecnologia é possível que estas novas
aplicações possam interagir com aquelas que já existem e que os sistemas
desenvolvidos em plataformas diferentes sejam compatíveis, permitindo
uma integração destes sistemas e uma comunicação entre as diferentes
aplicações.
Sistema PTSI Portfolio – representa o sistema em si, sendo o componente
central que interliga as entidades externas. Pela interpretação das figuras,
compreende-se a sua decomposição segundo duas aplicações principais:
40
o Serviço de Actualização – aplicação que recolhe dados dos Sistemas
Externos através da execução de requests periódicos e automáticos à
interface dos Web Services. Os dados obtidos são devidamente
processados e armazenados na BDC, possibilitando a sua posterior
utilização.
o Serviço de Apresentação – aplicação Web que apresenta os dados
recolhidos pelo Serviço de Actualização de uma forma consolidada,
integrando num único local toda a informação relativa aos vários
projectos contemplados no sistema.
Clientes Web – representam os diversos utilizadores do sistema que acedem
à aplicação Serviço de Apresentação através da utilização de um browser
Web, podendo visualizar todas as informações contidas na BDC.
Figura 5.2: Arquitectura de componentes do sistema
5.1.2 Visão Conceptual
A implementação do sistema visa uma arquitectura em camadas, inter-relacionadas
e simultaneamente independentes entre elas (Figura 5.3). As camadas representam os
vários níveis de funcionamento do sistema, estando portanto dividido em três camadas
distintas:
41
Camada de Dados – enquadra toda a interacção que existe com a BDC,
contemplando funções de armazenamento e de extracção dos dados.
Camada de Lógica de Negócio – é constituída por dois componentes:
o recepção de dados, responsável pela comunicação com os Sistemas
Externos e pela ligação à Camada de Dados para o armazenamento
dos dados obtidos;
o tratamento de dados, responsável pelo processamento dos dados
antes de serem armazenados e antes de serem apresentados, de
modo a consolidar de forma adequada e eficiente toda a informação
para que possa ser correctamente utilizada pelo Serviço de
Apresentação.
Camada de Apresentação – compreende toda a interface gráfica do Serviço
de Apresentação, enquadrando os diversos tipos de representação da
informação. Assim envolve os módulos de apresentação da informação
textual e da informação esquemática segundo gráficos e segundo
indicadores de tendência. Esta camada comunica directamente com os
Clientes Web, sendo responsável por apresentar um sítio Web para consulta
das informações dos projectos.
Figura 5.3: Arquitectura conceptual em camadas
5.1.3 Visão Estática
A visão estática da arquitectura contempla os principais módulos funcionais do
sistema. Assim é de todo adequada uma divisão do sistema nas partes que o constituem,
42
já que a fase de desenvolvimento segue essa mesma divisão enquanto implementação de
duas aplicações distintas.
5.1.3.1 Serviço de Actualização
A classe principal do Serviço de Actualização é a classe UpdateService, que
recolhe de um modo sistemático (definido pelo atributo Interval) as informações dos
Sistemas Externos para as actualizar na BDC. Esta classe possui dois atributos
principais, em que o primeiro representa a lista de projectos a actualizar e o segundo
representa a lista de Sistemas Externos a consultar.
Sendo a classe principal de um Windows Service, esta possui um método OnStart,
que é precisamente onde são inicializadas as duas listas. A lista projectos é inicializada
com recurso a uma chamada a outra classe, PTSIPortfolioDataBase, através do método
GetUpdateList(), que devolve todos os projectos que possuem alguma informação de
que deverão ser actualizados. A lista de Sistemas Externos é inicializada manualmente,
de acordo com as classes constantes no projecto que puderem ser instanciadas. Numa
fase inicial apenas serão considerados três sistemas que farão parte desta lista:
EPM;
Sharepoint;
BugTracking.
A classe UpdateService é então constituída por uma Interface que representa as
principais funcionalidades desta aplicação: a extracção dos dados e o seu
armazenamento na BDC, implementadas pelo método Update() (Figura 5.5). Neste
método, chamado por recorrência em cada classe respectiva de cada sistema, é
percorrida a lista de projectos a actualizar e para cada projecto é chamado o Web
Service respectivo, recolhendo passo a passo as informações pretendidas para cada
projecto em cada sistema.
A inclusão desta Interface justifica-se pela modularidade que esta proporciona à
aplicação. Desta forma, se se pretender a inclusão de novos Sistemas Externos no
sistema, apenas terá que ser implementada a sua classe de acesso, e adicionada à lista
externalSystems.
Figura 5.4: Visão geral das classes do Serviço de Actualização
Cada uma das classes que implementam a Interface IExternalSystems é, portanto,
relativa a um Sistema Externo em específico (Figura 5.5). Assim, cada uma das classes
deve implementar o método Update() declarado na Interface.
43
Figura 5.5: Classes que implementam a Interface IExternalSystems
Cada uma destas classes, ao aceder ao Web Service respectivo, deverá processar as
informações retornadas e armazená-las na BDC. Para isso, e de modo a facilitar esta
operação, cada classe deve possuir uma abstracção dessa base de dados, ou mais
especificamente, uma abstracção das tabelas dessa base de dados com que irá interagir.
Desta forma, cada uma dessas classes possui um DataSet que contém precisamente as
tabelas onde os dados retornados serão armazenados.
5.1.3.2 Serviço de Apresentação
No Serviço de Apresentação a classe PresentationService desempenha um papel
central, sendo responsável por ligar os componentes desta aplicação. A esta cabe a
responsabilidade de conciliar as acções solicitadas pela interface da aplicação com o
acesso à BDC, facultando as informações necessárias para visualizar cada página Web
(Figura 5.6).
Assim sendo, a classe PTSIPortfolioDataBase representa os dados armazenados no
sistema, sendo que a sua função passa por armazenar e disponibilizar os dados
necessários ao normal funcionamento da aplicação. O acesso à base de dados é
efectuado com base numa connection string, que é armazenada numa variável, o que
permite a sua fácil alteração no caso de ser necessário. Os dados retornados encontram-
se organizados por funções específicas do tipo de informação que está a ser apresentada.
Por exemplo, se um utilizador estiver a consultar a PML na vista agregada, a classe de
apresentação ao carregar a página (PageLoad()) efectua uma chamada à classe
PTSIPortfolioDataBase através do método GetDataPML_Agregada().
A Interface IShowPageData implementa as principais funcionalidades de
interacção com o utilizador. Sempre que uma página é carrega, todos os seus conteúdos
são correctamente inicializados no método PageLoad(). Como descrito no capítulo 4,
praticamente todos os tipos de dados existentes no sistema estão sujeitos a comentários
dos utilizadores. Por consequência, também todas as perspectivas do Serviço de
Apresentação estão dotadas de métodos para consulta e criação de comentários,
adaptados ao tipo de dados em questão.
44
Figura 5.6: Visão geral das classes do Serviço de Apresentação
As classes que implementam a Interface IShowPageData são então as responsáveis
pela interacção com o utilizador através da interface Web, permitindo a execução de
operações de consulta de informações dos projectos e da gestão de comentários ao
implementar os métodos da Interface. Estas classes representam as várias perspectivas
do projecto, nomeadamente a PML (que inclui as três vistas), a perspectiva geral, de
plano, financeira, de problemas, de defeitos, de stakeholders, de recursos e de riscos.
Figura 5.7: Classes que implementam a Interface IShowPageData
Existe ainda uma outra classe interveniente, AuxiliaryMethods, que representa
métodos genéricos que podem ser utilizados por mais do que uma classe de
apresentação. A maioria dos seus métodos estão relacionados com a criação de
informação gráfica, mas também pode ter outros métodos auxiliares nomeadamente a
45
nível de algoritmos ou outros cálculos. Os principais elementos visuais que esta classe
engloba passam principalmente por gráficos (charts), que podem ser de vários tipos
(colunas, circulares, pontos, linhas, áreas ou radar) e por indicadores de tendência
(gauges), que podem ser circulares - e.g. velocímetros - ou lineares – e.g. barras de
estado.
5.1.4 Visão Dinâmica
Nesta secção são apresentados diagramas de sequência que espelham o
comportamento do sistema em execução. Tal como na secção anterior, também esta se
encontra dividida entre “Serviço de Actualização” e “Serviço de Apresentação”. Para
melhor explicar o funcionamento do sistema foram criados exemplos do seu
funcionamento.
5.1.4.1 Serviço de Actualização
Demonstra-se a sequência de funcionamento normal do Serviço de Actualização
aquando da recolha de informações dos projectos a partir dos Sistemas Externos.
Inicialmente, e com uma periodicidade pré-definida, sempre que for hora de actualizar
as informações dos projectos, o Sistema Operativo (Operating System) da máquina onde
o Serviço de Actualização estiver disponível será responsável por o colocar em
execução, o que desencadeia uma chamada ao seu método principal, OnStart(), para dar
inicio à recolha das informações. A aplicação iniciará o seu ciclo de recolhas,
percorrendo a lista de projectos e a lista de Sistemas Externos chamando, para cada
projecto da lista, o método Update() de cada sistema da lista. Este método desencadeia
as operações internas de recolha. Os passos para esta recolha são três, como
demonstrado na Figura 5.8:
A obtenção dos dados dos Sistemas Externos é efectuada através de um
pedido HTTP aos Web Services (Web Service Request) disponíveis para o
respectivo sistema a que tentam aceder.
O processamento da informação obtida, tendo em vista a sua consolidação
para geração de metadata com propósitos estatísticos e para geração de
informações de tendência de valores.
O armazenamento dos dados (obtidos no passo anterior) na BDC, tendo em
conta o Sistema proveniente. Cada informação recolhida terá um local
específico na base de dados, pelo que existirão várias classes de DataSets,
relativos às tabelas com que interagem.
Este ciclo de passos será sempre sequencial e mantido por esta ordem para cada
recolha de cada projecto. O número de ciclos será, pois, igual ao número de Sistemas
Externos a aceder, sendo que ocorrerá um e um só ciclo por cada sistema (no caso do
seu correcto funcionamento).
46
Figura 5.8: Diagrama de funcionamento do Serviço de Actualização
5.1.4.2 Serviço de Apresentação
Para este módulo são descritos dois exemplos de funcionamento do Serviço de
Apresentação, que representam as duas principais situações de interacção com o
utilizador.
Para a primeira situação, ilustrada pela Figura 5.9, acompanha-se o pedido de
visualização de uma das páginas Web disponibilizadas pelo Serviço de Apresentação
(e.g., Project Master List, vista agregada). Este processo é iniciado com essa mesma
solicitação por parte do utilizador a partir de um browser Web ao aceder ao endereço
respectivo. Essa solicitação gera o carregamento da página e produz uma chamada ao
método PageLoad() da Interface IShowPageData, que é responsável por processar e
requerer a informação necessária à base de dados ou aos módulos de criação de
informação gráfica, e por a retornar ao utilizador sob a forma de página Web. Deve
portanto consolidar as diferentes informações para as apresentar sob texto, tabelas,
listagens, gráficos, gauges ou outros elementos visuais. Neste exemplo perspectiva-se
precisamente uma chamada à base de dados, um pedido de criação de um gráfico e um
pedido de criação de um indicador de tendência.
47
Figura 5.9: Diagrama de funcionamento do Serviço de Apresentação (apresentação de
página)
No segundo caso, ilustrado na Figura 5.10, demonstram-se as operações de gestão
de comentários por parte do utilizador. Primeiramente é solicitada a apresentação de
todos os comentários relativos à página onde o utilizador se encontra. Este pedido é
realizado mais uma vez recorrendo à Interface IShowPageData através do método
ShowComments(). Este método desencadeia uma operação de processamento por parte
do módulo principal que, já tendo essas informações em memória (decorrentes do
carregamento da página), apenas tem que os apresentar na mesma ou numa nova página
Web, recorrendo por exemplo a potencialidades do JavaScript. Segue-se um pedido de
escrita de um comentário pelo próprio utilizador, que mais uma vez desencadeia uma
operação de processamento pela classe PresentationService para que o texto do
comentário, juntamente com a data e hora da sua realização e com o nome do autor, seja
armazenado na BDC, passando a estar disponível a todos os utilizadores sempre que
consultarem os comentários do mesmo item.
48
Figura 5.10: Diagrama de funcionamento do Serviço de Apresentação (gestão de comentários)
5.2 Arquitectura dos Dados
A quantidade de dados armazenados sofrerá um crescimento constante e periódico,
causado pela recolha sistemática dos dados dos projectos. Assim sendo, no caso de o
projecto já existir antes de ser contemplado no sistema, terá que ser efectuado um
carregamento inicial com as informações já existentes em sistemas externos. Espera-se,
pois, que a dimensão da base de dados seja proporcional ao número de projectos
incluídos no sistema. Desta forma, funcionando como ponto intermédio entre os dois
principais módulos do sistema, a base de dados assume um papel preponderante, sendo
crucial a sua correcta definição e arquitectura.
5.2.1 Especificação da Informação
5.2.1.1 Modelo Conceptual de Dados
A BDC deve contemplar todas as informações relevantes relativas aos projectos,
armazenando-as de uma forma consolidada, permitindo um fácil armazenamento por
parte do Serviço de Actualização e um fácil acesso por parte do Serviço de
Apresentação. Desta forma, compreende-se desde logo uma orientação à entidade
Projecto, sendo a classe central da informação. Com efeito, todas as informações são
relativas a um determinado projecto, directa ou indirectamente.
49
Figura 5.11: Modelo Conceptual de Dados
50
Assim sendo, é perceptível que um projecto contém informações fixas (códigos,
âmbitos, entre outros), informações que são relativas a evoluções de determinadas áreas
(datas de fecho, horas de esforço, dados financeiros, entre outros) e informações que
não são mais do que conjuntos de itens que deverão estar agrupados (milestones,
problemas, riscos, entre outros). Nesse sentido, o Esquema Conceptual apresentado na
Figura 5.11 traduz essas mesmas relações, denotando uma classe central -Projectos- que
interliga as restantes.
5.2.1.2 Descrição das Classes
Tendo em conta o Esquema Conceptual apresentado, compreende-se que existem
diversas classes no sistema a nível de dados, sendo que umas desempenham um papel
mais central do que outras. Desta forma, torna-se necessária a compreensão de cada
uma destas classes, tendo em vista a percepção dos dados considerados como um todo e
o entendimento das ligações que as relacionam. Nesse sentido, será descrita cada uma
delas, dando especial ênfase aos Sistemas Externos e às principais perspectivas
afectadas.
Projectos – armazena informações de administração dos projectos. Esta
classe relaciona-se com todas as outras que todas são “listagens” de itens
relativos a um projecto.
o Sistemas Externos implicados: EPM, unicamente para o código em
EPM do projecto. Todas as restantes. informações são provenientes
da introdução manual.
o Perspectivas afectadas: Perspectiva Administração.
Utilizadores – guarda todos os utilizadores que podem aceder ao sistema,
bem como o seu tipo para controlo de acessos.
o Sistemas Externos implicados: -
o Perspectivas afectadas: Todas.
Comentários – guarda todos os comentários efectuados às diferentes
perspectivas ou projectos, juntamente com a data e hora da sua realização e
o seu autor.
o Sistemas Externos implicados: -
o Perspectivas afectadas: Todas.
o
Listagens – representa uma classe que generaliza nas várias listagens que
um projecto pode ter.
o Sistemas Externos implicados. Todos.
o Perspectivas afectadas: Todas.
Dados – agrega todos os atributos relativos ao projecto e que são (99% das
vezes) fixos.
51
o Sistemas Externos implicados: EPM.
o Perspectivas afectadas: Project Master List, Perspectiva Geral.
Milestones – contém uma listagem de todas as milestones relativas ao
projecto, que podem ser alteradas ao longo do tempo.
o Sistemas Externos implicados: EPM.
o Perspectivas afectadas: Perspectiva Plano.
Problemas – contém uma listagem de todos os problemas relativos ao
projecto, que vão sendo abertos e fechados, guardando-se sempre o
histórico para análise de evolução.
o Sistemas Externos implicados: Sharepoint.
o Perspectivas afectadas: Perspectiva Problemas.
Defeitos – semelhante à classe Problemas, mas indo de encontro com
defeitos encontrados por ferramentas bug tracking.
o Sistemas Externos implicados: Ferramenta bug tracking.
o Perspectivas afectadas: Perspectiva Defeitos.
Avaliacoes – contém informações recolhidas a partir de um inquérito
interno, efectuado pelos colaboradores do projecto e relativas às várias
áreas do projecto.
o Sistemas Externos implicados: Sharepoint.
o Perspectivas afectadas: Perspectiva Recursos.
Riscos – contém uma listagem de todos os riscos que podem afectar o
projecto.
o Sistemas Externos implicados: Sharepoint.
o Perspectivas afectadas: Perspectiva Riscos.
ActionItems – contém uma listagem dos action items relativos ao projecto,
guardando-se o histórico para efeitos estatísticos. De realçar que um action
item pode depender de outros action items.
o Sistemas Externos implicados: Sharepoint.
o Perspectivas afectadas: Perspectiva Stakeholders.
ChangeRequests – semelhante à classe action items, mas guardando as
informações relativas aos pedidos de alteração de determinadas partes do
projecto.
52
o Sistemas Externos implicados: Sharepoint.
o Perspectivas afectadas: Perspectiva Stakeholders.
ProgressosTemporais – contém informações que serão úteis para a criação
de gráficos de evolução do projecto, demonstrado a sua progressão ao longo
do tempo, nomeadamente ao nível de planeamentos de datas, de horas e do
trabalho já efectuado.
o Sistemas Externos implicados: EPM.
o Perspectivas afectadas: Project Master List, Perspectiva Geral,
Perspectiva Recursos.
ProgressosFinanceiros – semelhante à classe ProgressosTemporais, mas
relativa a informações no âmbito de gestão financeira.
o Sistemas Externos implicados: EPM.
o Perspectivas afectadas: Perspectiva Financeira.
5.2.2 Especificação da Base de Dados
5.2.2.1 Esquema Relacional de Dados
A partir do Modelo Conceptual de Dados é possível efectuar uma normalização
para obter um esquema mais físico, que irá ser o modelo implementado directamente na
BDC– Modelo Relacional. Neste modelo as entidades deixam de ser classes e passam a
ser tabelas. As restantes características da passagem para este modelo residem
fundamentalmente em 4 alterações principais:
Inclusão de chaves primárias – todas as tabelas passam a ter um código
interno (cod), gerado automaticamente pelo SGBD sempre que uma nova
linha é inserida, que funciona como identificador único de cada tuplo da
tabela. Esta chave é um inteiro para optimizar o processo de ligação entre as
tabelas.
Inclusão de chaves estrangeiras – para o mapeamento das relações um-para-
muitos, é necessário incluir a chave primária da tabela “um” na tabela
“muitos”. Assim, em todas as classes participantes neste tipo de relações foi
efectuado este mapeamento, sendo que a chave estrangeira contém sempre
o sufixo da tabela proveniente.
Mapeamento da generalização – a generalização da classe Listagens para
todas as outras foi mapeada segundo um tipo de generalização que apenas
conserva as classes filhas. Assim, a tabela Listagens não existe, passando
todas as tabelas filhas a herdar os seus atributos e relações.
Mapeamento da relação recursiva – a relação recursiva existente na classe
ActionItems é uma relação muitos-para-muitos e, portanto, o seu
mapeamento envolve a criação de uma nova tabela
(ActionItemsDependencias). Assim pode ser efectuada a relação directa
entre cada AcionItem e os seus dependentes.
53
Figura 5.12: Esquema Relacional de Dados
5.3 Serviço de Actualização
O Serviço de Actualização tem como objectivo fundamental a recolha periódica de
dados de projectos, a partir de diferentes sistemas utilizados na gestão de projectos.
Tendo isto em conta, é perceptível que não existe uma camada de apresentação na sua
arquitectura, já que também não existe interacção (directa) com os utilizadores.
54
Deste modo, será descrito, nesta secção, o modo de implementação seguido para
este módulo, considerando a especificação funcional efectuada na secção anterior,
detalhando os principais pormenores de implementação e as principais justificações de
decisões tomadas.
5.3.1 Camada de Dados
Quando o Serviço de Actualização inicia, com a execução do seu método interno
OnStart(), o primeiro passo é a inicialização das suas listas, quer com os Sistemas
Externos, quer com os projectos:
private List<IExternalSystems> externalSystems;
private List<String> projects;
A lista de Sistemas Externos é inicializada programaticamente, consoante as
classes que se encontrem implementadas no sistema. No entanto, a lista de projectos é
inicializada com recurso a uma chamada à base de dados, que devolve todos os
projectos que deverão ser actualizados. Isto acontece porque os projectos a actualizar
deverão ser especificados pelo utilizador na página de administração do Serviço de
Apresentação, especificando igualmente um atributo booleano que indica se o projecto
deverá ou não ser actualizado. Assim, no início de cada execução é efectuada uma
chamada ao método GetUpdateList(), da classe PTSIPortfolioDataBase, que por sua
vez efectua uma chamada ao stored procedure getUpdateList(). Este procedimento
retorna todos os projectos existentes na tabela Projectos e que possuem o atributo
actualizável definido a true. Estas linhas retornadas são interpretadas iterativamente por
um DataReader que as adiciona à lista de projectos.
Com esta lista totalmente preenchida, o segundo passo consiste em chamar, para
cada Sistema Externo existente na lista, o seu método Update(). Como cada um dos
Sistemas Externos são representados por um classe que implementa a Interface
IExternalSystems, este método pode ser chamado directamente da lista, conferindo ao
sistema a sua desejada arquitectura versátil.
//Acesses the External Systems to get the project's data
//and stores it in the database
foreach (IExternalSystems externalSystem in externalSystems)
externalSystem.Update(projects);
A partir deste ponto, o funcionamento desta aplicação passa a ser exclusivo para
cada Sistema Externo. Assim, em cada um deles, é efectuada uma chamada ao Web
Service respectivo e armazenadas na BDC as informações retornadas. Para este
armazenamento cada classe de Sistema Externo possui um DataSet, que contém as
tabelas com que irá interagir. Deste modo, com a utilização de DataSets, a inserção dos
dados torna-se muito mais fácil e rápida, sem necessidade de definição de stored
procedures ou de comandos SQL. Apenas é necessário criar uma instância desse
DataSet na tabela que se pretende usar no momento (TableAdapter), e seleccionar o
comando desejado (neste caso, comando Insert), tal como demonstrado no seguinte
trecho de código:
55
//Updates table ProgressosTemporais with new data
EPMDataSetTableAdapters.ProgressosTemporaisTableAdapter().Insert(
dr["dataInicio"],
dr["dataInicioBaseline"],
dr["dataFim"],
dr["dataFimBaseline"],
dr["horasPlaneadas"],
dr["horasEfectuadas"],
dr["cpi"],
dr["spi"],
dr["trabalhoConcluido"],
dr["estado"],
DateTime.Now,
actualProject
);
Figura 5.13: DataSet para EPM, com as tabelas necessárias para armazenamento
Os dados retornados pelos Web Service encontram-se num formato DataSet, já de
acordo com a estrutura das tabelas a inserir. Assim, por exemplo, para o EPM, que irá
armazenar dados em cinco tabelas, o DataSet retornado possui cinco tabelas, cada uma
com nome e ordem de atributos exactamente igual à tabela respectiva na BDC. Isto
permite que o DataSet retornado seja armazenado directamente nas tabelas desejadas,
sem qualquer necessidade de processamento. Os únicos trechos de processamento
existentes são utilizados para o cálculo de tendências ou de indicadores visuais, mas
também com o intuito de os inserir na BDC.
5.3.2 Camada de Lógica de Negócio
A partir do momento em que as listas do Serviço de Actualização se encontram
inicializadas, a execução do programa passa a ser efectuada em cada uma das classes
56
que representam os Sistemas Externos. Isto acontece devido à chamada ao método
Update(), definido em cada uma dessas classes. No entanto, este método é derivado da
Interface IExternaSystem, pelo que é nesta que se encontra declarado:
/// <summary>
/// This method must be implemented on the IExternalSystems
/// implementations.
/// Gets the information of the "projects" throughout its
/// WebService and stores it in the database.
/// </summary>
/// <param name="codEPM"></param>
void Update(List<String> projects);
,sendo que cada classe que a implemente deverá possuir na sua declaração a referência a
esta Interface.
/// <summary>
/// Class that implements access to the EPM External System
/// </summary>
class EPM : IExternalSystems{...}
Quando o método Update() é chamado, inicia-se um ciclo, com um número de
iterações igual ao número de projectos, em que são retornadas as informações dos
Sistemas Externos através dos respectivos Web Services e estas são armazenadas na
BDC.
//Gets data form ExternalSystem EPM
foreach (String codProject in projects)
{
//Gets the actual codProject
actualProject = int.Parse(codProject);
//Calls the WebService and gets the DataSet with the EPM data
ds = EPMws.ProjectoEPM(codProject);
//Inserts data in the database
InsertData(ds);
}
57
Figura 5.14: Funcionamento geral do Serviço de Actualização
Compreende-se pela interpretação do trecho acima apresentado que o DataSet
retornado pela chamada ao Web Service é directamente utilizado pelo método
InsertData(), que trata de distribuir cada tabela do DataSet pelas várias funções de
inserção na BDC.
//Inserts data in the database
private void InsertData(DataSet ds)
{
//Inserts data Dados
InsertDados(ds.Tables["Dados"]);
//Inserts data ProgressosTemporais
InsertProgressosTemporais(ds.Tables["ProgressosTemporais"]);
//Inserts data ProgressosFinanceiros
InsertProgressosFinanceiros(ds.Tables["ProgressosFinanceiros"]);
//Inserts data Milestones
InsertMilestones(ds.Tables["Milestones"]);
//Inserts data Tendencias
InsertTendencias(ds.Tables["ProgressosTemporais"]);
}
5.4 Serviço de Apresentação
O Serviço de Apresentação visa a exposição da informação armazenada na BDC
pelo Serviço de Actualização, de uma forma consolidada, intuitiva e fácil de
compreender para os GP. Assim, ao contrário do que acontece com o Serviço de
Actualização, este módulo possui uma camada de dados, sendo esta inclusivamente a
principal camada da sua arquitectura. Desta forma, e à semelhança da secção anterior,
58
nesta secção será descrito o modo de implementação seguido para este módulo,
considerando mais uma vez a especificação funcional, e detalhando os principais
pormenores de implementação e as principais justificações de decisões tomadas.
5.4.1 Camada de Dados
Sendo uma aplicação para apresentação dados, é perceptível desde logo que, a nível
de dados, as principais operações realização serão de retrieve de dados. Com efeito,
95% das operações realizadas por esta aplicação são de recuperação de informação,
sendo que as únicas excepções são a perspectiva de administração, que permite uma
alteração de atributos dos projectos a nível de especificação de classe, visibilidade e
taxonomia, e a escrita de comentários. Com estas modificações por parte do utilizador,
ou mesmo com a inserção de novos projectos para actualização, é necessária a inserção
de dados na BDC.
Para a recuperação da informação são utilizados stored procedures. Existe um
stored procedure para cada perspectiva, sendo que sempre que uma página é
apresentada, é feito um request à base de dados, com o stored procedure respectivo, que
devolve logo todas as informações necessárias para visualização da página. Isto garante
que todos os dados passíveis de serem vistos na perspectiva estão desde logo
disponíveis em memória, dando tempo de acção a operações de visualização e ocultação
de dados (e.g. com a utilização de JavaScript) sem necessidade de interacção com a
base de dados. Todos estes stored procedures são geridos através da classe
PTSIPortfolioDataBase, sendo a sua principal função precisamente a mediação entre as
páginas Web e a base de dados.
/// <summary>
/// Returns a dataset with the view
/// </summary>
/// <returns></returns>
public static DataSet GetDataPML_Agregada()
public static DataSet GetDataPML_Plano()
public static DataSet GetDataPML_Financeira()
public static DataSet GetDataGeral(int codProject)
public static DataSet GetDataFinanceira(int codProject)
public static DataSet GetDataPlano(int codProject)
public static DataSet GetDataProblemas(int codProject)
public static DataSet GetDataDefeitos(int codProject)
public static DataSet GetDataStakeholders(int codProject)
public static DataSet GetDataRecursos(int codProject)
public static DataSet GetDataRiscos(int codProject)
public static DataSet GetDataAdm()
Pela interpretação do trecho apresentado acima compreende-se que todas as
perspectivas específicas de um projecto recebem o código do respectivo projecto,
enquanto a PML e a perspectiva de administração são genéricas e apresentam as
informações para todos os projectos na base de dados. Compreende-se igualmente que
todos estes métodos retornam DataSets. Mais uma vez foi escolhido este modo de
abstracção de informação, por um lado pela integração que oferece com o retorno da
base de dados (em que apenas é necessário efectuar um cast à informação proveniente
da base de dados para a passar para o DataSet) e por outro lado por ser uma estrutura
fácil de aceder e iterar, possibilitando uma filtragem rápida para as diferentes formas de
visualização dos dados. Os DataSets retornados para cada perspectiva contêm, regra
59
geral, mais do que uma tabela, já que praticamente todas as perspectivas permitem a
visualização de mais do que um conjunto de dados. Dessa forma, apenas é necessária a
selecção da tabela correspondente a um conjunto de dados e o respectivo bind da
informação à estrutura utilizada para apresentação desses dados.
Para a inserção de dados, e um pouco à semelhança do que acontece no Serviço de
Actualização, foi escolhida a utilização de DataSets em detrimento dos stored
procedures. Isto porque apenas se efectuam dois tipos de inserções:
definição de um novo projecto no sistema, com a especificação do seu
nome e código interno;
alteração dos campos de administração de um projecto, como o atributo
actualizavel, e a especificação da classe, da visibilidade e da taxonomia de
um projecto já existente no sistema.
Assim, por exemplo no segundo tipo, apenas é necessário criar uma nova instância
do TableAdapter respectivo e seleccionar o comando de Update, passando a linha do
DataSet com a informação.
//Updates database with new data for the project
new DataBaseAccess.PTSIPortfolioDataSet-
TableAdapters.ProjectosTableAdapter().Update(dt.Rows[e.RowIndex]);
5.4.2 Camada de Lógica de Negócio
No Serviço de Apresentação a camada intermédia, que representa a lógica de
negócio, e tal como foi demonstrado na arquitectura desta aplicação, serve como
mediadora entre a camada de dados e a camada de apresentação. Isto significa que esta é
a camada de processamento e consolidação da informação, pegando na informação que
é retornada da BDC sob a forma de DataSets, interpretando-a e processando-a de forma
a estabelecer a sua organização, para que esta possa ser correctamente atribuída a
estruturas de apresentação de informação.
As principais funções desta camada passam por:
calcular valores de tendências, interpretando se estão a aumentar ou a
diminuir, com base nos dados retornados da BDC;
calcular valores de indicadores visuais (semáforos), com base em
parâmetros pré-estabelecidos, interpretando se são maiores, menores ou
iguais do que os valores retornados pela BDC;
gerar gráficos de vários tipos (pontos, linhas, colunas, áreas, radar,
circular), com base num conjunto de valores retornados pela BDC;
gerar gauges de vários tipos (linear, circular), com base num conjunto de
valores retornados pela BDC;
permitir a gestão de comentários, por parte do utilizador;
suportar tarefas de administração de projectos, por parte do utilizador.
Deste modo, é perceptível que toda a informação apresentada pela camada superior
é pré-processada por esta camada, confirmando a sua validade e a sua consistência com
outros dados da mesma perspectiva. Por esta razão, a classe AuxiliaryMethods
desempenha um papel preponderante neste pré-processamento, já que possui a maior
60
parte dos métodos utilizados para tal. Também possui outros métodos para cálculos
auxiliares e para funções genéricas utilizadas por mais do que uma perspectiva.
5.4.3 Camada de Apresentação
A camada de apresentação deste serviço representa a principal camada da sua
arquitectura, sendo o ponto central de interacção com o utilizador através da
apresentação da informação. No contexto do projecto como um todo, esta camada
representa o culminar de todo um trabalho conjunto de várias partes, módulos e
componentes que recolheram e trataram informação do modo mais adequado possível
para que esta pudesse ser apresentada correctamente neste ponto.
Compreende-se então a importância que esta camada possui para o projecto e para
o utilizador, pelo que a sua integração com as outras camadas é preponderante, ao
mesmo tempo que deve privilegiar valores como a simplicidade, clareza e exactidão da
informação apresentada.
Tal como definido na arquitectura, esta camada é composta por várias classes de
apresentação (páginas Web), que derivam da Interface IShowPageData. Cada uma
destas classes representa uma perspectiva, existindo por isso 10 páginas Web diferentes:
Project Master List;
Perspectiva Geral;
Perspectiva Financeira;
Perspectiva Plano;
Perspectiva Problemas;
Perspectiva Defeitos;
Perspectiva Stakeholders;
Perspectiva Recursos;
Perspectiva Riscos;
Perspectiva Administração.
Para criar a componente visualmente atractiva, foi desenvolvida e aplicada uma
style sheet, que confere à aplicação Web um aspecto em tudo semelhante ao site do
departamento de gestão de projectos.
Figura 5.15: Logótipo do PMO - PTSIPortfolio
Um dos pontos cruciais em qualquer tipo de aplicação Web, que não se torna
excepção neste projecto, é a navegação entre páginas. Para tal, foi criado um menu, que
aparece numa posição fixa, na parte esquerda da página e por baixo do logótipo, que se
adequa à página que está a ser visualizada, proporcionando as opções de navegação
possíveis a partir dessa página (Figura 5.16).
61
Figura 5.16: Menus de navegação – a partir de uma perspectiva de projecto (esquerda), a
partir da PML (centro) e a partir da Administração (direita)
Denota-se portanto que existem 3 tipos de menus diferentes, de acordo com a
página que se encontra a ser visualizada. O primeiro é o menu disponibilizado quando
se encontra numa qualquer perspectiva específica de um projecto. Este menu permite o
retorno à Project Master List ou a navegação entre as várias perspectivas para o mesmo
projecto. O segundo menu é disponibilizado ao visualizar a PML, em qualquer uma das
vistas. Como é perceptível, este menu permite a navegação entre as três vistas da PML,
apresentando sempre todos os projectos existentes no sistema. Este menu também
permite a passagem à perspectiva de administração, também relativa a todos os
projectos. O terceiro menu representa precisamente a perspectiva de administração, em
que se compreende que a única opção de navegação é o retorno à PML.
Com tudo isto é possível perspectivar a aparência geral de cada página Web, que
segue sempre as mesmas regras de organização e disposição dos elementos, com o
logótipo da página no topo, o menu no lado esquerdo e o conteúdo principal da página a
ocupar uma posição central (Figura 5.17).
62
Figura 5.17: Página inicial da aplicação Web (PML – Vista Agregada)
Por motivos de confidencialidade interna dos projectos, os dados apresentados nas
várias páginas possuem um carácter meramente elucidativo, sendo puramente fictícios e
aleatórios, não reflectindo portanto qualquer tipo de ligação com a realidade dos
projectos da PT-SI.
Assim, nesta primeira perspectiva, para a PML na vista Agregada, são perceptíveis
dois subconjuntos de dados. O primeiro é a PML em si, expondo os dados mais gerais
(âmbito, pessoas responsáveis, estado actual) de todos os projectos de uma forma
resumida e tabular. O segundo conjunto de dados representa indicadores visuais, com a
apresentação de dois gráficos, um de pontos, e outro de colunas, que demonstram
respectivamente a taxonomia e o índice de visibilidade dos projectos existentes no
sistema2.
Em relação às outras duas vistas da PML, Plano e Financeira, a essência de
conteúdo é a mesma, apresentando uma tabela para todos os projectos com as
informações específicas de cada vista, apesar de nenhuma destas possuir gráficos.
Assim sendo, na vista Plano (Figura 5.18) são apresentados dados relacionados com a
evolução do planeamento do projecto, como as datas actuais e baseline ou o índice SPI,
enquanto na vista Financeira (Figura 5.19) são apresentadas informações relativas ao
estado económico do projecto, como a tendência das várias rentabilidades e o índice
CPI.
2 A inconsistência entre o número de projectos apresentados na tabela e nos gráficos é propositada, servindo mais uma vez para fins meramente ilustrativos das
funcionalidades desenvolvidas.
63
Figura 5.18: PML – Vista Plano
Figura 5.19: PML – Vista Financeira
Os indicadores visuais presentes na PML passam principalmente por:
indicadores de tendência, que podem apresentar um seta para cima a verde
(se melhorou), uma seta vermelha para baixo (se piorou) ou um igual (se
manteve o valor);
semáforos, que podem ser verdes se o valor se encontram num domínio
aceitável, amarelos se o valor se encontra num domínio preocupante e
vermelho se o valor se encontra num domínio impróprios. Estes domínios
de valores são pré-estabelecidos e variam de semáforo para semáforo.
A partir da tabela de cada uma destas vistas da PML, é possível visualizar os vários
projectos existentes no sistema. No entanto esta lista apresenta mais vantagens, como a
possibilidade de ordenação dos projectos por um qualquer atributo bastando para tal
clicar no atributo respectivo que se encontra no header da tabela. Ao passar o ponteiro
do rato por cima desse atributo, o cursor muda para uma mão e o nome do atributo
passa a ter a formatação de uma hiperligação, indicando possibilidade de selecção
(Figura 5.20). A implementação dos métodos de ordenação da lista surgiu de um misto
de funções realizadas de raiz e de outras retiradas do site da Microsoft MSDN
[MIC091], já que a ordenação suportada pela .Net Framework não seria a mais
adequada.
Outra grande vantagem desta PML é a possibilidade de selecção directa de um
projecto, bastando apenas clicar na linha respectiva do projecto. Tal como acontece com
a ordenação, ao passar o ponteiro por um projecto o cursor muda para um mão e a linha
em questão muda de cor, indicando mais uma vez a possibilidade de selecção (Figura
5.21).
Figura 5.20: Ordenação da PML por atributos
64
Figura 5.21: Selecção de um projecto a partir da PML
Após o clique num qualquer projecto, o utilizador é automaticamente
redireccionado para as perspectivas específicas do projecto, sendo normalmente a
perspectiva Geral a primeira a ser apresentada já que, como o próprio nome indica,
apresenta informações gerais do projecto (do mesmo modo que a vista Agregada, mas a
um nível mais aprofundado). Esta perspectiva não possui gráficos nem valores
específicos, e ao contrário da PML que tem como objectivo chamar a atenção dos GP
para os projectos mais problemáticos, a perspectiva Geral pretende chamar a sua
atenção para as áreas mais problemáticas de um projecto. Nesse sentido para além das
informações gerais do projecto (Figura 5.22), esta perspectiva apresenta ainda gauges
circulares, sob a forma de velocímetros, referentes às várias perspectivas existentes
(Figura 5.23). Nestes velocímetros é possível visualizar um estado geral de cada uma
das áreas do projecto (milestones, plano, finanças, problemas, defeitos, stakeholders,
recursos e riscos) apresentando o resultado de cálculos pré-definidos que representam
valores médios de cada uma, e a sua evolução comparativamente com o último valor
calculado.
Figura 5.22: Perspectiva Geral – Informação geral do projecto
65
Figura 5.23: Perspectiva Geral – Velocímetros das várias perspectivas
Utilizando o menu do lado esquerdo é possível mudar de perspectiva. Passando
para a perspectiva Financeira (Figura 5.24), esta apresenta um conjunto de informações
bastante semelhante aos relatórios de projecto, começando pela informação gráfica, da
qual consta um gráfico radar para a análise integrada de objectivos (progresso, tempo e
custo) e um gráfico de pontos para o cumprimento de prazos e orçamentos (com os
índices CPI e SPI). A nível textual são apresentados os valores de custos, esforços e
rentabilidades referentes à Ficha de Rentabilidade, à Última Baseline, ao Plano Actual,
ao Plano Realizado e ao Plano Realizado SAP.
Figura 5.24: Perspectiva Financeira
No que toca à perspectiva Plano, são apresentadas as principais milestones do
projecto, sob a forma de uma tabela, conjuntamente com indicadores visuais do desvio
entre a data de conclusão prevista inicialmente e a e a data de conclusão prevista
actualmente, como apresentado na Figura 5.25. Para além destas informações, são ainda
apresentados dois gráficos de linhas, que demonstram a evolução da data de fim (actual
66
e planeada) e a evolução do progresso (efectuado e planeado) do projecto ao longo do
tempo.
Figura 5.25: Perspectiva Plano – Milestones do projecto
Figura 5.26: Perspectiva Plano – Evolução da Data Fim e do Progresso do projecto
Nas perspectivas Problemas e Defeitos, devido à sua semelhança de âmbito, os
seus conteúdos são totalmente semelhantes, com a diferença de no primeiro caso serem
referentes aos problemas reportados pelo GP e no segundo caso serem referentes a
defeitos encontrados por uma ferramenta de bug tracking. Deste modo, em ambas as
perspectivas é apresentada uma tabela com a listagem de todos os itens actualmente
existentes, bem como dados referentes a datas, estados, âmbitos, urgência e estratégias
de mitigação (Figura 5.27). Nestas perspectivas também se podem encontrar
informações estatísticas referentes aos itens encontrados, como a distribuição da
urgência dos itens e a evolução destes ao longo do tempo consoante o seu estado
(Figura 5.28 e Figura 5.29).
67
Figura 5.27: Perspectiva Problemas – lista de problemas
Figura 5.28: Perspectiva Problemas/ Defeitos – Distribuição de itens por urgência
Figura 5.29: Perspectiva Problemas/ Defeitos – Evolução de itens ao longo do tempo
No que respeita à perspectiva Stakeholders, esta apresenta informações sobre dois
tipos de dados diferentes: action items e change requests. Os primeiros, representam
actividades que deverão ser efectuadas no âmbito do projecto, enquanto os segundos
representam pedidos de alterações a serem aplicados ao projecto. Assim, para ambos é
apresentada uma tabela com a listagem dos vários itens e a inclusão dos seus atributos
mais importantes como as datas e os responsáveis (Figura 5.30 e Figura 5.32). Para os
action items são ainda apresentados três gráficos circulares que indicam a quantidade de
itens por estado e por tipo de responsável (Figura 5.31), enquanto para os change
requests é apresentado um gráfico de linhas que demonstra a evolução do estado destes
(abertos, fechados, em desenvolvimento, com e sem atraso) ao longo do tempo (Figura
5.33).
68
Figura 5.30: Perspectiva Stakeholders – Action Items do projecto
Figura 5.31: Perspectiva Stakeholders – Action Items por estado e responsável
Figura 5.32: Perspectiva Stakeholders – Change Requests do projecto
69
Figura 5.33: Perspectiva Stakeholders – Evolução do estado dos Change Requests ao longo do tempo
Na perspectiva Recursos, os grupos de dados são referentes ao controlo do staffing
e do índice de risco avaliado pela equipa de desenvolvimento do projecto (). Deste
modo, em relação ao controlo de horas gastas no projecto, esta perspectiva apresenta um
gráfico de linhas com a evolução das horas planeadas e efectivamente gastas no projecto
ao longo do tempo. Para a avaliação do índice de risco, é apresentada uma tabela que
representa a evolução da média da avaliação feita pela equipa em relação às várias áreas
(possivelmente mais susceptíveis a problemas) do projecto.
Figura 5.34: Perspectiva Recursos – Staffing e avaliação do índice de risco pela equipa
Finalmente, na perspectiva Riscos, como em todas as outras perspectivas que visam
a gestão de vários itens, esta também contém uma tabela com os vários riscos
70
identificados pelo GP e os seus atributos mais importantes como as consequências, o
impacto que teria, as possibilidades de ocorrer e as possíveis estratégias para a
prevenção (Figura 5.35). A nível de informação gráfica são apresentados dois gráficos,
sendo que um demonstra a distribuição dos riscos numa matriz que cruza a sua
probabilidade e o seu impacto, enquanto o outro apresenta a evolução do número de
riscos (em cada tipo de probabilidade de exposição) ao longo do tempo, com é
perceptível na Figura 5.36.
Figura 5.35: Perspectiva Riscos – Riscos do projecto
Figura 5.36: Perspectiva Riscos – Distribuição de riscos na matriz PxI e evolução destes ao
longo do tempo
Se a partir da PML se seleccionar a página de administração, é possível
perspectivar uma lista dos projectos existentes no sistema, com os seus atributos de
administração, como a classe, visibilidade, taxonomia, entre outros (Figura 5.37). Nesta
lista, a primeira coluna não apresenta atributos dos projectos, mas sim uma
funcionalidade de edição desses atributos. Deste modo, para a modificação desses
atributos, o utilizador apenas necessita de clicar na respectiva hiperligação Edit e a linha
correspondente passa a estar editável (Figura 5.38). A parir desse momento é possível
editar as text e as check boxes, consoante o caso, sendo também possível cancelar a
operação (Cancel) ou confirmá-la (Update).
71
Figura 5.37: Perspectiva Administração – Listagem dos projectos
Figura 5.38: Perspectiva Administração – Edição da classe de um projecto
5.5 Resumos e Conclusões
Este capítulo centrou-se na implementação do PTSIPortfolio, abordando as várias
vertentes desta fase.
Assim, primeiramente é enquadrada a especificação da arquitectura do sistema,
segundo uma visão geral, conceptual, estática e dinâmica. Na arquitectura geral e
conceptual do sistema percepciona-se a existência de três principais módulos no
sistema:
o Serviço de Actualização, que ostenta uma integração com os Sistemas
Externos através da tecnologia Web Services, e cujo modo de
funcionamento passa por uma chamada perdiódica a estes Web Services,
pela recolha e processamento dos dados retornados e pelo seu
armazenamento na BDC;
o Serviço de Apresentação, que representa o ponto de interacção com o
utilizador, e cujo funcionamento passa pelo acesso aos dados armazenados
pelo Serviço de Actualização, pela sua consolidação e processamento e pela
sua apresentação sob a forma de páginas Web ao utilizador, utilizando
informações textuais, gráficas e indicadores visuais.
Na visão estática arquitectura são referidos os principais componentes de cada módulo,
realçando o modo como se relacionam e sempre tendo em conta os principais propósitos
do sistema como um todo. Assim, a arquitectura do Serviço de Actualização apresenta
como principal característica a sua escalabilidade, permitindo uma fácil adição de novos
Sistemas Externos, sem qualquer necessidade de alteração do que já se encontra
implementado. Esta escalabilidade foi conseguida através do uso de Interfaces, que
abstraem o conceito de classe, permitindo conjugar os vários Sistemas Externos como
se fossem todos objectos do mesmo tipo. Na visão estática da arquitectura do Serviço de
Apresentação percebe-se uma orientação a aplicação Web, com a utilização de
componentes que auxiliam a lógica de negócio e o acesso a dados. A visão dinâmica do
sistema inclui exemplos de funcionamento dos dois módulos, oferecendo uma visão dos
aspectos mais importantes em cada ciclo de execução.
72
Seguidamente foi tratada a implementação propriamente dita, abordando cada um
dos módulos do sistema individualmente e destacando os principais detalhes de
implementação e as principais decisões tecnológicas em cada um. O modo de
abordagem dos sistemas seguiu uma análise por camadas, dando a perceber como cada
camada foi implementada e se relacionava com as suas adjacentes. No final deste
capítulo foram apresentados vários screen shots que evidenciam o aspecto gráfico do
Serviço de Apresentação, ressalvando a sua navegabilidade e os seus conteúdos
intuitivos, que são sempre complementados com informações visuais gráficas, sejam
elas gráficos ou indicadores visuais como semáforos e indicadores de tendências.
73
6 Testes
Pretende-se com este capítulo definir as condições necessárias à execução dos
testes a realizar ao PTSIPortfolio, definindo, para tal o âmbito dos testes a efectuar, as
actividades a executar e as respectivas condições de execução. Uma especificação mais
completa dos casos de teste, incluindo a especificação de desenhos de testes, encontra-
se passível de consulta no anexo F. Especificação de Desenhos de Teste.
6.1 Âmbito dos Testes
Uma vez que a utilização do produto resultante da implementação deste projecto
implica a utilização de várias máquinas externas (Clientes Web), separadas fisicamente,
os testes ao software irão incidir na sua maioria nas funcionalidades centradas no
servidor (que engloba todo o Sistema PTSIPortfolio), funcionalidades essas muito mais
críticas para o bom funcionamento do sistema. Assim, as funcionalidades que irão ser
testadas de forma mais crítica são as seguintes:
Acesso aos Sistemas Externos;
Recepção de dados;
Processamento de dados;
Armazenamento de dados;
Acesso a dados;
Disponibilização de dados para operações de consulta;
Disponibilização de dados para operações de actualização.
Para que tal aconteça, irá ser definida a estratégia de teste, que descreve o nível e o
critério de teste a ser utilizado. O nível de teste está intrinsecamente ligado à fase de
desenvolvimento do software em que o teste será aplicado bem como as tecnologias e
técnicas usadas.
74
6.2 Estratégia de Testes
Dado o âmbito e a complexidade do sistema, serão executados quatro tipos de
testes, com critérios, ambientes e responsáveis de execução específicos: testes Unitários,
de Integração, de Sistema e de Aceitação.
6.2.1 Teste Unitário
O Teste Unitário deverá ser efectuado para todos os programas aplicacionais que
compõem o sistema, sejam eles gerados automaticamente ou construídos. Devem ser
especificados os tipos de validação a efectuar em cada programa, a identificação e
definição dos casos de teste unitários e identificados os registos das execuções dos casos
de teste e das anomalias.
6.2.2 Teste Integração
O Teste Integração deverá ser efectuado para todos os interfaces dos programas
aplicacionais que compõem o sistema, sejam eles gerados automaticamente ou
construídos. Devem ser especificados os tipos de validação a efectuar em cada interface,
a identificação e definição dos casos de teste e identificados os registos das execuções
dos casos de teste e das anomalias.
6.2.3 Teste de Sistema
Os Testes de Sistema deverão ser realizados num ambiente com uma caracterização
técnica semelhante à do ambiente de produção, designadamente no que diz respeito à
BDC, que deverá ser diferente daquela que foi utilizada para desenvolvimento,
contendo o volume de informação necessário para a execução dos Testes. Estes deverão
incidir sobre todas as vertentes definidas no âmbito de testes (secção anterior)
cumprindo os respectivos casos de teste associados.
6.2.4 Teste de Aceitação
A execução dos Testes de Aceitação deverá ser da responsabilidade do cliente. No
entanto, quem quer que os realize, estes deverão ser realizados num ambiente com uma
caracterização técnica semelhante à do ambiente de produção. Estes deverão incidir
sobre todas as vertentes definidas no ponto no âmbito de testes (secção anterior)
cumprindo os respectivos casos de teste associados.
6.3 Abordagem
Pretende-se com este processo de testes estabelecer um relacionamento de
confiança e segurança, garantindo no produto cinco características essenciais:
Fiabilidade;
Portabilidade;
Usabilidade;
75
Segurança;
Performance.
Nesta secção define-se a abordagem dos testes ao software, os itens pretendidos e
as funcionalidades a testar. Para efectuar os testes ao produto, irão ser utilizados testes
unitários do tipo caixa preta, testes de integração para testar a inclusão com outros
sistemas, testes de sistemas para verificar o funcionamento geral e testes de aceitação a
realizar pelos clientes. Podemos então dividir os testes em dois módulos diferentes.
Codificação dos módulos do sistema – Teste de Unidade;
Cobertura dos requisitos – Teste de Sistema/Integração;
Tendo em conta estes tipos de testes, estes serão essencialmente vocacionados para
a fase de desenvolvimento. No sentido de dar resposta aos itens de teste, será seguida
uma ordem de tarefas (metodologia) de teste:
Verificação de resposta a requisitos;
Verificação manual de falhas no código fonte;
Realização de testes unitários com cobertura total ao código fonte das
funcionalidades a testar;
Estudo da carga de utilização de recursos lógico/físicos;
Realização de testes de integração com cobertura total ao código fonte das
funcionalidades a testar.
Como forma de dar resposta à metodologia de testes acima definida, deverá ser
usado um conjunto de métodos e ferramentas de testes e qualidade de software o mais
adequado ao tipo de produção em causa. Assim, umas possíveis soluções seriam:
Framework de testes unitários (NUnit);
Framework de análise do grau de cobertura de código fonte (NCover);
Test CheckList;
As duas primeiras frameworks são ferramentas de teste automáticas indicadas para
desenvolvimento com tecnologia .NET C#. A Test Checklist é uma simples lista de
condições que se devem verificar no código ou na aplicação. Neste caso, irão ser
definidas várias Test Checklists ao longo do desenvolvimento do projecto para verificar
que o seu desenvolvimento vai de encontro aos requisitos e arquitectura do produto. Ao
longo do desenvolvimento do mesmo código fonte, este deverá sempre ser revisto antes
de ser testado. Antes da fase de integração, deve proceder-se a duas tarefas:
cobrir o código com uma bateria de testes unitários, que testam a sua
coerência e fiabilidade com o recurso a uma framework com
funcionalidades desse tipo;
efectuar um estudo da carga de utilização de recursos lógico/físicos, isto é,
se o código fonte que se possui explora racionalmente os recursos lógicos e
físicos (CPU, memória, portas e outras infra-estruturas de comunicação,
etc.) que tem à sua disposição.
Após o código estar devidamente validado, deve partir-se para a integração do
produto, que deverá ocorrer sem problemas caso os testes definidos anteriormente
tenham sido eficazes.
76
6.4 Cobertura dos Testes
Para a definição dos itens e das funcionalidades de teste, deve considerar-se como
itens de teste tudo aquilo que é avaliável e mensurável em testes de software. Tendo isto
em conta, para este sistema, são considerados como itens de teste as funcionalidades do
projecto os seguintes:
Exequibilidade - a funcionalidade é executável sem erros e produz
resultados;
Coerência funcional - a funcionalidade executa o que é suposto de acordo
com as especificações;
Coerência de requisitos - a funcionalidade dá resposta aos requisitos da
aplicação;
Eficiência - a execução da funcionalidade utiliza o mínimo de recursos
(lógicos e físicos) que necessita para desempenhar a sua função;
Usabilidade - a funcionalidade é usável pelo grupo de utilizadores tipo do
produto;
Tendo em consideração estes itens de teste, são especificadas as funcionalidades
que deverão ser testadas, bem como uma escala relativa da importância da existência de
testes para essas funcionalidades. Esta escala pode ter três valores, crescentemente num
nível de importância: Baixo, Médio, Alto. A utilização da escala justifica-se caso se
verifique a necessidade de suprir um conjunto de testes à aplicação, devendo ser
supridos aqueles que tiverem menor importância para a qualidade do produto final. As
funcionalidades que deverão ser testadas estão referenciadas na Tabela 6.1.
Tabela 6.1: Especificação dos casos de teste
ID Funcionalidade Descrição da criticidade do teste Nível
ct_001
Chamada aos Web
Services para acesso
aos Sistemas Externos
A base do funcionamento do sistema está
na integridade e actualidade dos seus
dados, pelo que é imprescindível que os
pedidos (requests) aos Web Services sejam
correctamente efectuados.
Alto
ct_002 Processamento dos
dados recebidos
Uma vez efectuada a chamada
aosWebServices é necessário que estes
respondam (response) e que o sistema
saiba interpretar a resposta, através de um
parse da resposta., que podem originar
induções para geração de informações
estatísticas.
Médio
77
ct_003 Armazenamento dos
dados
Se os dados obtidos não forem
correctamente armazenados, toda a
essência de um sistema de consolidação de
informação é perdida.
Alto
ct_004 Acesso aos dados
O Serviço de Apresentação tem como
principal objectivo a disponibilização da
informação ao utilizador, sendo portanto
essencial o acesso aos dados existentes na
BDC.
Alto
ct_005 Apresentação da in-
formação da página
O utilizador deve poder visualizar a
informação proveniente da BDC de uma
forma estruturada e objectiva, de modo a
poder analisar os dados correctamente.
Médio
ct_006 Organização da infor-
mação da página
O utilizador deve poder executar operações
de filtragem ou de ordenação da
informação presente na página em
visualização, de modo a poder melhorar a
sua inteligibilidade.
Baixo
ct_007 Apresentação de in-
formação gráfica
É essencial que as informações mais
complexas (conjuntos de valores ou dados
estatísticos) possam ser apresentadas
graficamente para melhor compreensão por
parte do utilizador.
Médio
ct_008
Gestão de conteúdos
de um projecto ou
perspectiva
Esta é a principal componente do sistema a
nível de interacção com o utilizador no
sentido da edição de dados dos projectos/
perspectivas ou a nível de administração.
Médio
De modo a analisar a cobertura concreta dos testes, foi realizada uma traceability
matrix, que traça a intersecção dos requisitos especificados com os casos de teste
definidos3. Esta matriz encontra-se ilustrada na Tabela 6.2 e evidencia que todos os
requisitos especificados se encontram cobertos pelos casos de teste definidos.
3 A nomenclatura dos casos de uso pode ser consultada no capítulo constante no anexo B. Casos de Uso.
78
Tabela 6.2: Traceability Matrix
ct_001 ct_002 ct_003 ct_004 ct_005 ct_006 ct_007 ct_008 ct_009 ct_010 ct_011
uc_act_001 x x
uc_act_002 x x x x x
uc_pml_001 x x x x x x
uc_pml_002 x
uc_pml_003 x
uc_pml_004 x
uc_pml_005 x x x x x
uc_pml_006 x x x x
uc_per_001 x x x x x x
uc_per_002 x x x x x
uc_per_003 x x x x
uc_adm_001 x x x x
uc_adm_002 x x x x
uc_adm_003 x x x x
uc_adm_004 x x x x
6.5 Realização dos Testes e Resultados Obtidos
Esta especificação dos testes tem como objectivo uma definição precoce dos testes
a desenvolver, implicando uma necessidade de previsão das áreas que poderão vir a ser
as mais problemáticas e que, por isso mesmo, necessitarão de maior grau de atenção.
A metodologia seguida é considerada uma boa prática no desenvolvimento de
software já que evita que a especificação dos testes seja orientada às funcionalidades do
produto desenvolvido, cobrindo à partida mais áreas do projecto, incluindo zonas que
constariam na especificação inicial e que no desenvolvimento propriamente dito não
seriam implementadas rigorosamente de acordo com essa especificação. No entanto,
mesmo com toda esta antecipação para a realização dos testes, na data de entrega e
conclusão deste documento, a 29 de Junho de 2009, ainda não havia sido realizado
qualquer teste, não existindo portanto resultados concretos para demonstrar4.
Os únicos testes e resultados obtidos foram realizados pelo estagiário, ao longo da
implementação, como medida de prevenção e certificação do software em
desenvolvimento. Apesar do seu carácter ad-hoc, estes testes revelaram-se bastante
úteis, tendo permitido até ao momento identificar várias áreas problemáticas e prevenir
situações futuras de erros em determinadas partes do projecto.
6.6 Resumos e Conclusões
Neste capítulo foi descrita toda a metodologia seguida para a especificação dos
casos de teste, com a definição do seu âmbito, estratégia seguida, graus de cobertura e
modo de abordagem. Assim foram definidas as principais funcionalidades do sistema a
testar, com a explicitação de que serão utilizados testes unitários para verificação da
codificação, testes de sistema e de integração para cobertura de requisitos e testes de
aceitação para aprovação por parte do cliente. Foram igualmente identificadas as
ferramentas NUnit e NCover como principais instrumentos de teste do código-fonte.
4 Contudo, já se encontra integrada uma equipa de testes para o desenvolvimento dos mesmos, desde o dia 24 de Junho, estando agendada a primeira fase da realização dos testes unitários para o dia 6 de Julho.
79
7 Avaliação dos Resultados e
Melhoramentos
Tendo em consideração os objectivos especificados no inicio do projecto
compreende-se que o projecto atingiu um nível de implementação bastante aceitável,
superando mesmo as expectativas inicias. Parecendo que o tempo de desenvolvimento
do projecto ao longo do estágio seria insuficiente para todas as funcionalidades que se
pretenderiam obter, seguiu-se uma estratégia de prioritização dos requisitos
especificados e das páginas Web a desenvolver. Inclusivamente foi seguido um
planeamento dinâmico, que se ajustaria a tempo demorado em cada fase mais
prioritária, em detrimento de fases menos prioritárias. Mesmo assim todos os requisitos
e todas as páginas da aplicação Web foram correctamente implementados, no tempo
previsto inicialmente, o que originou uma enorme satisfação, tanto da parte do aluno
como da instituição. O único aspecto a apontar estaria relacionado com a realização de
testes, que apesar da sua especificação e planeamento já estarem terminados, ainda não
existe qualquer teste realizado e, consequentemente, não existe qualquer resultado
destes a apresentar.
Considera-se portanto que, no que respeita às fases de estudo inicial do problema e
tecnologias, de especificação de requisitos e da implementação do sistema, todos os
objectivos propostos foram concluídos com sucesso. No entanto, mesmo com este nível
de evolução, existem sempre melhoramentos a considerar, já que o melhoramento de
um projecto de software é um processo contínuo e infindo, existindo sempre lugar a
adaptações com vista a mais e melhores resultados. Serão seguidamente referidos alguns
destes melhoramentos.
7.1 Optimização da Velocidade do Serviço de Actualização
Actualmente o sistema conta com 14 projectos no seu âmbito, ainda em modo de
experimentação. Para esses 14 projectos, o Serviço de Actualização efectua diariamente
uma recolha dos seus dados, considerando nesta fase apenas os Sistemas Externos EPM
e Sharepoint. Apesar do tempo a este nível não ser uma questão crucial, se o
PTSIPortfolio se afirmar como uma ferramenta imprescindível para a gestão de
80
projectos na PT-SI, a actualização pode passar a ser menos espaçada em tempo mais
abrangente em projectos (a considerar uma evolução para um número de projectos na
ordem dos milhares), este pode passar a ser um factor preponderante.
Nestes 14 projectos com estes dois Sistemas Externos, o processo de recolha de
informações e consequente armazenamento na BDC demora cerca de 75 segundos. Ora
isto dá uma média de cerca de 5 segundos por projecto, o que representa de facto um
valor aceitável. Considerando uma hipotética evolução para 1000 projectos, o tempo de
actualização aumentaria para 5000 segundos, ou seja, cerca 1h24min. Por outro lado,
separando a recolha dos Sistemas Externos, foi possível concluir que apenas o EPM
demora cerca de 35 segundos para os 14 projectos, enquanto para o Sharepoint são
precisos cerca de 40 segundos. Ora isto sugere uma média de 37 segundos por Sistema
Externo, considerando uma dimensão de dados semelhante à destes dois sistemas.
Com base nestes valores compreende-se que para além da sua arquitectura
escalável, o Serviço de Actualização apresenta ainda outra vantagem evidente, que é de
facto a sua eficiência. Contudo, estes valores poderiam ser melhorados, tanto a nível da
chamada dos Web Services como a nível do armazenamento dos dados. Isto poderia
passar por uma maior orientação aos dados a nível dos Web Services, que parece ser o
bottle neck desta aplicação. Com efeito, excluindo problemas e velocidades de rede, a
chamada a estes serviços poderia ser mais rápida se o conteúdo retornado já estivesse
mais adaptado à realidade da BDC. Isto implicaria a transição da lógica de negócio da
camada de C# do Serviço de Actualização para os stored procedures que acedem às
bases de dados dos Sistemas Externos, o que poderia trazer grandes benefícios de
velocidade ao sistema, especialmente se os atributos requisitados fossem correctamente
indexados.
7.2 Inclusão de logfile no Serviço de Actualização
Devido ao seu carácter autónomo e automático, o funcionamento do Serviço de
Actualização não prevê qualquer controlo por parte de utilizadores. Apesar de este facto
ser, à partida, uma vantagem, toda esta mecânica gera um problema de intendência em
relação às actualizações que são efectuadas, tanto a nível dos Sistemas Externos, como a
nível dos projectos que se encontram no âmbito do sistema. Então o que acontece, por
exemplo, e ainda que remotamente, se a chamada ao Web Service falhar? Seja por time
out devido a problemas da rede, seja por um erro interno de inconsistência de dados,
este é um problema real e com um risco considerável.
O sistema, de acordo com o que está implementado, tenta actualizar todos os
Sistemas Externos em todos os projectos, sendo que se algum falhar, o ciclo continua
para o item seguinte. O único controlo que existe está localizado num atributo de cada
tabela da BDC, dataActualização ou dataProgresso, que ao funcionar como uma status
date indica o período da última actualização correcta para aquela tabela naquele
projecto. O que se pretende com este melhoramento é a inclusão de um mecanismo de
log que, sempre que o sistema falhe em algum projecto para um qualquer Sistema
Externo, este erro fique inventariado. Depois, já a nível da perspectiva de administração
do Serviço de Apresentação, o administrador poderia ter acesso a este log e perspectivar
os erros de actualização que se sucederam e a partir daí engendrar a melhor solução
possível.
81
7.3 Optimização da Velocidade do Serviço de Apresentação
A implementação actual do projecto realça o uso das tecnologias Dundas Chart e
Dundas Gauge para a criação de informações visuais, tanto a nível de gráficos, como de
barras de estado, como de velocímetros. Todos estes gadgets são gerados on-the-fly,
aquando do carregamento da página. Uma forma de diminuir a velocidade de acesso às
páginas do projecto seria com a geração destes gadgets pelo Serviço de Actualização ao
longo do seu processo de recolha, efectuando o seu armazenamento como imagens.
Assim, a página Web não teria que gerar um gráfico novo de cada vez que é efectuado
um pedido de visualização, mas sim apenas o carregamento de uma imagem pré-gerada
e guardada na BDC. Considerando um número de utilizadores na ordem das dezenas,
com todos a efectuar consultas da mesma página ao mesmo tempo, esta melhoria
reduziria a carga no servidor para a geração dos gráficos, apesar de manter a carga na
rede para o carregamento das imagens. Consequentemente, a velocidade de acesso às
páginas para cada utilizador também diminuiria, ainda que numa baixa escala, o que
aumentaria certamente o grau de satisfação dos seus utilizadores.
7.4 Melhoramento do Módulo de Visualização
O Serviço de Apresentação prima pela sua simplicidade e capacidade de realce dos
principais problemas dos projectos, com recurso a métricas bem definidas. Porém, os
GP estão habituados a obter estas informações de uma forma ad-hoc, a partir dos seus
sistemas de reporting. Uma das principais formas de ajudar os GP a perceber os
conteúdos do PTSIPortfolio passaria pela adaptação do seu conteúdo de uma forma
semelhante à utilizada por esses outros sistemas. Isto encontra-se patente, por exemplo,
na perspectiva Financeira, cujo conteúdo apresenta uma disposição completamente igual
à disposição e organização apresentadas pelos relatórios de projecto. O mesmo poderia
acontecer noutras perspectivas, tornando ainda mais intuitivo, por recurso ao processo
de habituação dos GP, todo o conteúdo fornecido por este projecto.
Outro modo de melhoramento do módulo de visualização poderia passar pelo
provimento de mais e melhor informação gráfica, considerando mais indicadores de
tendência e mais gráficos de evolução, sem deixar de considerar que «tudo o que é
demais é erro». O que é certo é que as informações gráficas são mais perceptíveis e, na
maior parte dos casos, mais rápidas de captar. E apesar de haver muitas informações
textuais que não poderiam ser representadas graficamente, ainda existem muitas que
poderiam, o que poderia facilitar todo este processo de «absorção» de informação por
parte dos GP.
7.5 Optimização da Interacção com o Utilizador
No Serviço de Apresentação, os únicos modos de interacção com o utilizador, para
além da consulta, situam-se na gestão de comentários e na gestão dos atributos de
administração dos projectos. Apesar de tudo, sendo uma aplicação para consulta e não
para a gestão propriamente dita dos projectos, estes dois aspectos de interacção com o
utilizador relevam-se bastante importantes, já que podem oferecer um melhor nível de
serviço aos GP. Desta forma, estes dois módulos poderiam ser melhorados com recurso
por exemplo às potencialidades do JavaScript ou Ajax, que poderiam tornar este
processo mais rápido e intuitivo.
82
8 Conclusões
Com o término da especificação deste projecto torna-se essencial a realização de
uma reflexão crítica que permita, por um lado, identificar os aspectos positivos a retirar
da sua realização, e por outro lado compreender os aspectos negativos para que sejam
rectificados em situações futuras.
Antes de mais é essencial compreender que todo o esforço neste projecto foi
orientado segundo duas vertentes: primeiro na compreensão das necessidades dos
utilizadores e em segundo na construção da aplicação que melhor respondesse a esse
desafio. Apesar de todos os objectivos terem sido atingidos com sucesso, ainda é cedo
para retirar qualquer conclusão definitiva sobre a satisfação dos futuros utilizadores. No
entanto, pelas informações existentes, existem bons indícios de contentamento.
Deste modo, para além das características multi-disciplinares envolvidas num
projecto deste tipo, a sua realização propiciou ainda um primeiro e verdadeiro contacto
com o mundo empresarial. A nível pessoal, a realização deste projecto no âmbito da PT-
SI, e sobretudo na equipa de desenvolvimento onde estive integrado, foi bastante
gratificante, já que proporcionou a inclusão num grupo de trabalho extremamente
profissional e experiente, cujos conhecimentos vão muito para além daquilo que é
ensinado nos livros. Numa equipa em que a dinâmica ostenta um papel totalitário, foi-
me passada um pouco da essência do que é gerir situações diárias e recorrentes de
necessidades e problemas.
Com tudo isto concluo que num projecto desta índole, muito mais do que a
realização do projecto em si, interessa fomentar o crescimento individual, aperfeiçoando
e impulsionando soft-skills a vários níveis, nomeadamente em áreas como a
responsabilidade, a autogestão, a honestidade, o empreendedorismo, a comunicação e a
participação individual num todo que é maior do que a soma das partes.
Em última instância gostaria de referir que o PTSIPortfolio não constitui apenas
uma equação simples; fiabilidade, simplicidade, clareza, confiança, conveniência,
adaptação, controlo, sinalização... gestão. Bem mais do que um produto de software que
permite a consolidação de informações de projectos, esta solução pode intervir
beneficamente no processo de gestão de projectos ao obrigar os GP a reportar o dia-a-
dia dos seus projectos: vale a pena acreditar que este será um factor preponderante para
atingir a excelência na gestão de projectos. E certamente vale a pena trabalhar para isso.
Referências
[PTS09] Portugal Telecom – Sistemas de Informação. [Online]. Consultado em: Junho
de 2009. Disponível em: <http://www.ptsi.pt>
[PTS091] Portugal Telecom – Sistemas de Informação - “A Gestão de Projectos na
Portugal Telecom – Sistemas de Informação”. Data de publicação: 5 de Junho
de 2009. Consultado em: Junho de 2009.
[PMI04] Project Management Institute – “A Guide to Project Management Body of
Knowledge - PMBOK Guides 2004 Edition”, 2004. Consultado em: Junho de
2009.
[INT09] Portugal Telecom – Sistemas de Informação - Intranet
[Fis01] FISCHER, Gerhard - "The Software Technology of the 21st Century: From
Software Reuse to Collaborative Software Design", 2001. Consultado em:
Junho de 2009. Disponível em:
<http://l3d.cs.colorado.edu/~gerhard/papers/isfst2001.pdf>
[Amb07] AMBLER, Scott W. - “Feature Driven Development (FDD) and Agile
Modeling”, 2007. [Online] Consultado em: Junho de 2009. Disponível em:
<http://www.agilemodeling.com/essays/fdd.htm >
[Nun07] NUNES, Paulo - “Conceito de Gestão de Projectos”. [Online] Data de
publicação: 31 de Outubro de 2007. Consultado em: Junho de 2009.
Disponível em:
<http://www.knoow.net/cienceconempr/gestao/gestaoprojectos.htm>
[W3C02] World Wide Web Consortium - “Web Services Activity Statement – “Web
Services Home”, 2002. [Online] Consultado em: Junho de 2009. Disponível
em: <http://www.w3.org/2002/ws/Activity>
[W3C07] World Wide Web Consortium - “Web Services Description Language
(WSDL) Version 2.0 Part 1: Core Language” [Online] Data de Publicação:
26 de Junho de 2007. Consultado em: Junho de 2009. Disponível em:
<http://www.w3.org/TR/wsdl20/>
[MIC09] Microsoft Corporation - “Services”, Abril de 2009. [Online] Consultado em:
Junho de 2009. Disponível em:
<http://msdn.microsoft.com/en-us/library/ms685141(VS.85).aspx>
[MIC091] Microsoft Corporation - “GridView.Sort Method”, Abril de 2009. [Online]
Consultado em: Junho de 2009. Disponível em:
<http://msdn.microsoft.com/en-
us/library/system.web.ui.webcontrols.gridview.sort.aspx>
[Tin09] TintaDigital – “Soluções em Tecnologias de Informação – “Ferramentas de
gestão de projectos opensource”, 2009. [Online] Consultado em: Junho de
2009. Disponível em:
<http://www.tintadigital.com/index.php/pergunte-
nos/openoffice.org/ferramenta-degestao-de-projectos-opensource.html>
[OFF09] Office Online – “Microsoft Project: Visão geral do produto”, 2009. [Online]
Consultado em: Junho de 2009. Disponível em:
<http://office.microsoft.com/pt-br/project/HA101656381046.aspx>
[PMI08] Project Management Institute – “Researching the Value of Project
Management Study”, 2008. [Online] Consultado em: Junho de 2009.
Disponível em:
<http://www.pmi.org/BusinessSolutions/Pages/Researching-Value-of-
Project-Management-Study.aspx >
[Gor06] GORMAN, Jason - “Use Cases – An Introduction”, 2008. [Online]
Consultado em: Junho de 2009. Disponível em:
<http://www.parlezuml.com/tutorials/usecases/usecases_intro.pdf>
[OMG08] Object Management Group, Inc. - “Unified Modeling Language”, 2008.
[Online] Consultado em: Junho de 2009. Disponível em:
<http://www.uml.org>
[W3C09] World Wide Web Consortium – “World Wide Web Consortium”, 2009.
[Online] Consultado em: Junho de 2009. Disponível em:
<http://www.w3c.org>
85
A. Planeamento
Diagrama de Gantt com o planeamento do projecto, demonstrando a
esquematização das durações previstas para cada fase, incluindo o contraste entre uma
perspectiva optimista e uma perspectiva pessimista. A perspectiva optimista é
representada pelo esquema normal, enquanto a pessimista é representada por um
marcador (triângulo rodado para a esquerda), que representa a duração máxima da fase
respectiva.
A.1 Fases 1, 2 e 3 do Projecto
86
A.2 Fases 4, 5 e 6 do Projecto
87
B. Casos de Uso
B.1 Módulo Serviço de Actualização (act)
ID uc_act_001
Nome Recolher dados
Descrição Este caso de utilização consiste no acesso e recolha de dados
relativos a projectos a partir de sistemas externos.
Actores -
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Actualização em
execução.
A ligação aos sistemas externos encontra-se disponível.
Pré-condições A execução desta aplicação tem que respeitar o horário de
funcionamento.
Existem dados para ser recolhidos.
Os dados a recolher têm que respeitar o formato e o nível de
agregação definidos.
Pós-condições -
88
ID uc_act_002
Nome Armazenar dados
Descrição Este caso de utilização consiste no processamento e armazenamento
dos dados recolhidos.
Actores -
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Actualização em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições A execução desta aplicação tem que respeitar o horário de
funcionamento.
Existem dados para ser processados.
Os dados a processar têm que respeitar o formato e o nível de
agregação definidos.
Pós-condições -Todos os dados recolhidos e processados têm que ser armazenados na
Base de Dados Central.
B.2 Módulo Project Master List (pml)
ID uc_pml_001
Nome Consultar Project Master List
Descrição Este caso de utilização consiste na visualização de uma lista com
todos os projectos activos.
Actores Utilizador Registado, Administrador
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições -
89
Pós-condições A listagem, por omissão, é efectuada com todos os projectos cuja
natureza seja “PRJ” e o estado seja “Activo”.
A ordenação, por omissão, apresenta em primeiro lugar os projectos
relacionados com o utilizador.
ID uc_pml_002
Nome Alternar entre vistas na PML
Descrição Este caso de utilização consiste na navegação entre as várias vistas
(Agregada, Plano, Financeira) na PML.
Actores Utilizador Registado, Administrador
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
Pré-condições O utilizador encontra-se a visualizar a Project Master List.
O utilizador especifica uma vista para a realização da consulta.
Pós-condições -
ID uc_pml_003
Nome Seleccionar projecto na Project Master List
Descrição Este caso de utilização consiste na especificação de um projecto para
visualização dos projectos com determinada natureza.
Actores Utilizador Registado, Administrador
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
Pré-condições O utilizador encontra-se a visualizar a Project Master List.
O utilizador especifica um projecto para a realização da consulta.
Pós-condições -
90
ID uc_pml_004
Nome Ordenar projectos na Project Master List
Descrição Este caso de utilização consiste na especificação de uma coluna da
Project Master List segundo a qual a listagem de projectos deve ser
ordenada.
Actores Utilizador Registado, Administrador
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
Pré-condições O utilizador encontra-se a visualizar a Project Master List.
O utilizador especifica uma coluna para a realização da ordenação.
Pós-condições Os projectos apresentados são reorganizados segundo a nova
ordenação.
A ordenação, por omissão, é efectuada de forma decrescente. Se já
existir uma ordenação anterior segundo a mesma coluna, a ordem
deve ser invertida.
ID uc_pml_005
Nome Consultar comentários de um projecto da Project Master List
Descrição Este caso de utilização consiste na consulta dos comentários
previamente realizados a um determinado projecto presente na Project
Master List.
Actores Utilizador Registado, Administrador
Prioridade Desejável
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador encontra-se a visualizar a Project Master List.
O utilizador especifica um projecto para a apresentação dos seus
comentários.
91
Pós-condições Apenas os comentários relativos ao projecto escolhido são
apresentados.
ID uc_pml_006
Nome Efectuar comentário em relação a um projecto da Project Master List
Descrição Este caso de utilização consiste na realização de um texto de interesse
relativo a um determinado projecto presente na Project Master List.
Actores Utilizador Registado, Administrador
Prioridade Desejável
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador encontra-se a visualizar os comentários relativos a um
determinado projecto.
Pós-condições O comentário será guardado juntamente com o projecto a que diz
respeito, a identificação do utilizador que o realizou e a data/ hora da
sua realização.
B.3 Módulo Perspectivas (per)
ID uc_per_001
Nome Consultar dados de uma perspectiva
Descrição Este caso de utilização consiste na visualização das informações
(textuais ou gráficas) específicas a uma perspectiva.
Actores Utilizador Registado, Administrador
Prioridade Dependente do tipo de perspectiva:
Geral Essencial
Financeira/ Controlo Essencial
Plano Essencial
92
Problemas e Defeitos Opcional
Stakeholders Desejável
Recursos Opcional
Riscos Desejável
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador especifica uma perspectiva para visualização.
Pós-condições Apenas as informações da perspectiva em causa são apresentadas.
ID uc_per_002
Nome Consultar comentários da perspectiva/ subperspectiva
Descrição Este caso de utilização consiste na consulta dos comentários
previamente realizados a uma determinada perspectiva ou
subperspectiva.
Actores Utilizador Registado, Administrador
Prioridade Dependente do tipo de perspectiva:
Geral Essencial
Financeira/ Controlo Essencial
Plano Essencial
Problemas e Defeitos Opcional
Stakeholders Desejável
Recursos Opcional
Riscos Desejável
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador encontra-se a visualizar a perspectiva em questão.
Pós-condições Apenas os comentários relativos à perspectiva / subperspectiva em
questão são apresentados.
93
ID uc_per_003
Nome Efectuar comentário em relação a uma perspectiva/ subperspectiva
Descrição Este caso de utilização consiste na realização de um texto de interesse
relativo a uma determinada perspectiva ou subperspectiva de um
projecto.
Actores Utilizador Registado, Administrador
Prioridade Dependente do tipo de perspectiva:
Geral Essencial
Financeira/ Controlo Essencial
Plano Essencial
Problemas e Defeitos Opcional
Stakeholders Desejável
Recursos Opcional
Riscos Desejável
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador encontra-se a visualizar os comentários relativos a uma
determinada perspectiva ou subperspectiva de um projecto.
Pós-condições O comentário será guardado juntamente com a perspectiva/
subperspectiva e projecto a que diz respeito, a identificação do
utilizador que o realizou e a data/ hora da sua realização.
B.4 Módulo Administração (adm)
ID uc_adm_001
Nome Especificar projectos visíveis
Descrição Este caso de utilização consiste na especificação dos projectos
existentes que irão constar da Project MasterList.
94
Actores Administrador
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador seleccionou um ou mais projecto.
Os projectos seleccionados existem nos Sistemas Externos.
Pós-condições
ID uc_adm_002
Nome Alterar atributos de um projecto
Descrição Este caso de utilização consiste na especificação de valores relativo a
um projecto.
Actores Administrador
Prioridade Essencial
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador especificou um projecto para alterar.
Os valores especificados pertencem ao domínio de valores aceites.
Pós-condições
ID uc_adm_003
Nome Adicionar novo projecto
Descrição Este caso de utilização consiste na especificação de um novo
projecto para ser actualizado.
Actores Administrador
Prioridade Essencial
95
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador especificou um projecto para adicionar.
O projecto especificado deve existir nos Sistemas Externos.
Pós-condições -
ID uc_adm_004
Nome Adicionar observações a projecto
Descrição Este caso de utilização consiste na especificação de observações
administrativas a um projecto.
Actores Administrador
Prioridade Opcional
Pressupostos O servidor encontra-se activo com o Serviço de Apresentação em
execução.
A ligação à base de dados encontra-se disponível.
Pré-condições O utilizador especificou um projecto para adicionar.
-
Pós-condições -
96
C. Protótipos gráficos
C.1 Perspectiva Geral
97
C.2 Perspectiva Financeira
C.3 Perspectiva Plano
98
C.4 Perspectiva Problemas
C.5 Perspectiva Defeitos
99
C.6 Perspectiva Stakeholders
C.7 Perspectiva Recursos
100
C.8 Perspectiva Riscos
101
D. Especificação dos Web Services
A informação pretendida está de acordo com o diagrama relacional apresentado
neste relatório. As tabelas Projectos, Utilizadores, Comentarios, e Defeitos não
possuem informações provenientes destes sistemas e portanto não serão consideradas.
Para cada um dos sistemas, serão necessárias as seguintes informações.
D.1 Sistema Externo EPM
Código do projecto
Dados
o Domínio
o Sub-domínio
o Chefe
o Cliente
o Gestor de Mercado
o Contrato Outsourcing
o Multi-Projecto
o Status Date
o Link para o Workspace
(Dados de “Análise integrada de objectivos”)
o Progresso baseline
o Custo baseline
o Tempo baseline
o Progresso realizado
o Custo realizado
102
o Tempo realizado
o Progresso planeado
o Custo planeado
o Tempo planeado
Progressos Temporais
o Data de Inicio
o Data de Inicio Baseline
o Data de Fim
o Data de Fim Baseline
o Horas de esforço planeadas
o Horas de esforço efectuadas
o CPI
o SPI
o Percentagem de trabalho concluído
o Estado do projecto
Progressos Financeiros
(Dados de “Ficha de rentabilidade”)
o Data da última gravação
o Número de fichas de rentabilização
o Esforço
o Custos materiais
o Custo de consultores
o Custo total
o Proveitos
(Dados de “Última baseline”)
o Data de início
o Data de fim
o Esforço
o Custos materiais
o Custo de consultores
o Custo total
o Proveitos
(Dados de “Plano Actual”)
o Data de início
o Data de fim
o Esforço
o Custos materiais
o Custo de consultores
o Custo total
o Proveitos
o Rentabilidade no final do projecto
(Dados de “Realizado”)
103
o Data de início
o Data de fim
o Esforço
o Custos materiais
o Custo de consultores
o Custo total
o Proveitos facturados
o Proveitos até à data
(Dados de “Realizado SAP”)
o Data de início
o Custos materiais
o Custo de consultores
o Custo total
o Proveitos facturados
o Proveitos até à data
o Rentabilidade actual
(Dados de “Indicadores de performance”)
o ACWP
o BCWS
o BCWP
Milestones
o Nome
o Data Actual
o Data Baseline
D.2 Sistema Externo Sharepoint
Código do Projecto (igual ao EPM)
Problemas
o Descrição
o Estado
o Entidade
o Data de abertura
o Data de fecho prevista
o Estratégias
o Urgência
Avaliações
o Requisitos
104
o Processos
o Planeamento
o Recursos
o Tecnologia
o Comunicação
o Trabalho em equipa
o Data da avaliação
Action Items
o Descrição
o Responsável
o Dependências
o Estado
o Data de abertura
o Data de fecho prevista
o Data de fecho efectiva
Change Requests
o Descrição
o Estado
o Data abertura
o Data prevista de entrega
o Data efectiva de entrega
Riscos
o Condição
o Consequência
o Probabilidade
o Impacto âmbito
o Impacto tempo
o Impacto custo
o Impacto qualidade
o Tipo
o Estado
o Estratégias de mitigação
o Data de abertura
o Data de fecho
105
E. Prova de Conceito
Screen shot da prova de conceito realizada para o serviço de apresentação (Spike
Presentation Service). Este demonstra a criação de um gráfico (gráfico de visibilidade
de projectos, que aparece na PML – Vista Agregada), utilizando a ferramenta Dundas
Chart for ASP.NET.
106
F. Especificação de Desenhos de Teste
F.1 Acesso e utilização da Base de Dados
Identificação dos Casos de Teste
Neste desenho de teste estão presentes os testes que permitem averiguar a
qualidade das características mais comuns do acesso generalista a uma base de dados,
como a conexão e consulta de dados. Pelo âmbito, os casos de teste poderão ser
negativos ou positivos, ou seja, poderão ser testes que estejam obrigados a falhar ou a
passar, dependendo dos dados de input.
Irá ser utilizada a metodologia de teste do tipo blackbox, já que apenas se pretende
testar o funcionamento geral da Base de Dados Central, bem como os resultados
esperados decorrentes desse funcionamento.
ID Caso de Teste Descrição
ct_009 Conexão/Desconexão à
Base de Dados
Deve ser possível ao sistema ligar-se e desligar-se
da Base de Dados.
ct_010 Escrita e Leitura de
Dados
O sistema deve poder escrever e ler dados na Base
de Dados.
ct_011 Integridade e Fiabilidade O sistema deve conseguir operar as transacções da
base de dados com fiabilidade e integridade.
Critérios de aceitação/ rejeição
Este Desenho de Teste baseia-se num conjunto de itens que estão intrinsecamente
ligados ao acesso directo à base de dados. Estes itens têm como base um critério de
aceitação que consiste na verificação da consistência entre dados esperados de saída e
dados efectivos de saída. Caso esta consistência se verifique, os testes são aprovados.
107
F.2 Funções do Serviço de Actualização
Identificação dos Casos de Teste
Neste desenho de teste estão presentes os testes que permitem averiguar a
qualidade das características presentes no Serviço de Actualização, nomeadamente a
nível da recolha, processamento e armazenamento de dados a partir de Sistemas
Externos.
Irão ser utilizados testes automáticos e testes do tipo blackbox, já que apenas se
pretende testar o funcionamento geral da aplicação, bem como os resultados esperados
decorrentes desse funcionamento.
ID Caso de Teste Descrição
ct_001 Chamada aos Web
Services para acesso aos
Sistemas Externos
O Serviço de Actualização deve possuir alguma
forma de invocar os Web Services de acesso aos
Sistemas Externos, e obter uma resposta.
ct_002 Processamento dos
dados recebidos
O Serviço de Actualização deve executar
operações de processamento sempre que receber
dados dos Web Services.
ct_003 Armazenamento dos
dados
O Serviço de Actualização deve proceder ao
armazenamento dos dados interpretados e
processados na Base de Dados Central, para
posterior uso.
Critérios de aceitação/ rejeição
Este Desenho de Teste baseia-se num conjunto de itens que estão intrinsecamente
ligados ao funcionamento do Serviço de Actualização. Estes itens têm como base um
critério de aceitação que consiste na verificação da consistência entre dados esperados
de saída e dados efectivos de saída. Caso esta consistência se verifique, os testes são
aprovados.
F.3 Funções do Serviço de Apresentação
Identificação dos Casos de Teste
Neste desenho de teste estão presentes os testes que permitem averiguar a
qualidade das características presentes no Serviço de Apresentação, nomeadamente a
nível da apresentação de conteúdos e da interacção com o utilizador.
Irão ser utilizados testes automáticos e testes do tipo blackbox, já que apenas se
pretende testar o funcionamento geral da aplicação, bem como os resultados esperados
decorrentes desse funcionamento.
ID Caso de Teste Descrição
ct_004 Acesso aos dados O Serviço de Apresentação deve poder aceder
correctamente aos dados pretendidos que estejam
armazenados na BDC.
ct_005 Apresentação da O Serviço de Apresentação deve poder processar e
108
informação da página consolidar os dados retirados da BDC de forma a
poder apresentá-los numa página Web.
ct_006 Organização da
informação da página
O utilizador do Serviço de Apresentação deve poder
organizar a informação presente na página, tanto a
nível de filtragens como de ordenações.
ct_007 Apresentação de
informação gráfica
O serviço de Apresentação deve poder utilizar
informações provenientes da BDC para gerar
gráficos ou indicadores de tendência.
ct_008 Gestão de comentários
de um projecto ou
perspectiva
O utilizador do Serviço de Apresentação deve ter à
sua disposição um módulo que lhe permita visualizar
e escrever comentários relativos a um projecto ou a
uma perspectiva em específico.
Critérios de aceitação/ rejeição
Este Desenho de Teste baseia-se num conjunto de itens que estão intrinsecamente
ligados ao funcionamento do Serviço de Apresentação. Estes itens têm como base um
critério de aceitação que consiste na verificação da consistência entre dados esperados
de saída e dados efectivos de saída. Caso esta consistência se verifique, os testes são
aprovados.
ct_001: Chamada aos Web Services para acesso aos Sistemas Neste caso, serão testados os componentes ou características que dizem respeito à
chamada dos métodos dos Web Services, nomeadamente no método GetData().
Valores de Entrada
Chamada ao método específico;
Parâmetros para o método;
WSDL (apenas da primeira vez).
Valores de Saída
Bloco XML com informação pretendida.
Hardware e Software
Máquina servidora com aplicação;
Ligação à Intranet;
Máquinas de Sistemas Externos.
Ferramentas de Teste
NUnit.
ct_002: Processamento dos dados recebidos Neste caso, serão testados os componentes ou características que dizem respeito ao
processamento dos dados recebidos a partir dos Web Services, nomeadamente no
método GetData().
Valores de Entrada
109
Bloco XML.
Valores de Saída
Variáveis em memória com os dados.
Hardware e Software
Máquina servidora com aplicação.
Ferramentas de Teste
NUnit.
ct_003: Armazenamento dos dados Neste caso, serão testados os componentes ou características que dizem respeito ao
armazenamento dos dados recebidos a partir dos Web Services, nomeadamente no
método StoreData().
Valores de Entrada
Dados dos Web Services (variáveis em memória).
Valores de Saída
Mensagem da Base de Dados que confirme o sucesso da operação.
Hardware e Software
Máquina servidora com aplicação.
Ligação à intranet.
Servidor SQLServer.
Ferramentas de Teste
NUnit.
ct_004: Acesso aos dados Neste caso, serão testados os componentes ou características que dizem respeito ao
acesso dos dados armazenados na Base de Dados Central, nomeadamente nos métodos
GetDataPML(), GetDataGeral(), GetDataFinanceira(), GetDataPlano(),
GetDataProblemas(), GetDataDefeitos(), GetDataStakeholders(), GetDataRecursos() e
GetDataRiscos().
Valores de Entrada
Connection Sring;
Método CRUD BD;
Parâmetros.
Valores de Saída
Array, classe ou estrutura com os dados requeridos.
Hardware e Software
Máquina servidora com aplicação;
110
Ligação à intranet;
Servidor SQLServe.r
Ferramentas de Teste
NUnit.
ct_005: Apresentação da informação da página Neste caso, serão testados os componentes ou características que dizem respeito à
apresentação das informações guardadas aos utilizadores numa página Web,
nomeadamente no método ShowPage() e ShowComments().
Valores de Entrada
Valores da Base de Dados.
Valores de Saída
Página Web com as informações consolidadas.
Hardware e Software
Máquina servidora com aplicação;
Ligação à intranet;
Servidor SQLServer;
Máquina externa que aceda ao sistema.
Ferramentas de Teste
NUnit.
ct_006: Organização da informação da página Neste caso, serão testados os componentes ou características que dizem respeito à
organização das informações apresentadas aos utilizadores numa página Web,
nomeadamente no método ShowPage() e no que respeita à filtração/ ordenação de
elementos listados.
Valores de Entrada
Array com valores a apresentar.
Valores de Saída
Novo array com valores actualizados.
Hardware e Software
Máquina servidora com aplicação.
Máquina externa que aceda ao sistema.
Ferramentas de Teste
NUnit.
ct_007: Apresentação de informação gráfica
111
Neste caso, serão testados os componentes ou características que dizem respeito à
apresentação das informações gráficas aos utilizadores numa página Web,
nomeadamente no método ShowPage().
Valores de Entrada
Valores da Base de Dados.
Valores de Saída
Gráfico com a representação dos dados.
Hardware e Software
Máquina servidora com aplicação;
Ligação à intranet;
Servidor SQLServer;
Máquina externa que aceda ao sistema.
Ferramentas de Teste
NUnit.
ct_008: Gestão de conteúdos de um projecto ou perspectiva Neste caso, serão testados os componentes ou características que dizem respeito à
gestão de conteúdos de um projecto ou de perspectiva pelos utilizadores numa página
Web. Esta gestão pode ser feita a nível de administração como a nível de criação de
novos comentários, nomeadamente nos métodos AddProject(), EditProject() e
WriteComment().
Valores de Entrada
Texto inserido pelo utilizador.
Valores de Saída
Mensagem da Base de Dados que confirme o sucesso da operação.
Hardware e Software
Máquina servidora com aplicação;
Ligação à intranet;
Servidor SQLServer;
Máquina externa que aceda ao sistema.
Ferramentas de Teste
NUnit.
ct_009: Conexão/Desconexão à Base de Dados Neste caso serão testados os componentes ou características que dizem respeito às
características de acesso à Base de Dados.
Valores de Entrada
112
Connection String.
Valores de Saída
Mensagem da Base de Dados que confirme o sucesso da operação no estabelecimento
da conexão e desconexão.
Hardware e Software
Servidor SQLServer.
Ferramentas de Teste
NUnit.
ct_010: Escrita e Leitura de Dados Neste caso serão testados os componentes ou características que dizem respeito à
gestão de acesso à base de dados, tanto a nível de insert como de retrieve de
informação.
Este caso já se encontra coberto pelo resultado dos Casos de Teste ct_003, ct_004 e
ct_008.
ct_011: Integridade e Fiabilidade Neste caso, deveriam ser testados todos os componentes que garantissem
Integridade e Fiabilidade da Base de Dados. Contudo, a documentação do SQLServer já
garante que uma base de dados criada nesse sistema resulta numa base de dados ACID.
Assim, uma base de dados deste tipo proporciona um conjunto de propriedades que
garante que as suas transacções são processadas de forma altamente fiável, pelo que não
se irá efectuar qualquer teste em relação a este conjunto de características.
Valores de Entrada
Os valores de entrada não se aplicam neste caso de teste.
Valores de Saída
Os valores de saída não se aplicam neste caso de teste.
Hardware e Software
Não é necessário qualquer tipo de software ou hardware para este Caso de Teste.
Ferramentas de Teste
Não é necessário qualquer tipo de ferramenta de testes para este Caso de Teste.
