Utilização da Metodologia Unified Process e
Reflexão sobre a Complexidade Legislativa
no Desenvolvimento de Sistemas de Informação
Paula Cristina Linhares Costa
Dissertação de Mestrado
Orientador na FEUP: Prof. Doutor José Manuel Mendonça Orientador Profissional: Mestre António Bento
Faculda de de E ngenharia da Universidade do Porto Mestrado Integrado em Engenharia Industrial e Gestão
Dedico este trabalho a todas as pessoas com quem trabalhei até hoje e que gostam de trabalhar.
Resumo
Esta dissertação descreve o percurso profissional da mestranda e direciona-o para a análise da metodologia Unified Process e para a exploração do tema da complexidade legislativa no desenvolvimento de sistemas de informação.
A abordagem a estes temas foi efetuada com base no percurso e experiência profissional enquanto responsável de projeto no âmbito do desenvolvimento e manutenção do Sistema de Informação da Segurança Social Portuguesa, nas referências teóricas sobre a metodologia e na pesquisa de artigos científicos sobre o tema da complexidade legislativa.
Inicialmente foi descrito o percurso profissional tendo-se dado ênfase a um importante projeto nacional, que esteve na base do atual Sistema de Informação da Segurança Social Portuguesa.
Através da análise da experiência adquirida em um projeto que englobou todas as fases do ciclo de vida de desenvolvimento de software, foi elaborado um breve tutorial de boas práticas nessa matéria. A experiência em um projeto de grande dimensão e com uma forte componente politica e socioecónomica apoiou a exploração do tema da complexidade legislativa, na sua definição, causas, consequências e potenciais soluções.
Com base na experiência profissional sustenta-se que as boas práticas associadas ao desenvolvimento de software e à metodologia Unified Process constituem uma garantia da qualidade desse processo e que a reflexão sobre o tema da complexidade legislativa aponta para a simplificação e avaliação dos custos de conformidade, como possíveis soluções para alguns dos problemas que lhe estão associados.
Palavras-Chave
Desenvolvimento de sistemas de informação; Unified Process; Complexidade legislativa; Simplificação; Custos de conformidade; Segurança Social Portuguesa
The Use of the Unified Process Methodology and the Study of Complex
Legislative Requirements on the Development of Information Technology
Systems
Abstract
This dissertation describes the professional career path of the student, while analyzing the Unified Process methodology and exploring the theme of legislative complexity and its contribution to the development of information technology systems.
The aforementioned concepts were developed using as reference the professional experience obtained as Project Manager responsible for the development and maintenance of the Portuguese Social Security Information System, as well as theoretical references on the methodology and scientific articles on legislative complexity.
The report has its onset with a detailed description of the student’s professional experience emphasized by an involvement in the implementation of a large scale national project, which is the basis of the current Portuguese Social Security Information System.
The analysis of the professional experience gained while participating in a project which included all phases of the software development life cycle, allowed for the production of a brief tutorial of best practices essential to the software development process. The experience in a large-scale project with strong political and socioeconomic characteristics aided in the study of complex legislative requirements, in terms of definition, causes, consequences and potential solutions.
The professional experience obtained throughout the years, sustains that when one associates the Unified Process methodology with best practices in software development, the quality of the process is guaranteed. The study of legislative complexity suggests that by evaluating compliance costs and simplifying legislation, one may reduce most of the associated problems.
Keywords
Information Systems Development; Unified Process; Legislative Complexity; Simplification; Compliance costs; Portuguese Social Security System
Agradecimentos
Agradeço em primeiro lugar à Faculdade de Engenharia da Universidade do Porto (FEUP) por ter proporcionado aos seus antigos alunos com licenciaturas anteriores ao Processo de Bolonha esta oportunidade de adquirir o grau de mestre e ao Professor Falcão e Cunha por ter sido o intermediário e facilitador da mesma.
Agradeço ao meu orientador da FEUP o Professor José Manuel Mendonça, que tive o prazer de conhecer neste mestrado, pelo interesse e disponibilidade para discutir ideias e me ajudar a estruturar de uma forma objetiva e coerente este relatório.
Agradeço ao meu orientador profissional o Dr. António Bento pela capacidade de me ouvir e de me orientar respeitando sempre as minhas opções, pela disponibilidade para rever todos os conteúdos inúmeras vezes e por guardar na memória (por vezes mais do que eu própria) grande parte do meu percurso e realizações profissionais.
Agradeço e admiro na D. Soledade Medeiros e na D. Lucília Fernandes a capacidade, para me ajudar tão eficientemente a gerir a distância, para responder tão prontamente a todas as minhas questões e para garantir a disponibilidade ou respostas de quem precisava.
Agradeço à minha família e ao João por acreditarem em mim e me incentivarem sempre para a concretização dos meus projetos.
Agradeço ao meus colegas e amigos que me ajudaram a recolher informação, a organizar ideias e a descomprimir. Agradeço em particular à Ana e à Fátima, por terem estado tão atentas e por me terem ajudado em várias pesquisas e traduções.
Agradeço profundamente à minha irmã Vânia por partilhar comigo todos os seus conhecimentos enquanto aluna de doutoramento, esclarecendo as minhas questões fundamentais sobre projetos de investigação e trabalhos científicos, por ter partilhado comigo artigos e pesquisas, por me ter ouvido e confiado em mim. E essencialmente por me dar alento em todos os momentos, os mais fáceis e os menos fáceis, durante este percurso.
Índice de Conteúdos 1. Introdução ...1 1.1. Motivação... 1 1.2. Organização do Relatório... 1 2. Atividade Profissional ...2 2.1. Experiência Profissional ... 2
2.2. Apresentação do Instituto de Informática, I.P... 4
2.3. Apresentação do Sistema de Informação da Segurança Social ... 9
2.4. Conclusão e Perspetivas Futuras ... 12
3. Atividade Profissional e Metodologia Unified Process...13
3.1. Descrição do Fundo de Garantia Salarial... 13
3.2. Análise da Atividade Profissional no Projeto Fundo de Garantia Salarial e enquadramento na Metodologia Unified Process... 14
3.3. Discussão da Metodologia Unified Process ... 22
3.4. Conclusão ... 30
4. Atividade Profissional e Complexidade Legislativa...31
4.1. Descrição da Eventualidade de Desemprego ... 31
4.2. Apresentação dos Subsistemas de Prestações Gerais, Desemprego e Layoff ... 32
4.3. Análise da Atividade Profissional no Projeto Desemprego e Enquadramento na Problemática da Complexidade Legislativa... 32
4.4. Discussão da Problemática da Complexidade Legislativa ... 39
4.5. Conclusão ... 49
5. Conclusões...50
Referências ...51
ANEXO A: COMPETÊNCIAS DOS DEPARTAMENTOS DO II, I.P ...56
ANEXO B: MODELO DE GESTÃO DO II, I.P. ...57
ANEXO C: RECURSOS DO II, I.P. ...59
ANEXO D: ARQUITETURA DO II, I.P. ...61
ANEXO E: DIAGRAMAS UNIFIED MODELING LANGUAGE ...63
ANEXO F: CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE; ARTEFACTOS ...67
ANEXO G: DESCRIÇÃO E FLUXOGRAMA DO PROCESSO LEGISLATIVO COMUM ...69
ANEXO H: DESCRIÇÃO DO PROCESSO LEGISLATIVO DO GOVERNO ...71
Siglas
CES Conselho Económico e Social
CPA Controlo de Processos Administrativos
DES Desemprego
DGITA Direção-Geral de Informática e Apoio aos Serviços Tributários e Aduaneiros FEUP Faculdade de Engenharia da Universidade do Porto
FGS Fundo de Garantia Salarial
GC Subsistema de Gestão de Conta-corrente
IEFP, I.P. Instituto do Emprego e Formação Profissional, I.P. IGFSS, I.P. Instituto de Gestão Financeira da Segurança Social II, I.P. Instituto de Informática, I.P.
IIES Instituto de Informática e Estatística da Solidariedade ISS, I.P Instituto da Segurança Social, I.P.
ITPT Impedimentos Temporários para o Trabalho
MIEIG Mestrado Integrado em Engenharia Industrial e Gestão MSSS Ministério da Solidariedade e da Segurança Social ONI Organismo Nacional de Informática
OO Object-Oriented
PESI Plano Estratégico de Sistemas de Informação PF Prestações Familiares
PG Prestações Gerais
PME Pequenas e médias empresas
QUAR Quadro de Avaliação e Responsabilização
SIADAP Sistema Integrado de Gestão e Avaliação do Desempenho na Administração Pública SICC Sistema Integrado de Conta Corrente
SIF Sistema de Informação Financeira
SISS Sistema de Informação da Segurança Social
SLA Service Level Agreement (Acordo de Nível de Serviço) SSD Segurança Social Direta
TIC Tecnologias de Informação e Comunicações UE União Europeia
UML Unified Modeling Language
Índice de Figuras
Figura 1 - Estruturas de projeto do II, I.P., organizadas matricialmente... 5
Figura 2 - Departamentos e áreas do II, I.P., organizados hierarquicamente ... 6
Figura 3 – Cadeia de valor do II, I.P... 8
Figura 4 - Sistema de Informação da Segurança Social, 2010 ... 11
Figura 5 - Arquitetura base do Sistema de Informação da Segurança Social ... 19
Figura 6 - Uma abordagem iterativa e incremental do desenvolvimento orientado a objetos... 25
Figura 7 - Ciclo de vida de desenvolvimento de software ... 30
Figura 8 - Distribuição percentual das despesas correntes da Segurança Social em 2010 ... 34
Figura 9 - Arquitetura lógica do II, I.P. ... 61
Figura 10 - Arquitetura global de rede do II, I.P. ... 62
Figura 11 - Diagrama de classes ... 63
Figura 12 - Diagrama de objetos... 63
Figura 13 - Diagrama de componentes... 64
Figura 14 - Diagrama de deployment... 64
Figura 15 - Diagrama de casos de uso ... 64
Figura 16 - Diagrama de sequência ... 65
Figura 17 - Diagrama de colaboração... 65
Figura 18 - Diagrama de estados... 65
Figura 19 - Diagrama de atividades ... 66
Figura 20 - Fluxograma do processo legislativo comum... 70
Índice de Tabelas
Tabela 1 - Dados do projeto FGS ... 21
Tabela 2 - Dados da aplicação FGS ... 21
Tabela 3 - Despesa da Segurança Social... 35
Tabela 4 – Prestações de Desemprego da Segurança Social ... 35
Tabela 5 - Beneficiários das prestações de Desemprego no total de desempregados inscritos nos Centros de Emprego e Formação Profissional ... 35
Tabela 6 – Síntese da legislação principal da eventualidade de Desemprego ... 37
1. Introdução
1.1. MotivaçãoNos últimos anos comecei a sentir a necessidade de consolidar em termos académicos o conhecimento adquirido ao longo dos cerca de 15 anos de experiência profissional. Por isso, quando recebi da FEUP a informação sobre o Mestrado Integrado em Engenharia Industrial e Gestão (MIEIG) percebi que tinha surgido essa oportunidade.
Acredito que, por ter este percurso académico e profissional, estou em melhores condições para usufruir de uma formação avançada em Engenharia Industrial e Gestão, do que eventualmente estaria ao terminar a licenciatura em Gestão e Engenharia Industrial (pré-Bolonha), mas também por isso, sinto maior necessidade de atualização e evolução dos conhecimentos técnicos e científicos.
Este mestrado representa assim um desafio à reflexão sobre a prática adquirida, uma oportunidade para adquirir novos conhecimentos e conhecer novas pessoas, que me inspirem ao perspetivar o futuro.
Efetuar o MIEIG na FEUP significa reconhecer a esta Faculdade (a minha instituição académica base) a qualidade de ensino e de preparação para a atividade profissional e voltar a confiar nessa qualidade, agora na vertente de investigação e evolução profissional.
1.2. Organização do Relatório
Este relatório está dividido em cinco capítulos.
No capítulo inicial de introdução, é efetuado o enquadramento geral do relatório, explorada a motivação subjacente ao MIEIG e ainda descrita a organização do documento.
No segundo capítulo, é descrita a experiência profissional, com ênfase nos projetos implementados e nas competências adquiridas nos últimos anos, paralelamente à contextualizando da organização e do Sistema de Informação da Segurança Social.
No terceiro capítulo, após um breve enquadramento do projeto Fundo de Garantia Salarial é analisada a atividade profissional à luz da metodologia Unified Process (UP), seguida da respetiva discussão teórica.
No quarto capítulo, após um breve enquadramento do projeto Desemprego é analisada a atividade profissional à luz da complexidade legislativa, seguida da respetiva discussão teórica.
No capítulo final, são apresentadas as conclusões que resultaram da discussão dos respetivos temas e as perspetivas profissionais e de investigação futura.
2. Atividade Profissional
“Genius is one percent inspiration, ninety-nine percent perspiration.” Thomas Alva Edison
2.1. Experiência Profissional
Movida pelo fascínio na disciplina de gestão de recursos, em 1996, no último ano do curso, movi esforços no sentido de estagiar nessa área. Essa oportunidade acabou por surgir no Grupo SONAE, pouco tempo depois.
Inicialmente trabalhei na empresa Sonae Investimentos, participando num estudo para reestruturação de cargos superiores, em colaboração com a equipa de consultores da Hay Group. O meu trabalho continuou, posteriormente, na Sonae Distribuição. Esta empresa centralizava os serviços de recursos humanos do grupo, o que me permitiu colaborar nas diferentes vertentes dessa área, nomeadamente recrutamento e seleção, formação e gestão técnica administrativa.
Esta experiência na Sonae Distribuição contribuiu para direcionar o meu percurso profissional, para uma vertente de gestão mais abrangente, permitindo-me descobrir que o meu fascínio na área de recursos humanos assentava na gestão de pessoas, que se manifesta em qualquer ramo da gestão.
A experiência na Sonae Investimentos facultou-me técnicas e contactos necessários para concretizar essa nova direção, mais abrangente.
Dessa forma começou a minha colaboração com a empresa MBA Consultores, em 1997. Na sequência da experiência anterior comecei por acompanhar um novo projeto de descrição de funções no Grupo Amorim, colaborando paralelamente na construção do sistema de qualidade da empresa e nas atividades de formação, essencialmente nas áreas comportamental, comunicação e recursos humanos.
A experiência na área da consultoria facultou-me maior autonomia e polivalência em termos profissionais e permitiu-me desenvolver competências de comunicação interpessoal e institucional, quer com clientes, quer com o público de uma forma geral, no âmbito das atividades de formação.
Em 1999, enquanto sentia uma vontade crescente de acompanhar as fases de implementação de soluções, que raramente era possível na área de consultoria, e de trabalhar numa organização de maior dimensão, tomei conhecimento de um projeto de grande envergadura, cuja missão me foi descrita, em termos gerais, da seguinte forma: reestruturar o funcionamento da segurança social a nível nacional.
A dimensão e a componente de gestão da mudança foram determinantes para me candidatar a esse projeto, dado que respondiam diretamente às minhas aspirações. Assim, nesse mesmo ano, integrei a Área de Organização (1) do recém-criado Instituto Público (2), então designado por Instituto de Informática e Estatística da Solidariedade (IIES), sob a tutela do Ministro do Trabalho e da Solidariedade.
Após a fase inicial de divulgação do projeto, por todo o país, iniciamos os trabalhos de reengenharia e de gestão da mudança, que constituem a base da organização do sistema de segurança social atual. Este período foi fundamental na aquisição das competências basilares para o meu percurso profissional. Os trabalhos de reengenharia deram-me um conhecimento profundo das pessoas e do negócio da segurança social. Os trabalhos na área de organização, a título de exemplo, o trabalho de desconcentração de competências para o front-office, no âmbito da criação das Lojas da Solidariedade e Segurança Social, foram uma excelente escola em termos de experimentação de vários modelos de organização do trabalho. Por fim os projetos de gestão da mudança (que acompanharam a entrada em produção das novas aplicações) revelaram-se fulcrais no desenvolvimento de competências de gestão da mudança, planeamento e das restantes disciplinas associadas aos projetos de desenvolvimento de sistemas de informação.
Em 2004, com a implementação dos primeiros subsistemas pelo IIES, comecei a sentir maior motivação para as disciplinas de sistemas de informação, nomeadamente levantamento de requisitos e análise, indo ao encontro da minha formação base em Gestão e Engenharia Industrial, nas suas componentes técnica e de gestão. Esta nova motivação aconteceu em simultâneo com uma grande alteração no modelo de relacionamento com os utilizadores finais, que decorreu da criação do Instituto de Segurança Social, I.P. (ISS, criado em 2001) (3). Esta alteração fez com que a intervenção do II, I.P. passasse a estar mais focada na gestão tecnológica dos projetos e menos nas vertentes de organização e gestão da mudança. Por esse motivo, comecei a empreender esforços para mudar de funções, no âmbito do IIES.
Esses esforços resultaram na minha integração na equipa de Análise de Sistemas, da Unidade de Sistemas de Informação, em 2005 (1).
Após um período inicial de formação e de colaboração em diferentes atividades, como levantamento de requisitos, análise de sistemas e manutenção das bases de dados dos sistemas transversais, foi-me atribuída a responsabilidade de gestão do projeto de desenvolvimento, de um novo subsistema da segurança social, o Fundo de Garantia Salarial, que acabei por assumir no final de 2005.
Três anos depois, em 2009, foi-me atribuída a responsabilidade pela manutenção dos subsistemas de Prestações Gerais e Desemprego e, paralelamente, fui convidada para integrar a equipa de auditores internos, funções que ainda desenvolvo atualmente.
Fazendo uma retrospetiva da minha atividade profissional, as diferentes funções que desempenhei serviram como percursoras para a atividade atual, na área de gestão de projetos. A gestão de projetos, atualmente na vertente do desenvolvimento de sistemas de informação, é por isso a matéria que considero relevante apresentar e discutir no presente relatório, na perspetiva de sedimentação e aquisição de novas competências e de potenciais contributos no âmbito da investigação.
Neste sentido, começarei por descrever a organização onde estes projetos foram desenvolvidos, o Instituto de Informática, I.P. e o Sistema de Informação da Segurança Social, e posteriormente, aprofundarei as atividades desenvolvidas no projeto Fundo de Garantia Salarial e no projeto Desemprego, acima referenciados.
2.2. Apresentação do Instituto de Informática, I.P.
O despacho conjunto, nº 200/97, dos Ministros das Finanças e da Solidariedade e Segurança Social, criou uma estrutura de projeto, designada por Organismo Nacional de Informática (ONI), cujo trabalho reforçou a necessidade urgente de criar uma sede própria para desenvolver um sistema de informação que superasse as dificuldades do sistema existente “caracterizado pela proliferação de subsistemas não compatibilizáveis e com mais de uma dezena de anos” (2). Com esse objetivo foi então criado, o Instituto de Informática e Estatística da Solidariedade (IIES), pelo Decreto-Lei nº 115/98, de 4 de maio, que publicou a Lei Orgânica do XIII Governo Constitucional (4).
Em 1999 foram aprovados os Estatutos do IIES, pelo Decreto-Lei nº41-A/99, de 9 de fevereiro (2), enquanto organismo dotado de personalidade jurídica de direito público, com autonomia administrativa e financeira e património próprio. Em 6 de abril é publicada pela Portaria nº 242/99 a respetiva estrutura orgânica (1).
Nos diferentes Governos Constitucionais, o IIES adquiriu novas denominações, mas o seu objetivo manteve-se genericamente inalterado. Atualmente é designado por Instituto de Informática, I.P. (II, I.P.) e constitui um organismo central da administração indireta do Estado, dotado de autonomia administrativa e financeira e património próprio, com intervenção sobre todo o território nacional, tendo a sua sede em Porto Salvo, Taguspark, Oeiras. O II, I.P. integra o Ministério da Solidariedade e da Segurança Social (MSSS) que é um departamento governamental que resulta da reorganização da estrutura do Estado estabelecida pela Lei Orgânica do XIX Governo Constitucional.
O II, I.P. está sob superintendência e tutela do respetivo ministro. Para efeitos das matérias relacionadas com a coleta de contribuições a superintendência e tutela do II, I.P. são exercidas em conjunto pelos membros do Governo responsáveis pelas áreas da solidariedade e da segurança social, das finanças e da economia e emprego (5).
A missão, visão e valores do II, I.P. são descritos da seguinte forma (6):
Missão: O II, I.P. tem por missão definir e propor as políticas e estratégias de tecnologias de informação e comunicação, garantindo o planeamento, conceção, execução e avaliação das iniciativas de informatização e atualização tecnológica do MSSS.
Visão: O II, I.P. pretende ser uma referência nacional das melhores práticas na conceção, desenvolvimento, implementação e operação de Sistemas de Informação. Valores: O II, I.P. rege-se por princípios de dedicação exclusiva ao serviço do
interesse público, observando os valores fundamentais e princípios da atividade administrativa: legalidade, justiça, imparcialidade, competência, responsabilidade, proporcionalidade, transparência e boa-fé.
2.2.1. Clientes
Os clientes do II, I.P. são todos os organismos do MSSS e outros organismos da Administração Pública com os quais são celebrados protocolos. Em última instância são também clientes os cidadãos e empresas que interagem com a segurança social através dos canais disponibilizados para o efeito (web e telefónico).
2.2.2. Colaboradores
De acordo com os últimos dados públicos divulgados (7), o II, I.P. contava, em 31 de dezembro de 2009, com um total de 277 trabalhadores (para mais informação sobre os Recursos do II, I.P. (8), ver anexo C).
2.2.3. Estrutura Orgânica
Em 2007 o II, I. P. adotou um modelo estrutural misto constituído por (9): Estruturas de projeto, organizadas matricialmente;
Departamentos e áreas, organizados hierarquicamente.
A atividade do II, I. P., no relacionamento com as entidades a quem presta serviços, e na gestão das soluções aplicacionais desenvolve-se através de estruturas de projeto, organizadas matricialmente, de natureza não permanente, criadas por deliberação do conselho diretivo. Esta estrutura representada na figura seguinte (10) é a que melhor caracteriza a organização e aquela que é apresentada primeiramente, inclusive na legislação (9), por ser a que melhor transparece os serviços prestados e a natureza flexível das equipas que os desenvolvem.
Figura 1 - Estruturas de projeto do II, I.P., organizadas matricialmente
As estruturas de projeto são coordenadas por responsáveis designados pelo conselho diretivo, não sendo estes considerados dirigentes, e reportam diretamente aos departamentos em que se integram e ou diretamente ao conselho diretivo.
Soluções Aplicacionais Transversais Soluções Aplicacionais da Segurança Social e Reabilitação Soluções Aplicacionais do Emprego, Formação Profissional e Relações Laborais Gestão da Informação Operações de Sistemas e Apoio a Clientes
Planeamento, Auditoria e Qualidade
Arquitectura de Sistemas e Estratégia Tecnológica
Administração Geral Conselho Directivo
A essas estruturas compete a avaliação das necessidades em matéria de sistemas de informação e o planeamento, levantamento de requisitos, conceção, elaboração, construção, realização de testes e apoio à transição das soluções aplicacionais disponibilizadas pelo II, I.P.
A estrutura hierárquica é constituída por departamentos e por outras unidades flexíveis, designadas por áreas e equipas a criar, alterar e extinguir pelo conselho diretivo em função das necessidades de serviço (anexo A – Competências dos Departamentos do II, I.P.).
Esta estrutura encontra-se representada na figura seguinte (11):
Figura 2 - Departamentos e áreas do II, I.P., organizados hierarquicamente
De acordo com esta estrutura estou atualmente integrada na Área de Prestações do Departamento de Soluções Aplicacionais da Segurança Social e Reabilitação. Faço parte da estrutura de Soluções Aplicacionais da Segurança Social e Reabilitação enquanto responsável pela manutenção dos subsistemas de Prestações Gerais e Desemprego, bem como da estrutura transversal de Planeamento, Auditoria e Qualidade, enquanto auditora interna.
2.2.4. Catálogo de Serviços
O instituto disponibiliza aos seus clientes um Catálogo de Serviços, onde consta a descrição de cada serviço, as características e condições necessárias de acesso aos serviços. Esse catálogo comporta serviços nas seguintes áreas de intervenção: Datacenter, Acesso e Partilha de informação, Segurança da informação, Apoio ao Utilizador, Ciclo de vida dos equipamentos, Monitorização, Gestão da informação, Formação, Framework SISS e Serviços Aplicacionais, tendo associados Service Level Agreement (SLA). Fazem parte por exemplo dos Serviços Aplicacionais os subsistemas para os quais presto serviços, nomeadamente Prestações Gerais e Desemprego.
2.2.5. Sistema de Gestão Integrado
O sistema de gestão integrado do II, I.P. engloba o sistema de gestão da qualidade (ISO 9001:2008), o sistema de gestão de serviços de TI (ISO/IEC 20000:2005) e o sistema de gestão da segurança de informação (ISO/IEC27001:2005) (13).
A aposta feita pelo II, I.P. em termos de melhoria dos sistemas de Gestão da Qualidade permitiram-lhe tornar-se a primeira organização prestadora de Serviços de Tecnologias de Informação, em Portugal, certificada por estas três normas.
Desde 2004 que o II, I.P. adotou também como referência o EFQM Excellence Model, tendo obtido o reconhecimento C2E (Committed to Excellence), em 2007 e R4E (Recognised for Excellence), em 2009 e 2012.
2.2.6. Cadeia de Valor
Os processos do instituto foram sistematizados, documentados e esquematizados de acordo com a figura a seguir apresentada, que representa a Cadeia de Valor do II, I.P. (14).
A Cadeia de Valor do II, I.P. identifica o conjunto de macroprocessos inter-relacionados e inter-atuantes, através dos quais o II, I.P. cria o valor dos serviços que disponibiliza aos seus clientes, bem como o conjunto de macroprocessos de gestão e os macroprocessos de suporte, que asseguram e controlam a atividade desenvolvida. Para cada um desses processos foram definidos os indicadores da medição de desempenho, que são monitorizados regularmente.
Na perspetiva da Cadeia de Valor do II, I.P., atualmente, as minhas atividades enquadram-se essencialmente nos Processos de Realização, e mais em particular nos macroprocessos de Gestão de Projetos, Gestão de Entregas (anteriormente designado por Construção, Manutenção e Entrega de SI) e Gestão de Alterações.
As atividades associadas a esses macroprocessos incluem o planeamento, em termos de timings e custos, a comunicação e negociação da solução com os clientes e fornecedores, o acompanhamento das provas de conceito e pilotos, a validação dos entregáveis previstos na metodologia (e revisão dos mesmos em termos de análise), o controlo dos SLA estabelecidos em termos de helpdesk, bem como o reporte à gestão, quer quando são constituídos projetos, quer quando se tratam de alterações do âmbito da manutenção evolutiva e corretiva.
Figura 3 – Cadeia de valor do II, I.P
O macroprocesso de Gestão de Projetos aplica-se a todos os projetos realizados no II, I.P., quer digam respeito a novos subsistemas (como é o caso do Fundo de Garantia Salarial, que será descrito no capítulo 3), quer a subsistemas em manutenção (como é o caso do Desemprego, que será descrito no capítulo 4). O desvio temporal do projeto face ao planeamento é um exemplo de indicador de desempenho deste macroprocesso.
O macroprocesso de Gestão de Entregas é igualmente válido para novos subsistemas, como para subsistemas em fase de manutenção, englobando as diversas atividades, tais como: planeamento, desenho, construção, testes, formação e implementação. São indicadores de desempenho deste macroprocesso, por exemplo, a percentagem de builds (entregas de construção) rejeitadas nos testes de aceitação e a percentagem de incumprimento dos SLA estabelecidos em termos de helpdesk.
O macroprocesso de Gestão de Alterações aplica-se a todos os serviços do Catálogo de Serviços do II, I.P. relacionados com a disponibilização dos serviços da Segurança Social Direta, do Sistema de Informação Financeiro e do Sistema de Informação da Segurança Social. Este macroprocesso abrange as alterações relativas a hardware, a software de sistemas e a software aplicacional relacionados com os serviços do Catálogo de Serviços do II, I.P. que possibilitam a disponibilização dos serviços atrás referidos. O número de alterações de emergência é um exemplo de indicador de desempenho deste macroprocesso.
Pode ser visto o modelo de gestão do II, I.P. e os recursos humanos, financeiros e materiais, respetivamente nos anexos B e C.
2.3. Apresentação do Sistema de Informação da Segurança Social
2.3.1. Construção do Novo Sistema
A segurança social enfrentava em 1998, no momento que precedeu a criação do II, I.P. uma necessidade urgente de melhorar a gestão financeira do sistema e o combate à fraude e evasão contributiva. Esta situação decorria em grande parte dos principais processos de negócio estarem suportados por aplicações obsoletas, com a informação dispersa por vários sistemas distritais, sem interação nem consolidação. A falta de uniformização dos processos de negócio levantava sérios constrangimentos na resposta aos clientes.
Os 22 sistemas distritais estavam assentes em plataformas distintas, AS400, ICL IDMS, UNISYS, entre outras, o que para além dos problemas de integração, estava a criar também uma situação insustentável na gestão do sistema. Refira-se, a título de exemplo, que proliferavam prestações atribuídas nas mesmas condições com montantes diferentes (por vezes até com despachos e decisões diferentes) e, mais grave, existiam beneficiários que se aproveitavam de forma fraudulenta destes problemas solicitando a atribuição de uma mesma prestação em distritos diferentes.
Como não poderia deixar de ser, a conceção do novo sistema, teve como ponto de partida o diagnóstico da situação, ao nível de recursos humanos, infraestruturas, processos de negócio, e necessidades de formação.
Os primeiros projetos formativos levados a cabo pelo II, I.P. abrangeram os cerca de 14.000 colaboradores da segurança social e tiveram como objetivos:
Dotar os colaboradores da segurança social de competências informáticas, de forma a possibilitar a utilização do novo sistema de informação da segurança social;
Sensibilizar os colaboradores da segurança social para a importância do uso de ferramentas informáticas na prestação de um serviço de excelência ao cliente;
Desenvolver nos colaboradores da segurança social atitudes de mudança e adesão às novas ferramentas informáticas.
Posteriormente, foram ministradas ações de formação mais específicas, orientadas para a aquisição de competências técnicas no domínio da administração de sistemas.
Paralelamente, desenhou-se a arquitetura do sistema global, definindo-se o modelo operacional e de gestão, o modelo de arquitetura técnica e aplicacional e a importante estratégia de migração de dados.
Em função da arquitetura técnica definida, foram criados novos postos de trabalho para todos os colaboradores do sistema e foi implementado um sistema de redes e comunicações capaz de sustentar o novo sistema de informação.
Em termos de arquitetura técnica o sistema foi definido em três camadas/níveis: a camada de integração - de base de dados, a camada aplicacional - de regras de negócio e a camada cliente – de apresentação. Optou-se pelo JAVA como linguagem de programação e o UML (Unified Modeling Language) como linguagem de modelação, operacionalizada através de uma
metodologia própria, desenvolvida com base em metodologias OO (Object-Oriented), nomeadamente na metodologia UP (Unified Process). Dado tratar-se de um sistema de âmbito nacional, procurou-se investir em standards de mercado para garantir a evolução e manutenção do sistema a longo prazo (15).
Em termos de dados foi construído um sistema, com suporte ORACLE, a par com o complexo projeto de migração de dados. Este processo contemplou a aquisição dos dados dos sistemas antigos, a purificação, o carregamento e a sincronização contínua dos mesmos, para o novo sistema, até estarem reunidas as condições para os sistemas legados serem descontinuados.
O passo seguinte consistiu no desenvolvimento e disponibilização dos vários subsistemas que integram o sistema global nacional. A primeira aplicação de âmbito nacional, a Declaração de Remunerações por Internet, entrou em produção no ano 2000, paralelamente aos processos de transição para o ano 2000 e Euro, seguindo-se o subsistema de Gestão de Tesourarias, no ano 2002. Em 2003 iniciou-se a implementação do SISS de forma mais abrangente, integrando os subsistemas chamados nucleares. Um subsistema de Identificação e Qualificação, repositório único e nacional com a identificação das Entidades que se relacionam com a Segurança Social, nomeadamente Pessoas Singulares e Pessoas Coletivas e a classificação desse relacionamento (15). E um segundo subsistema de Gestão de Remunerações, repositório único e nacional de toda a carreira contributiva das Pessoas Singulares, perante a segurança social.
O ano de 2005 representou um marco na história do instituto, na medida em que se afirmou o Novo Sistema de Informação da Segurança Social, com a consolidação em exploração dos subsistemas de processamento e pagamento das prestações a nível nacional, bem como, devido ao início da desativação das plataformas distritais, nomeadamente Desemprego, Prestações Familiares, entre outros. O Novo Sistema de Informação da Segurança Social tornou-se também mais visível para o exterior, pela disponibilização do serviço Segurança Social Direta (SSD), concretizando a tão desejada aproximação do Sistema de Segurança Social à sociedade (16).
A partir de 2007 ganharam preponderância os sistemas de gestão do relacionamento com o cidadão, por exemplo, a consolidação das funcionalidades na SSD, o centro de contacto da Segurança Social - Via Segurança Social, e os sistemas de suporte à gestão, nomeadamente o Sistema de Informação Financeira (SIF), em alinhamento com o plano estratégico de sistemas de informação.
2.3.2. Sistema Atual
A figura seguinte apresenta o estado atual do SISS em termos de arquitetura aplicacional (12). No anexo D, pode ser vista a arquitetura lógica e a arquitetura global de rede do II, I.P..
O SISS engloba atualmente uma vertente central de Negócio constituída por subsistemas de Prestações, Arrecadação e Controlo de Receitas, Ação Social e Inspeções e Auditorias, para as quais presto serviço atualmente, enquanto responsável pela manutenção dos subsistemas de Prestações Gerais e Desemprego; uma vertente Transversal que tem não só os sistemas de Suporte à gestão como também Parametrizações, que contém regras gerais internas ou externas à Segurança Social (por exemplo códigos postais, tabelas de IRS) e que por isso apoiam todos os outros sistemas – todos os colaboradores contribuem para a manutenção destes sistemas transversais.
Estes sistemas estendem-se aos organismos clientes pela vertente Gestão Cliente e aos beneficiários e contribuintes, clientes desses organismos. Os colaboradores que trabalham na vertente de negócio, tal como é o meu caso, habitualmente prestam serviços também nesta área como última linha de apoio ao cliente ou cidadão. O mesmo acontece em relação à vertente Canais que representa atualmente a área de maior crescimento, pela disponibilização direta ao cidadão alguns serviços do negócio.
2.4. Conclusão e Perspetivas Futuras
As diferentes funções que desempenhei serviram como percursoras para as atividades que atualmente desenvolvo na área de gestão de projetos. Com mais de 10 anos de experiência nesta área, perspetivo para o futuro projetos e/ou gestão de programas com maior responsabilidade e dimensão e eventualmente em novas áreas de intervenção, nomeadamente nas áreas de organização e gestão da mudança para as quais continuo a sentir uma forte motivação.
O II, I.P. está num período de mudança, impulsionado pela reorganização dos organismos com que se relaciona, mas continua focado no seu objetivo de melhoria contínua do SISS. O SISS de acordo com o Plano Estratégico de Sistemas de Informação para o Triénio 2011-2013 deverá evoluir de acordo com as seguintes orientações (12):
“Garantir que as necessidades mais relevantes para a actividade dos organismos são cobertas por sistemas de informação, eliminando ou minimizando o recurso a sistemas paralelos”;
“Promover uma visão abrangente e integrada dos sistemas de informação, potenciando a partilha de informação entre os diversos sistemas e proporcionando ao utilizador uma visão única das informações de negócio”;
“Gerar informação de gestão para os decisores de negócio, que possibilite a análise e monitorização da actividade desenvolvida”;
“Objectivar a flexibilidade e modularidade de modo a permitir de forma fácil e expedita a extensão dos sistemas a novas funcionalidades”;
3. Atividade Profissional e Metodologia Unified Process
“How do you eat an elephant? One bite at a time!” Autor desconhecido
Para contextualização das atividades desenvolvidas será efetuado de seguida um breve enquadramento do Fundo de Garantia Salarial e do respetivo projeto.
3.1. Descrição do Fundo de Garantia Salarial
O Fundo de Garantia Salarial foi instituído em 1999 (17), na sequência de compromissos decorrentes do acordo de concertação estratégica e da tentativa de aproximar a lei nacional às legislações dos Estados membros, na matéria de proteção dos trabalhadores assalariados, em caso de insolvência do empregador.
Este Fundo foi criado com o objetivo de assegurar o pagamento dos créditos emergentes do contrato de trabalho e da sua violação ou cessação, aos trabalhadores que, reunindo as condições legalmente estabelecidas, o requeiram, nas situações em que o empregador seja judicialmente declarado insolvente ou que tenha iniciado o procedimento de conciliação (18).
O Fundo é dotado de personalidade jurídica e autonomia administrativa, patrimonial e financeira. No entanto, por razões de racionalidade de gestão de recursos públicos e de celeridade de estruturação institucional, o funcionamento do Fundo é assegurado através da estrutura orgânica do Instituto de Gestão Financeira da Segurança Social, I.P. (IGFSS, I.P.), designadamente das respetivas delegações distritais, que lhe prestaram apoio financeiro, administrativo e logístico (19).
Em 2001 o Fundo começou a desenvolver a sua atividade, com base em suportes de informação rudimentares (folhas de cálculo em MS Excel, bases de dados em MS Access, etc.), que se mostravam suficientes para responder ao pequeno número de requerimentos que existia no momento. No entanto, esse número foi rapidamente aumentando, tornando os métodos existentes insustentáveis, quer pela morosidade, quer pela falta de uniformidade no tratamento desses requerimentos.
Compare-se os valores publicados da dívida ao Fundo (equivalente aos valores pagos) em 2002, de 10.966,25€ (20), com o valor de 2005 e 2006, de 39.974,50€, 40.134,20€, respetivamente (21). Este aumento significativo da receita vem sublinhar a pertinência da uniformização e autonomização dos processos.
Neste sentido, em 2005, o IGFSS, I.P. solicitou ao II, I.P. o desenvolvimento de um subsistema para apoiar as atividades desenvolvidas pelo Fundo, nomeadamente em termos de apreciação de requerimentos, controlo do procedimento administrativo, pagamento dos créditos, recuperação de créditos e apoio à gestão.
Esperava-se que esse subsistema permitisse melhorar a eficácia e uniformidade das atividades e pudesse ser integrado no sistema de informação da segurança social, de modo a beneficiar da partilha de informação entre os vários subsistemas.
O desenvolvimento deste sistema permitiria ainda constituir uma base de dados estatística, garantindo assim o acesso mais eficaz e célere a toda a informação de apoio à gestão. Esta base de dados seria constituída apenas a partir da entrada em produção do sistema, dado que a não sistematização dos dados existentes inviabilizava qualquer processo de migração.
3.2. Análise da Atividade Profissional no Projeto Fundo de Garantia Salarial e enquadramento na Metodologia Unified Process
Para a discussão e aprofundamento das atividades desenvolvidas no projeto Fundo de Garantia Salarial (FGS) é fundamental relembrar que, em termos de cadeia de valor (ver figura 4 – Cadeia de Valor do II, I.P.) as minhas atividades enquadram-se essencialmente no âmbito dos Processos de Realização, e mais em particular neste projeto, nos macroprocessos de Gestão de Projetos e Gestão de Entregas.
Esta questão é relevante na medida em que a análise apresentada de seguida terá sempre como fio condutor estes macroprocessos, nomeadamente em termos de objetivos, etapas, e principais entregáveis.
No que diz respeito à metodologia salienta-se que o II, I.P. utiliza uma metodologia própria, desenvolvida com base em metodologias OO (Object-Oriented), nomeadamente na metodologia UP (Unified Process), que faz uso extensivo da linguagem UML (Unified Modeling Language).
Sendo o FGS um projeto de desenvolvimento de software, foi também obrigatoriamente seguida a metodologia UP adaptada ao II, I.P. para a gestão do ciclo de vida de desenvolvimento de sistemas de informação. Por esse motivo, a análise seguinte terá por base a metodologia UP. As especificidades da metodologia do II, I.P. não serão citadas por não serem de domínio público.
3.2.1. Macroprocesso de Gestão de Projetos
Em 2005, tal como referi anteriormente, após um período inicial de formação e colaboração em atividade de análise em diferentes projetos, na então designada Unidade de Sistemas de Informação, fui nomeada pelo conselho diretivo do II, I.P. responsável pelo projeto Fundo de Garantia Salarial (FGS). Esta nomeação é em si já uma das etapas do macroprocesso de Gestão de Projetos.
No geral este processo aplica-se a todos os projetos realizados no II, I.P. e tem como objetivos definir o projeto e a respetiva equipa, identificar os principais pontos de controlo do projeto e acompanhar o mesmo até à assinatura do termo de aceitação do projeto pelo cliente.
Como responsável de projeto, a minha principal missão neste macroprocesso foi definir o projeto, em termos de propósito de valor, indicadores de desempenho e fatores de risco, efetuar a análise de exequibilidade e propor a equipa de projeto.
Um dos aspetos a salientar desta etapa diz exatamente respeito à equipa de projeto.
Em projetos mais simples é habitualmente identificado o dono/patrocinador, ou sponsor do projeto do lado do cliente, o que nos permite traçar planos de comunicação e decisão relativamente simples. Neste projeto, o facto do funcionamento do Fundo ser assegurado pelo IGFSS, I.P. e delegações distritais, significava que os futuros utilizadores do subsistema seriam colaboradores do IGFSS, I.P., mas também do ISS, I.P., por serem os principais responsáveis pelas equipas distritais.
Assim sendo, houve necessidade de identificar dois sponsors do projeto do cliente (para além do sponsor do II, I.P.) e respetivas equipas. Este facto tornou os planos de decisão e comunicação mais complexos e por vezes mais morosos, dado que era necessário em cada circunstância estabelecer compromissos em relação a prioridades ou interesses individuais de cada uma das instituições. Sponsors diferentes representam visões diferentes daquilo que se pretende e esse é o cerne da dificuldade (22).
Os objetivos do projeto foram definidos em consonância com os objetivos estratégicos definidos no plano de atividades (23), o que resultou na definição dos seguintes objetivos para o projeto:
Pagamento atempado aos trabalhadores dos créditos garantidos pelo FGS; Combate à utilização e atribuição indevida dos créditos garantidos pelo FGS; Maior controlo da dívida das Entidades Empregadoras;
Melhoria da cobrança da dívida das Entidades Empregadoras ao FGS e à Segurança Social;
Criação e manutenção de uma base de dados de direitos e deveres, contribuindo para a melhoria da qualidade de serviço e aproximação do sistema ao cidadão.
Definido o projeto, foi-lhe então atribuído o orçamento de 215.000,00€ (24), explicitado no respetivo plano de atividades. É importante referir que não cabe ao responsável de projeto, de acordo com a estrutura mista interna do II, I.P. gerir o orçamento do projeto. Essa gestão é efetuada pela estrutura funcional dos departamentos e da pool de recursos, cabendo ao responsável de projeto apenas a verificação das entregas contratualizadas.
3.2.2. Macroprocesso de Gestão de Entregas
Este macroprocesso prevê a implementação de serviços suportados por tecnologias de informação baseados numa perspetiva holística (pessoas, processos e tecnologias) e considerando as diversas atividades: planeamento, desenho, construção, testes, formação e implementação. Este processo é válido tanto para subsistemas em desenvolvimento, como para subsistemas em fase de manutenção.
Uma vez que este macroprocesso reflete todo o ciclo de vida de desenvolvimento de projetos de software, acaba por ser um espelho da metodologia desenvolvida pelo II, I.P. no desenvolvimento desse tipo de projetos.
Assim, à semelhança da metodologia UP, a metodologia do II, I.P. prevê a existência de quatro fases no ciclo de vida de desenvolvimento de projetos de software, nomeadamente (25): Conceção, Elaboração, Construção e Transição.
3.2.2.1 Fase de Conceção
O principal objetivo desta fase é obter uma visão, âmbito e aceitação homogénea do projeto perante todos os stakeholders, nomeadamente (26):
Estabelecer o âmbito e as condições de fronteira do sistema, dando ênfase à visão operacional, critérios de aceitação e o que é expectável que faça e não faça parte do produto final;
Discriminar os componentes mais críticos do sistema de informação, os cenários principais das funcionalidades que levaram a um maior impacto do desenho;
Exibir ou demonstrar pelo menos uma possível arquitetura para resolver alguns dos principais cenários;
Rever a estimativa do custo total da alteração e calendário; Rever os riscos identificados;
Preparar os ambientes de suporte das alterações.
Os trabalhos iniciaram-se pela construção do modelo de negócio, tal como preconiza a metodologia (26), recorrendo essencialmente à descrição dos processos de trabalho e a diagramas de atividade, tendo por base os objetivos do negócio e dos clientes.
Por se tratar de uma fase relativamente breve, e ainda destinada a avaliar a pertinência e exequibilidade do projeto, foi operacionalizada apenas por mim, com o apoio da Equipa de Verificação. Esta equipa foi constituída na sequência da definição da metodologia do II, I.P., com o objetivo de validar os entregáveis de cada uma das fases e validar a passagem à fase seguinte. Apesar de não ser a sua missão, frequentemente, as pessoas desta equipa tiveram um papel de mentores, de extrema importância na formação dos restantes colaboradores, em matéria de metodologia e standards do II, I.P.
Um dos aspetos principais desta fase (25), e deste projeto em particular, consistiu na definição do âmbito. Em primeiro lugar por se tratar de um novo projeto, com a condicionante de os utilizadores não utilizarem anteriormente nenhum sistema de informação.
Outra dificuldade relevante na definição do âmbito do projeto pendeu-se com o facto de se tratar de um negócio com um período recente de funcionamento, que fazia com que ainda não existissem processos homogéneos ou nem tão pouco definidos.
A falta de consolidação dos processos de negócio representou também a principal dificuldade na etapa seguinte da metodologia, ou seja, a instabilidade na definição dos requisitos macro do sistema (26).
Esta instabilidade de requisitos para além de representar um importante risco para o projeto, afetava o planeamento dos outros subsistemas com o qual o FGS teria que interagir. Por exemplo, se existissem importantes alterações em termos de definição do processo de gestão da dívida das entidades empregadoras, todas as funcionalidades que o subsistema de Gestão de Conta-corrente (GC) teria que desenvolver, para o interface com o FGS, poderiam estar também em causa.
Nos casos em que a indefinição dos processos estava associada a questões político-legislativas, optou-se por excluir nessa fase esses mesmos processos do âmbito do sistema. Por exemplo, ficou fora do âmbito do sistema a gestão da dívida do FGS à Segurança Social e às Finanças (dado que o Fundo, à semelhança das entidades empregadoras, retém o valor das quotizações para a segurança social e dos impostos, alguns stakeholders entendiam que quando fosse iniciado o processo de recuperação de créditos deveriam ser pagos os valores retidos, à segurança social e às finanças, mas isso não estava estabelecido legalmente).
Os requisitos constituíram a base para o modelo de análise do sistema, que nesta fase consistia essencialmente, e tal como prevê a metodologia (26), numa primeira versão do modelo de domínio e do diagrama de casos de uso. No diagrama de casos de uso foram identificados os atores e principais interfaces com os outros subsistemas.
O facto de não existir migração de dados representou, por um lado uma simplificação em termos técnicos do projeto e por outro lado, um desafio em termos de gestão das expectativas dos clientes, dado que limitava o potencial de algumas funcionalidades a curto prazo. Por exemplo, a gestão da dívida das entidades empregadoras para os requerimentos já deferidos e pagos era inviável (em termos de custo benefício) no novo sistema.
A gestão da expectativas e gestão da mudança mereceu também mais atenção nas situações em que o novo sistema perspetivava um aumento de esforço, do ponto de vista das equipas de tratamento dos requerimentos, na medida em que passava a obrigar a algumas atividades anteriormente inexistentes, por exemplo em termos de registo de dados.
Em termos de arquitetura não foram identificadas nesta fase, nos requisitos funcionais e não funcionais, divergências que obrigassem à alteração da arquitetura genérica do SISS.
Contudo, chegou a ser efetuado um estudo de soluções workflow, pela exigência associada às atividades de controlo do procedimento administrativo. As soluções analisadas acabaram por ser abandonadas, por implicarem uma grande dependência dos respetivos fornecedores, sobretudo em termos de manutenção.
Após a conclusão desta fase decidiu-se avançar com o projeto. Devido à escassez de recursos internos disponíveis para a execução das fases seguintes, foi lançado um procedimento para aquisição dos serviços relacionados com essas fases, que se concretizou no início de 2006 (27).
Enquanto responsável de projeto coube-me, após a adjudicação do projeto, o controlo do projeto de acordo com o planeamento, em termos de timings e custos, a comunicação e negociação da solução com os clientes e fornecedores, o acompanhamento das provas de conceito e pilotos, a validação dos entregáveis previstos na metodologia (e revisão dos mesmos em termos de análise), bem como o reporte à gestão.
3.2.2.2 Fase de Elaboração e Construção
De acordo com a metodologia, o principal objetivo da fase de elaboração é o de definir uma arquitetura robusta como base para todo o desenho e construção do sistema (25).
De uma forma geral, são enumerados os seguintes objetivos para esta fase:
Assegurar que a arquitetura, os requisitos e os planos, são suficientemente estáveis e de que os riscos estão suficientemente mitigados, de modo a ser possível prever o custo e calendário finais do projeto;
Endereçar todos os riscos de arquitetura mais significativos do projeto;
Estabelecer uma arquitetura base através da análise dos cenários mais significativos, que normalmente expõem os principais riscos técnicos do projeto;
Produzir um protótipo de arquitetura (evolutivo ou não) com uma qualidade similar ao produto final em produção e produzir outros artefactos similares, como por exemplo protótipos de interface para validação com utilizadores finais;
Demonstrar que a arquitetura base possa manter os requisitos do sistema com um custo aceitável num período de tempo razoável;
Estabelecer um ambiente de suporte.
Uma vez que na fase de conceção se verificou que os requisitos não obrigavam à alteração da arquitetura genérica do SISS, a primeira fase dos trabalhos nesta fase consistiu em validar isso mesmo. Para isso construiu-se um pequeno protótipo das funcionalidades mais relevantes do sistema.
Segundo as orientações metodológicas, deveríamos ter escolhido os casos de uso mais complexos para este protótipo (25), por exemplo os que se relacionavam com o processo de recuperação de créditos. No entanto, como não foram identificados riscos em relação à metodologia foram escolhidas funcionalidades mais urgentes do ponto de vista dos utilizadores, para facilitar o processo de gestão das expectativas referido anteriormente.
Esse protótipo foi apresentado aos utilizadores numa sessão designada por prova de conceito, da qual resultou a validação da arquitetura.
A arquitetura do FGS, tal como a generalidade dos subsistemas dos SISS, segue o modelo de implementação representado pela seguinte figura (28):
Figura 5 - Arquitetura base do Sistema de Informação da Segurança Social
Tal como se pode observar, esta arquitetura é constituída por três camadas: a camada cliente, a camada aplicacional e a camada de base de dados.
Na camada cliente encontram-se os ecrãs e todos os componentes gráficos. É com esta camada que o utilizador interage, e é o único componente visível ao utilizador.
A camada aplicacional é a mais importante de todo o sistema. Isto porque é onde estão implementadas as regras de negócio que sustentam toda a lógica do sistema. Esta camada recebe os pedidos de camada cliente, resolve-os e devolve a resposta ao cliente. Caso necessite de dados persistentes, para despachar o pedido do cliente, invoca a camada de base de dados.
A camada de base de dados é responsável por guardar os dados de forma persistente numa base de dados, e de lê-los, aquando do pedido da camada aplicacional.
Associado a um dos princípios básicos desta metodologia - o de ser iterativa e incremental (25), existe uma regra/orientação (valiosíssima do meu ponto de vista) que consiste em focar cada uma dessas iterações nos principais riscos do projeto, antecipando o desenvolvimento das funcionalidades associadas aos maiores riscos.
Pela minha experiência isto garante uma boa parte do sucesso do projeto, na medida em que os riscos podem ser identificados atempadamente, permitindo estabelecer compromissos com o cliente para definir planos de implementação alternativos.
Seguindo esta orientação foram definidas, como funcionalidades prioritárias, todas aquelas que envolviam interação com outros subsistemas do SISS, permitindo assim mitigar a dependência do planeamento, quer das alterações necessárias nesses subsistemas, quer simplesmente da disponibilização dos serviços acordados.
3.2.2.3 Fase de Transição
A fase de transição do projeto foi aquela que representou maior esforço em termos de controlo de recursos, devido ao número de equipas envolvidas nesta fase.
Paralelamente à equipa de fornecedores, nesta fase foi necessário acompanhar mais de perto as equipas internas, de testes funcionais, de bases de dados, de implementação e de formação, dado que todos os trabalhos se encontravam no caminho crítico.
Nesta fase, foi definida e implementada a estratégia de gestão da mudança, que de uma forma geral, estabelecia o plano de realização de pilotos, de transição do sistema propriamente dito, de formação e apoio aos utilizadores.
Nas sessões de piloto disponibilizava-se a versão cliente a um grupo de utilizadores-chave pré-identificados, que eram responsáveis por efetuar os testes funcionais e validar a passagem a produção (em simultâneo à validação interna efetuada pela equipa de verificação), quando já estivessem resolvidos os incidentes relevantes.
Para além da formação dos 80 utilizadores diretos (23), efetuada por equipas internas foi ainda formada a equipa de helpdesk, responsável pela primeira linha de apoio aos utilizadores. Foram também identificados utilizadores-chave dos clientes que ficaram responsáveis pelo apoio imediato dos utilizadores e reporte de incidentes ao II, I.P.
Paralelamente, foi construído um manual utilizador da aplicação e de procedimentos relativos à instrução e tratamento dos processos, para facilitar a passagem de conhecimentos e garantir a uniformização de procedimentos.
Em termos funcionais o Fundo centralizou as atividades de decisão nos serviços centrais do IGFSS, I.P. e descentralizou as atividades de contacto com os beneficiários (para gestão do requerimento) e com os tribunais (para gestão dos processos de recuperação de dívida), nos serviços distritais, ou seja, nos 18 Centros Distritais de Portugal Continental, 3 nos serviços distritais da Região Autónoma dos Açores e 1 na Região Autónoma da Madeira.
Tendo em conta a dimensão dos serviços, definiu-se um plano faseado de entrada em produção, começando pela entrada em produção nos serviços centrais e no Centro Distrital com maior número de processos, Lisboa, seguindo-se o resto do país.
Assim, e de acordo com o plano definido a 14 de setembro de 2006 entrou em produção o FGS no distrito de Lisboa, seguindo-se em 3 de outubro a entrada em produção no resto do país.
Após o termo da fase de apoio inicial aos utilizadores e da resolução dos incidentes críticos, foi assinado o termo de aceitação do projeto pelo II, I.P. e clientes, fechando desta forma o macroprocesso de Gestão de Projetos, tal como está definido no II, I.P.
Nos anos posteriores o projeto entrou em manutenção evolutiva e corretiva, cobrindo atualmente a maioria das funcionalidades solicitadas pelos clientes, nomeadamente nas
matérias de apreciação dos requerimentos, controlo do procedimento administrativo, pagamento dos créditos, recuperação de créditos e apoio à gestão.
Em jeito de síntese apresentam-se alguns números relativos ao projeto e ao atual subsistema:
Tabela 1 - Dados do projeto FGS
Ano Orçamento/Custo Recursos
Humanos Início Fim Atividades Fonte
2005
215.000,00€ (orçamento estimado em 2005, e não executado)
6,1 (estimados) 09-02-2005 04-08-2005
Reuniões de Kick-off. Fase de Conceção. Processo de subcontratação do desenvolvimento da aplicação (23) (24) 23-01-2006 13-10-2006 Fase de Elaboração 15-02-2006 27-10-2006 Fase de Construção 2006 240.731,00€ (custo total efetivo) Recursos internos: 4.473 horas (efetivas) Análise e Desenvolvimento Subcontratado 20-06-2006 03-11-2006
Fase Transição. Fase de acompanhamento inicial em produção
(23)
Tabela 2 - Dados da aplicação FGS (sem referências)
Utilizadores diretos Utilizadores diretos, incluindo informativo Número Processos Registados por Ano Valores Pagos
por Ano Metodologias/Ferramentas
80 3.577 27.410 210 milhões de
euros
Unified Process adaptada ao II, I.P.
(metodologia de desenvolvimento de projeto) JAVA (J2EE) (linguagem de programação)
Tortoise SVN/PVCS (controlo de versões)
SQL Developer (bases de dados)
ModelMart (modelo de dados)
Forte for Java EE (ecrãs)
EasyVista/remedy (helpdesk)
Bugzilla/track-record (gestão de incidentes) 3.2.3. Considerações Finais
O último entregável proposto pela metodologia do II, I.P. exige um exercício de reflexão sobre as lições aprendidas ao longo do projeto, resultando num documento que constitui um balanço das boas práticas e dos aspetos a melhorar nos projetos futuros. No documento elaborado, a equipa salientou como boas práticas a realização de reuniões semanais com as equipas de fornecedores e clientes, com elaboração das respetivas atas. Para além das atas, a equipa salientou ainda a qualidade da restante documentação do projeto, pelo facto de ter sido uma excelente ajuda na fundamentação de decisões, na facilitação dos pontos de situação do projeto e na constituição de uma base de dados de conhecimento para a gestão de projetos no II, I.P..
Salientou-se o envolvimento das equipas dos clientes. A título de exemplo, referiu-se que foram apresentadas nas reuniões iniciais as noções básicas da metodologia, o que permitiu que grande parte dos casos de uso e regras de negócio fossem validadas pelas próprias equipas dos clientes.
Como aspetos a melhorar, salientou-se a necessidade de clarificação do tipo de testes a efetuar ao longo do projeto, dado que isso não tinha ficado muito claro no plano inicial, gerando conflito de expetativas entre as diferentes equipas.
Também como aspetos a melhorar, salientou-se a necessidade de chegar a um acordo no inicio do projeto, com a equipa de verificação, relativamente aos entregáveis necessários, uma vez que estes dependem de projeto para projeto. Adiar esse acordo, para o momento das entregas, pode por em causa a fundamentação utilizada.
O facto do projeto FGS ter sido desenvolvido de raiz, permitiu-me adquirir experiência em todas as fases do ciclo de vida de projetos de desenvolvimento de software, o que contribuiu bastante para o meu desenvolvimento profissional na gestão deste tipo de projetos. Este projeto foi ainda mais representativo no que diz respeito à consolidação dos conhecimentos em UML e nas metodologias OO (em particular na metodologia do II, I.P.), adquiridos previamente em formação, pelo que esse será o tema desenvolvido no subcapítulo seguinte. Por outro lado, as competências que adquiri ao longo do meu percurso profissional, em termos de planeamento, orientação para objetivos, capacidade de comunicação com clientes e fornecedores, foram também importantes contributos para o sucesso deste projeto.
3.3. Discussão da Metodologia Unified Process
O objetivo deste subcapítulo é apresentar um breve tutorial associado às metodologias OO (Object-Oriented), nomeadamente à metodologia UP (Unified Process), tendo por base a formação que recebi nesse âmbito e a minha experiência profissional, nomeadamente no projeto descrito anteriormente.
Com este tutorial pretende-se apresentar as melhores práticas no âmbito desta linguagem e metodologias, não sendo o foco a análise da linguagem ou das metodologias per se. Também não é objetivo deste tutorial explorar novos caminhos no desenvolvimento de software.
3.3.1. Conceitos
3.3.1.1 Object-Oriented Modeling
A visão tradicional do desenvolvimento de software (29) tem uma perspetiva algorítmica, segundo a qual o principal alicerce de todo o software são os requisitos funcionais. Esta visão leva os construtores do sistema a concentrarem-se apenas no detalhe desses requisitos, o que não seria intrinsecamente incorreto, exceto pelo facto de tender a produzir sistemas frágeis, porque os requisitos do sistema mudam e crescem tornando estes sistemas muito difíceis de manter.
A visão contemporânea do desenvolvimento de software (29) tem uma perspetiva orientada a objetos (Object-Oriented), segundo a qual o principal alicerce de todo o software são objetos ou classes (object/class). De uma forma simples, pode-se dizer que neste contexto um objeto é a representação específica de uma entidade, geralmente obtida a partir do vocabulário do problema ou da solução e uma classe é um molde que representa um conjunto de objetos comuns.
Esta abordagem tornou-se muito utilizada por se poder aplicar na construção de sistemas de todo o tipo de domínio, tamanho ou complexidade e também por ir de encontro às linguagens
