Utilização da Metodologia Unified Process e Reflexão sobre ... · Reflexão sobre a Complexidade...

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

Faculdade de Engenharia da Universidade do Porto

Mestrado Integrado em Engenharia Industrial e Gestão

2012-07-11

Desenvolvimento de Sistemas de Informação: Metodologia Unified Process e Complexidade Legislativa

ii

Dedico este trabalho a todas as pessoas com quem trabalhei até hoje

e que gostam de trabalhar.


iii

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


iv

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


v

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.


vi

Í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

ANEXO I: ESTUDO SOBRE A FEITURA DAS LEIS: PORTUGAL E A EUROPA................................72


vii

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

UP Unified Process


viii

Í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


ix

Í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

Tabela 7 - Alguns dos artefactos previstos nas diferentes fases do ciclo de vida dos projetos ........... 68


1

1. Introdução

1.1. Motivação

Nos ú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

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.


3

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.


4

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é.


5

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 AplicacionaisTransversais

Soluções Aplicacionais

da Segurança Social

e Reabilitação

Soluções Aplicacionaisdo Emprego,

FormaçãoProfissional e

RelaçõesLaborais

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


6

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.


7

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.


8

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.


9

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


10

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.


11

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..

Figura 4 - Sistema de Informação da Segurança Social, 2010


12

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”;

� “Capitalizar os investimentos já efectuados em sistemas de informação”.


13

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.


14

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.


15

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.


16

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).


17

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).


18

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.


19

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.


20

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


21

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.


22

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 de programação, sistemas operacionais e ferramentas atuais, igualmente orientadas a objetos.


23

3.3.1.2 Unified Modeling Language

Unified Modeling Language™ - UML - é a especificação adotada pela Object Management Group (OMG)1 para o desenvolvimento de software orientado a objetos (30).

UML é uma linguagem (notação com semântica associada) para visualizar, especificar, construir e documentar os artefactos de um sistema com uma componente intensiva de software (29).

Entende-se por artefactos, parte de informação associada a uma versão, que é produzida, modificada ou usada por um processo; pode ser um modelo, elementos de um modelo ou um documento. (26)

UML não é uma metodologia nem uma linguagem de programação, trata-se de um standard aberto que se baseia na experiência e necessidades de utilizadores e que se aplica a todo o ciclo de vida do software, modelação do negócio, modelação de requisitos e modelação da solução.

Sendo uma linguagem de modelação o UML fornece um vocabulário e regras de comunicação focadas em representações conceptuais e físicas do sistema. Esse vocabulário e regras permitem criar bons modelos mas não especificam quando, nem como, devem ser criados. Esse é o papel do processo de desenvolvimento.

Um modelo (model) no contexto do desenvolvimento de software é uma representação simplificada da realidade que ajuda a equipa de projeto a compreender certos aspetos da complexidade inerente ao software.

3.3.1.3 Unified Process

A definição de Unified Process (25) enquadra-se na definição geral de processo, ou seja: um conjunto de atividades que uma equipa realiza para transformar um conjunto de requisitos dos clientes num sistema de software. No entanto, Unified Process também é também um framework (estrutura do processo) genérica que as pessoas podem adaptar, adicionando e removendo atividades com base nas necessidades e recursos disponíveis para um determinado projeto. O Unified Process faz uso extensivo da linguagem UML.

3.3.1.4 Rational Unified Process

IBM Rational Unified Process® - RUP® - é um framework de processo de engenharia de software, criado pela Rational Software Corporation e adquirido pela IBM, que disponibiliza um conjunto de boas práticas, tendo em vista a produção de software de alta qualidade, dentro de prazos e orçamentos determinados (31).

1 OMG é um consórcio internacional sem fins lucrativos, fundado em 1989, cuja missão é desenvolver,

conjuntamente com os seus membros, standards abertos, na área das tecnologias orientadas a objetos.


24

3.3.2. Boas Práticas em Projetos de Desenvolvimento de Software

3.3.2.1 Problemas Associados a Projetos de Desenvolvimento de Software

O que pode estar na origem do insucesso de alguns projetos de desenvolvimento de software?

Segundo alguns autores (26), tanto os projetos mal sucedidos como os que apresentam piores desempenhos (por exemplo, projetos que não respeitam prazos e/ou custos acordados, sistemas impossíveis de manter ou com custos muito elevados de manutenção) apresentam um conjunto de sintomas semelhantes, que resultam da combinação dos seguintes fatores:

� Compreensão incorreta das necessidades dos utilizadores;

� Incapacidade para lidar com mudanças de requisitos;

� Software difícil de manter ou estender;

� Descoberta tardia de falhas no projeto;

� Fraca qualidade e performance do software;

� Descoordenação no trabalho de equipa;

� Módulos que não se ajustam corretamente uns aos outros;

� Falta de fiabilidade no processo build-and-release.

Como principais causas para estes problemas são enumeradas as seguintes:

� Gestão de requisitos deficitária;

� Comunicação ambígua e imprecisa;

� Arquiteturas frágeis;

� Complexidade exagerada;

� Inconsistências não detetadas entre requisitos, desenhos e implementações;

� Testes insuficientes;

� Avaliação subjetiva do estado do projeto;

� Redução de risco tardia devido ao desenvolvimento em cascata;

� Propagação não controlada de mudanças.

Entende-se (26) que tratando estas causas é possível não só eliminar os problemas, como também garantir o desenvolvimento e manutenção da qualidade do software. A adoção de abordagens comprovadas comercialmente para desenvolvimento de software é a estratégia mais generalizadamente utilizada na indústria por organizações de sucesso no tratamento destas causas, que se traduz em parte pela adoção das boas práticas a seguir apresentadas.


25

3.3.2.2 Desenvolvimento Iterativo e Incremental de Software

Na abordagem tradicional do processo de desenvolvimento de software em cascata, o processo avança linearmente da análise dos requisitos, para o desenho do sistema, posteriormente, para o código e testes unitários, e por fim, para os testes dos subsistemas e do sistema.

O problema deste tipo de abordagens (26) é que elas tendem a camuflar os riscos do projeto até ser demasiado tarde para poder fazer alguma coisa significativa para os controlar.

A abordagem alternativa é o desenvolvimento iterativo e incremental.

A essência desta abordagem (32) diz respeito ao desenvolvimento de uma aplicação através de aproximações sucessivas. Primeiro é desenvolvido um protótipo inicial, posteriormente esse protótipo é refinado, melhorado e alargado, através de vários ciclos de iterações, cujo número depende da complexidade da aplicação.

Pode-se dizer que cada ciclo resulta num protótipo que se vai desenvolvendo por aproximações sucessivas até se alcançar uma aplicação considerada completa, tal como se pretende mostrar na figura seguinte (32).

Figura 6 - Uma abordagem iterativa e incremental do desenvolvimento orientado a objetos

De acordo com esta abordagem, o desenvolvimento inicia pela definição do âmbito e dos requisitos macro para todo o projeto, criando uma descrição de alto nível de toda a aplicação. Nesta fase documenta-se o que o sistema vai fazer, quem o vai utilizar e quais as restrições ou critérios de aceitação do mesmo. Este modelo de alto nível permite representar todos os objetos de negócio que são necessários para a aplicação e dá-lo a conhecer aos utilizadores, funcionando assim como uma espécie de “contrato” entre os utilizadores e quem está a desenvolver o sistema.

Depois de conhecer âmbito total da sua aplicação, seleciona-se uma parte da aplicação que será desenvolvida em primeiro lugar – o protótipo inicial.


26

Algumas pessoas sugerem que se deve iniciar pelo desenvolvimento da parte mais difícil da aplicação. De acordo com a minha experiência, isto é particularmente importante se existir alguma incerteza sobre a arquitetura ou interfaces da aplicação. Nessa situação, o protótipo pode “não fazer muito”, ou seja ter ainda poucas funcionalidades e eventualmente até incompletas, mas permite à equipa de projeto testar os aspetos de maior incerteza, para avançar com o restante desenvolvimento apenas quando estiver segura de que é uma solução adequada.

Por outro lado, se não existirem questões da arquitetura a verificar, pode-se desenvolver em primeiro lugar as funcionalidades prioritárias para os utilizadores, para que estes verifiquem se o sistema satisfaz as suas necessidades. Tal como foi referido no subcapítulo anterior, esta foi a opção tomada no projeto FGS, pelo facto dos utilizadores não terem experiência na utilização de aplicações, o que podia levantar alguns problemas de aceitação da mesma.

Depois do desenvolvimento do protótipo inicial deve ser definido um plano de todas as iterações seguintes (ou ciclos seguintes). Obviamente isso pode ser alterado, em função de problemas que venham a ser identificados, mas ainda assim já deve ser possível identificar o número de iterações e as funcionalidades a desenvolver em cada uma delas (alto nível). Para a identificação destas iterações devem ser identificados os riscos associados ao projeto e às funcionalidades. Tal como para o protótipo inicial, esses riscos é que vão definir aquilo que deve ser efetuado de seguida.

Resumidamente, a grande vantagem do método iterativo é antecipar os riscos (associados aos recursos, ao negócio ou técnicos), de tal forma que ainda seja possível evitá-los, endereça-los ou mitigá-los, em vez de viver o pânico na véspera das entregas.

Uma outra importante vantagem é envolver todos os stakeholders (utilizadores, analistas, arquitetos, programadores, testers, gestores de projeto, formadores, etc.) desde o início do projeto, o que facilita bastante a comunicação e gestão de conflitos, em prol da resolução dos problemas que possam surgir no decorrer do projeto.

Por último, o método iterativo proporciona uma arquitetura bastante robusta, na medida em que os erros vão sendo continuamente corrigidos ao longo das várias iterações.

3.3.2.3 Gestão de Requisitos

“A requirement is a condition or capability a system must meet.” (26)

“Functional requirements define the behavior of the system from user’s perspective and Non-Functional requirements define the qualitative characteristics of the system” (22)

O grande desafio na gestão dos requisitos no desenvolvimento de software está associado ao facto dos requisitos serem dinâmicos, o que faz com que alterem no decorrer do ciclo de vida do projeto. Além disso, a identificação dos requisitos é um processo contínuo. Por isso, a menos que o sistema seja muito simples, é praticamente impossível ter os requisitos todos identificados antes de iniciar o desenvolvimento. Sobretudo porque, à medida que o sistema vai estando construído, a compreensão dos requisitos pelos utilizadores também vai alterando.

A gestão dos requisitos envolve três atividades: identificar, organizar e documentar as funcionalidades e restrições do sistema; analisar as alterações dos requisitos e avaliar o respetivo impacto; acompanhar e documentar as soluções de compromisso (trade-offs) e decisões (26).

Os analistas responsáveis pelo levantamento de requisitos devem ter boas competências de comunicação, e mais especificamente, experiência/habilidade na condução de entrevistas, já


27

que é desta forma que habitualmente os requisitos são identificados. Uma dessas competências, porventura a principal, é saber ouvir. Por vezes, no decorrer da entrevista os utilizadores fazem comentários laterais importantíssimos, que podem passar despercebidos se o analista não estiver concentrado. E concentrado, não é só estar focado no tema, mas também (e sobretudo) não estar a pensar no que o próprio pensa que o sistema devia fazer.

Organizar e documentar os requisitos permite priorizar, rastrear e filtrar os mesmos, facilitando o planeamento do projeto e a comunicação com os utilizadores. Isto pode reduzir os custos e atrasos no projeto e promover desde o início o envolvimento dos utilizadores.

A principal medida de qualidade de um sistema é se ele faz aquilo que é suposto fazer (26). E isso obviamente só é possível se todos os stakeholders tiverem o mesmo entendimento sobre o que deve ser feito.

3.3.2.4 Uso de Arquiteturas Baseadas em Componentes

A arquitetura de software centra-se na estrutura e comportamento do sistema, bem como na sua usabilidade, acessibilidade, fiabilidade, disponibilidade, escalabilidade, performance, segurança, extensibilidade, suportabilidade, etc.

Arquiteturas robustas são importantes porque permitem importantes ganhos de reutilização, facilitam a divisão do trabalho entre as várias equipas de desenvolvimento, diminuem as dependências entre hardware e software (sujeitos a mudanças) e facilitam a manutenção do sistema.

A arquitetura de software baseada em componentes é uma abordagem importante porque permite a reutilização ou customização de componentes, das inúmeras fontes comercialmente disponíveis (26).

O uso de arquiteturas baseadas em componentes, associado à abordagem iterativa promove a melhoria contínua da arquitetura do sistema, porque cada iteração produz um produto de arquitetura que pode ser medido, testado e avaliado face aos requisitos do sistema.

Visualizar, especificar, construir e documentar um sistema intensivo de software implica a visão do sistema de diferentes perspetivas. Cada um dos stakeholders olha para o sistema de uma maneira diferente, em momentos diferentes ao longo da vida do projeto. A arquitetura do sistema é provavelmente o entregável mais importante para gerir esses vários pontos de vista ao logo do ciclo de vida do projeto e combater continuamente os riscos mais importantes do projeto.

3.3.2.5 Modelação

“We build models of complex systems because we cannot comprehend such a system in its entirety.” (29)

Um modelo é uma representação simplificada da realidade que permite ultrapassar os limites da capacidade humana para compreender a complexidade. Assim, através de modelos podemos analisar um determinado problema focando um aspeto de cada vez - “dividir-para-conquistar” - ou seja, dividir um problema complexo em uma série de pequenos problemas de fácil resolução.

No desenvolvimento de software, a construção de modelos permite visualizar, especificar, construir e documentar a estrutura e comportamento do sistema. A utilização de uma linguagem de modelação, como o UML, permite uma comunicação clara (sem ambiguidade) entre todos os elementos da equipa de desenvolvimento.


28

As ferramentas de modelação facilitam a gestão dos modelos, porque permitem esconder ou expor os detalhes de acordo com o que for necessário e permitem manter a consistência entre os diferentes artefactos do sistema. Algumas ferramentas permitem também a sincronização entre os modelos e o código fonte, o que pode facilitar bastante as alterações (26).

Em UML (29) os diferentes modelos são construídos a partir de blocos de construção básicos, tais como classes, interfaces, colaborações, componentes, nós, dependências, generalizações e associações. Por sua vez, os diagramas são o meio de visualização desses blocos de construção. O UML define um conjunto de diagramas focados em diferentes aspetos, que permitem a compreensão de sistemas complexos.

Tipicamente os diagramas que permitem uma visão estática do sistema são:

� Diagrama de classes

� Diagrama de objetos

� Diagrama de componentes

� Diagrama de deployment

E os diagramas que permitem uma visão dinâmica do sistema são:

� Diagrama de casos de uso

� Diagrama de sequência

� Diagrama de colaboração

� Diagrama de estados

� Diagrama de atividade

Para descrição e exemplo de cada um destes diagramas, ver anexo E.

3.3.2.6 Verificação Contínua da Qualidade do S oftware

Os problemas de software (26) são 100 a 1000 vezes mais caros para localizar e reparar após a implementação, pelo que se torna muito importante avaliar continuamente a qualidade do sistema em termos de funcionalidade, fiabilidade e desempenho.

Verificar a funcionalidade de um sistema - a maior parte das atividades dos testes - envolve a criação de testes para cada cenário chave, cada um dos quais representa o comportamento desejado de algum aspeto do sistema. Como o desenvolvimento é efetuado de forma iterativa, em cada iteração são analisados os cenários que falharam e onde, num processo de avaliação quantitativa e contínua.

A avaliação objetiva permite expor as inconsistências dos requisitos, do desenho e da implementação do sistema e se detetados prematuramente reduzem significativamente os custos do projeto.

No desenvolvimento de software a qualidade pode ser vista em duas vertentes: qualidade do produto e qualidade do processo. A qualidade do produto foca-se no software produzido e nos elementos que o compõe, nomeadamente componentes, arquitetura, etc. A qualidade do processo foca-se na observação do critérios de qualidade observados durante a produção do


29

software, bem como na qualidade dos artefactos produzidos (planeamento das iterações, planos de testes, realização dos casos de uso, modelo de desenho, etc.).

3.3.2.7 Controlo de Alterações

No decorrer do ciclo de desenvolvimento são criados artefactos importantes que vão sendo modificados ao longo das várias iterações. Garantir a rastreabilidade dessas alterações e medir a evolução dos trabalhos é de tal forma importante para a integridade do software e para a gestão do projeto (monitorização das alterações, deteção precoce de problemas, etc.) que, regra geral, obriga à adoção de uma abordagem sistemática nesta matéria. Por isso, de acordo com as necessidades da organização são normalmente adquiridas ferramentas que facilitam a gestão destas alterações ao nível dos requisitos, desenho e implementação.

Da minha experiência estas questões devem ser acauteladas desde o início do projeto, definindo no ambiente de trabalho partilhado (workplace) uma estrutura standard dos artefactos, de acordo com a ferramenta de controlo de versões utilizada, e definindo métodos de trabalho que garantam a sincronização sistemática dos artefactos. Se a equipa de trabalho já tem alguma experiência em projetos de desenvolvimento de software é relativamente fácil de manter esta disciplina, porque a experiência de trabalhar sobre artefactos não sincronizados é algo que dificilmente se esquece!

Estas questões são tanto mais importantes quanto maiores forem os projetos e as respetivas equipas, mas quando assim é, maior é também a probabilidade destas ferramentas e métodos já estarem implementados.

3.3.3. Ciclo de Vida UML

Tal como já foi referido no subcapítulo anterior as metodologias UP (25), e o UML (29) preconizam a existência de quatro fases no ciclo de vida de desenvolvimento de projetos de software, nomeadamente: Conceção, Elaboração, Construção e Transição.

Conceção: O principal objetivo desta fase é o de obter uma visão, âmbito e aceitação homogénea do projeto perante todos os stakeholders.

Elaboração: O principal objetivo desta fase é o de definir uma arquitetura robusta como base para todo o desenho e construção do sistema.

Construção: O principal objetivo desta fase é o de clarificar os restantes requisitos que possam existir e o completar a implementação do sistema baseada na arquitetura base definida na fase anterior.

Transição: O principal objetivo desta fase é o de assegurar que o produto final está pronto para os utilizadores finais o poderem explorar.

Para mais detalhe dos objetivos das fases do ciclo de vida de desenvolvimento de software e exemplos dos artefactos produzidos ver anexo F.


30

Na figura seguinte, porventura a mais conhecida do UML, mostra a relação entre as fases do ciclo de vida do projeto e as disciplinas de desenvolvimento de software ao longo do tempo.

Figura 7 - Ciclo de vida de desenvolvimento de software

O aspeto inovador do UML e metodologia UP, tal como mostra a figura, é a assunção de que as disciplinas de desenvolvimento de software, requisitos, análise e desenho, implementação, etc. não só não se esgotam em determinadas fases do ciclo de vida, como também se mantém até ao final do mesmo, garantindo assim a génese iterativa e incremental deste modelo.

O número de iterações, outra das componentes da figura, é definido na fase de conceção após desenvolvido o protótipo inicial.

O número de iterações depende de projeto para projeto mas, pela minha experiência, é sempre preferível fazer iterações mais curtas (não mais de um mês) para que não decorra muito tempo sem que os entregáveis/artefactos percorram todas as disciplinas, de forma a manter os riscos controlados. Obviamente estas iterações também têm que ser definidas em função da “velocidade” da equipa, que normalmente pode ser avaliada em função de projetos anteriores.

3.4. Conclusão

O projeto Fundo de Garantia Salarial, por ter sido um projeto construído de raiz, permitiu-me contactar com todas as fases do ciclo de vida de desenvolvimento de software e, em particular, com a metodologia do II, I.P. que tal como a metodolofia UP, faz uso extensivo da linguagem UML.

Esta linguagem assenta numa abordagem de desenvolvimento de software através de aproximações sucessivas, que se designa por iterativa e incremental.

As metodologias UP associadas a esta abordagem definem um conjunto de boas práticas que promovem o sucesso dos projetos e a qualidade do software produzido.

A prática metodologia do II, I.P. permitiu-me por isso validar os fundamentos teóricos nestas matérias, que resultou na consolidação de conceitos e métodos apresentados neste capítulo.


31

4. Atividade Profissional e Complexidade Legislativa “The hardest thing in the world to understand is the income tax.”

Albert Einstein

Para contextualização das atividades desenvolvidas será efetuado de seguida um breve enquadramento do Desemprego e do respetivo projeto.

4.1. Descrição da Eventualidade de Desemprego

A Constituição da República Portuguesa (artigo 63º) (33) e a atual Lei de Bases da Segurança Social (artigo 2º) define que “todos têm direito à segurança social” (34).

“O sistema de segurança social abrange o sistema de protecção social de cidadania, o sistema previdencial e o sistema complementar” (artigo 23º, composição do sistema) (34).

“O sistema previdencial visa garantir, assente no princípio de solidariedade de base profissional, prestações pecuniárias substitutivas de rendimentos de trabalho perdido em consequência da verificação das eventualidades legalmente definidas” (CAPÍTULO III, Sistema previdencial, Artigo 50.º, Objectivos) (34).

Eventualidades abrangidas pelo sistema previdencial incluem (CAPÍTULO III, Sistema previdencial, Artigo 52.º, Âmbito material) (34):

a) Doença;

b) Maternidade, paternidade e adoção;

c) Desemprego;

d) Acidentes de trabalho e doenças profissionais;

e) Invalidez;

f) Velhice;

g) Morte.

A eventualidade de Desemprego é caracterizada por “toda a situação decorrente da perda involuntária de emprego do beneficiário com capacidade e disponibilidade para o trabalho, inscrito para emprego no centro de emprego” (35).

“A reparação da eventualidade de desemprego dos beneficiários abrangidos pelo regime geral de segurança social dos trabalhadores por conta de outrem é efectivada mediante a atribuição de prestações.”

“As prestações de desemprego têm como objectivo:

a) Compensar os beneficiários da falta de retribuição resultante da situação de desemprego ou de redução determinada pela aceitação de trabalho a tempo parcial;

b) Promover a criação de emprego, através, designadamente, do pagamento por uma só vez do montante global das prestações de desemprego com vista à criação do próprio emprego” (35).


32

4.2. Apresentação dos Subsistemas de Prestações Gerais , Desemprego e Layoff

Inicialmente, aquando ao desenvolvimento dos primeiros subsistemas de prestações, avançou-se com uma hipótese de arquitetura do sistema que pressupunha a existência de uma base aplicacional comum para as diferentes prestações. De acordo com essa hipótese, nesse sistema deveriam constar todas as funcionalidades semelhantes e a gestão das regras das diferentes prestações. As prestações seriam uma espécie de módulos, com as especificidades inerentes a cada uma delas.

Seguindo este pressuposto foi construído o subsistema de Prestações Gerais (PG), que serviu desde logo de base às prestações do âmbito de Desemprego e de Impedimentos Temporários para o Trabalho (maternidade, paternidade e adoção).

Esta hipótese acabou por ser abandonada mais tarde, quando o detalhe de outras prestações (por exemplo, Prestações Familiares) evidenciou diferenças significativas, que dificultavam a existência de uma base comum. Por outro lado, entendeu-se que esta base se tornaria quase insustentável em termos de gestão, quer pela dimensão, quer pela excessiva dependência gerada entre os diferentes subsistemas.

Mais recentemente iniciou-se um estudo de autonomização também dos subsistemas de Desemprego e Impedimentos Temporários para o Trabalho, para se poder responder de forma mais célere, as frequentes alterações legislativas nestas prestações.

Outra opção de implementação foi considerar as funcionalidades de Layoff como um módulo do subsistema de DES.

O Layoff (36) é uma redução temporária dos períodos normais de trabalho ou suspensão dos contratos de trabalho efetuada por iniciativa das empresas, durante um determinado tempo devido a: motivos de mercado; motivos estruturais ou tecnológicos; ou catástrofes ou outras ocorrências que tenham afetado gravemente a atividade normal da empresa; desde que tais medidas se mostrem indispensáveis para assegurar a viabilidade económica da empresa e a manutenção dos postos de trabalho. No período de tempo em que se aplica o regime de Layoff, os trabalhadores têm direito a receber uma compensação salarial paga diretamente ao trabalhador pela entidade empregadora. A Segurança Social comparticipa a entidade empregadora com 70% desse valor.

4.3. Análise da Atividade Profissional no Projeto Desemprego e Enquadramento na Problemática da Complexidade Legislativa

Após um período de acompanhamento inicial das atividades de manutenção no projeto FGS, manifestei o meu interesse pela gestão de projetos de maior dimensão, que representassem um maior desafio em termos de gestão de projeto.

Assim, em 2009 fui nomeada pelo Conselho Diretivo do II, I.P. responsável pelo projeto Desemprego, papel que ainda desempenho atualmente.

Para simplificar a discussão que se segue passará a ser referido simplesmente o subsistema de Desemprego (DES), ainda que grande parte das funcionalidades estejam implementadas no


33

sistema de Prestações Gerais, e que se estejam também a englobar, as funcionalidades relativas a Layoff.

Dado que o subsistema DES já estava desenvolvido a responsabilidade pela gestão do projeto Desemprego é apenas uma forma de descrever abreviadamente a responsabilidade pelas atividades de manutenção evolutiva e corretiva do subsistema DES e de todos os projetos que sejam constituídos no âmbito desse subsistema. Refira-se que são constituídos projetos sempre que as funcionalidades a implementar sejam de elevada complexidade, impacto ou duração.

Também neste projeto, em termos de cadeia de valor (ver figura 4 – Cadeia de Valor do II, I.P.) as minhas atividades enquadram-se essencialmente nos macroprocessos de Gestão de Projetos, Gestão de Entregas e Gestão de Alterações, tendo como atividades principais o planeamento do projeto, a comunicação e negociação da solução com os clientes e fornecedores, a validação dos entregáveis previstos na metodologia, e a execução/revisão de alguns entregáveis em termos de análise, 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.

4.3.1. Dimensão do Subsistema de Desemprego

Um dos principais aspetos a considerar, enquanto responsável pelo subsistema de DES, é a dimensão e o impacto social do mesmo. Essa dimensão reflete-se quer em termos de funcionalidades associadas, quer em termos de número de registos associados a essas funcionalidades.

No sentido de demostrar a dimensão deste subsistema apresenta-se de seguida a descrição geral das funcionalidades e alguns números relacionados com este subsistema.

Assim, em termos gerais2, pode-se referir que o subsistema de Desemprego engloba as seguintes funcionalidades:

Consulta (consulta das prestações e respetivos processos, consulta de layoff, consulta de dados gerais de outros subsistemas);

Registo (registo de pedidos de desemprego, registo de processos de layoff, registo de documentos);

Análise (análise de condições de atribuição, gestão dos diferentes estados e interface com o subsistema de despacho dos processo, Controlo de Processos Administrativos (CPA), reanálises de prestações de desemprego e layoff);

Gestão (registo de ações nas prestações: suspensões, cessações, reinícios, etc., correções, alterações, anulações, gerir a base de cálculo de IRS, gerir as quotas das entidades empregadoras, gerar equivalências de remunerações, reanálises e recálculos de prestações de desemprego e layoff);

2 Esta informação resulta da minha visão do sistema decorrente da experiência profissional.


34

Processamento (processar e lançar as prestações no subsistema de pagamento, Sistema Integrado de Conta Corrente (SICC), recalcular prestações de desemprego e layoff);

Emissão de Ofícios e Listagens (desemprego e layoff).

Refira-se ainda que este subsistema faz a gestão de interfaces com inúmeros subsistemas

internos, quer para atribuição das prestações, quer para controle das mesmas. Em termos de entidades externas salienta-se a interface com o Instituto do Emprego e Formação

Profissional, I.P. (IEFP), que permite a sincronização de dados de requerimentos de desemprego, bem como o cruzamento de toda a informação relevante gerida por estas entidades, no âmbito do Desemprego.

De modo a ilustrar a dimensão do sistema em termos de número de registos apresenta-se de seguida um conjunto de dados que traduzem o impacto desta eventualidade no sistema da segurança social.

Figura 8 - Distribuição percentual das despesas correntes da Segurança Social em 2010 (37)

Em termos de valores processados este volume representa um valor de cerca de 2 mil milhões/ano (2010), ou seja, cerca de 185 milhões/mês. Este valor tem aumentado, no decorrer da presente situação de crise económica, tal como ilustra a tabela seguinte.


35

Tabela 3 - Despesa da Segurança Social (Euro – Milhares) (38)

Despesa da Segurança Social

Prestações Sociais Anos

Total 1 Total 2 Familiares Doença e

Maternidade

Desemprego e Apoio ao Emprego

Pensões, Suplementos e Complementos

Rendimento Social de Inserção

2008 26.801.178,7 18.324.103,5 942.763,2 742.577,3 1.566.573,6 12.818.152,0 425.721,0

2009 29.577.376,8 20.110.363,5 1.136.984,5 850.875,8 2.045.184,9 13.464.650,4 507.708,9

2010 31.093.897,6 20.907.615,0 1.108.523,6 892.518,4 2.221.136,0 14.011.912,6 519.908,7

(1) Inclui ainda as rubricas: Subsídios à Formação Profissional e Outras Despesas

(2) Inclui ainda a rubrica: Outras

A tabela seguinte mostra o número de beneficiários com prestações de desemprego (com pelo menos um processamento no ano) entre 2008 e 2010.

Dado que as prestações de desemprego têm uma duração que pode ir de 270 a 900 dias (este período pode ser superior em função da atribuição do subsídio social de desemprego subsequente) (39), podemos dizer grosso modo que o número de prestações anuais não é muito diferente do número de prestações geridas mensalmente.

Tabela 4 – Prestações de Desemprego da Segurança Social (Indivíduo)1 (40)

Prestações Sociais 2008 2009 2010

Abono de Família (n.º de crianças e jovens) 1 813 882 1 849 587 1 821 906

Desemprego 459 535 564 055 599 239

Doença 549 264 584 728 546 042

Complemento Solidário para Idosos 179 520 232 818 246 656

Rendimento Social de Inserção (n.º de famílias) 160 542 192 249 206 700

(1) Beneficiários com pelo menos um processamento no ano

A tabela seguinte permite constatar o número de beneficiários desempregados sem direito a prestações de desemprego. Os requerimentos de desemprego que não reúnem condições para a atribuição de prestações (pedidos indeferidos) são também geridos pelo subsistema de DES.

Tabela 5 - Beneficiários das prestações de Desemprego no total de desempregados inscritos nos Centros de Emprego e Formação Profissional (Proporção - %) (41)

Prestações de desemprego

Anos Total Subsídio social de

desemprego Subsídio de desemprego

2008 72,4 22,5 50,4

2009 78,6 25,9 53,3

2010 57,3 12,1 45,3

2011 62,0 11,0 51,2


36

Esta dimensão reflete-se, em primeiro lugar, no número de pessoas envolvidas na manutenção do sistema e no número de utilizadores do mesmo. Fazendo uma inferência a partir dos valores das despesas (figura 8), podemos referir que desemprego corresponde a cerca de um décimo dos colaboradores/utilizadores globais, mesmo sem ter em conta os fatores de complexidade e de vida útil das prestações (obviamente uma pensão, uma vez atribuída, tem menos esforço, em termos de manutenção do que uma prestação de desemprego, já que estas podem alterar em função de inúmeros fatores).

Por outro lado reflete-se em termos de dimensão e crescimento de dados. Refira-se que o SISS tem em termos gerais um crescimento contínuo do volume de dados de mais 176Gb/mês (42).

Isto significa que, em termos de atividades de manutenção evolutiva, ganham especial relevo as atividades de expurgo e de gestão da capacidade dos sistemas, cujas execuções para os diferentes níveis (conforme o plano de expurgo definido pelo II, I.P.) têm que ser executadas impreterivelmente todos os anos, tal como os planos de recuperação de falhas que têm que estar permanentemente atualizados.

Outro dos fatores relevantes associados à dimensão deste projeto, porventura o mais importante, diz respeito à dimensão social das prestações envolvidas.

Sendo as prestações de desemprego substitutivas de remunerações (compensam a falta de remunerações por ausência de trabalho), pode-se deduzir que uma importante percentagem da população portuguesa depende destas prestações como forma de subsistência (39).

Este fator representa uma enorme responsabilidade para com essas pessoas e respetivos agregados familiares, beneficiários destas prestações, que é diretamente proporcional à pressão exercida pelos restantes stakeholders. Nomeadamente, a comunicação social, uma vez que são prestações muito mediáticas, pela importância social, política e económica a que estão associadas.

Em termos de gestão esta realidade impõe uma gestão de risco particularmente rigorosa e uma maior exigência no reporte à gestão, auditorias e apoio à extração de dados estatísticos, da responsabilidade do II, I.P., para citar apenas alguns exemplos.

4.3.2. Alterações Legislativas da Eventualidade de Desemprego

Um dos aspetos que mais influencia a performance de um sistema em manutenção evolutiva e corretiva é a estabilidade dos requisitos. Ora esse é provavelmente o fator de maior instabilidade nos sistemas de Segurança Social e garantidamente no subsistema de DES.

A maioria das alterações ao subsistema de DES decorre diretamente das alterações legislativas, quer no âmbito desta eventualidade, quer no âmbito de subsistemas de interface.

Para dar uma ideia dessas alterações no âmbito de desemprego, apresenta-se de seguida uma tabela resumo da principal legislação de desemprego implementada no subsistema de DES (não pretende ser uma sistematização de toda a legislação existente), e da legislação alterada desde que assumi a responsabilidade por este projeto (43, 44, 45), ou seja em menos de 4 anos.


37

Tabela 6 – Síntese da legislação principal da eventualidade de Desemprego

Classificação Número Data publicação Vigência Descrição

Desemprego Geral

Decreto-Lei 119/1999 14-04-1999 Revogado1 Estabelece, no âmbito do subsistema previdencial, o quadro legal da reparação da eventualidade de desemprego dos trabalhadores

por conta de outrem

Decreto-Lei 220/2006 03-11-2006 Em vigor Estabelece, no âmbito do subsistema previdencial, o quadro legal da reparação da eventualidade de desemprego dos trabalhadores

por conta de outrem

Portaria 8-B/2007 03-01-2007 Em vigor Regulamenta o Decreto-Lei nº 220/2006

Decreto-Lei 72/2010 18-06-2010 Em vigor Igual ao anterior, altera e republica o Decreto-Lei nº 220/2006.

Data de início específica para a condição de recursos: 01-08-2010

Decreto-Lei 64/2012 15-03-2012 Em vigor Igual ao anterior, altera o Decreto-Lei nº 220/2006. Data de início específica para o prazo de garantia 01-07-2012

Decreto-Lei 65/2012 15-03-2012 Em vigor em breve

Estabelece, no âmbito do subsistema previdencial, o quadro legal da reparação da eventualidade de desemprego dos trabalhadores independentes

Lei 4/2010 05-05-2010 Em vigor Informação do desempregado (entrada em vigor à data da lei que aprovou o orçamento de Estado para 2010)

Decreto-Lei 324/2009 29-12-2009 Revogado Prazo de garantia 365 dias. Revogado a 01-07-2010

Lei 5/2010 05-05-2010 Revogado Majoração 10% (entrada em vigor à data da lei que aprovou o orçamento de Estado para 2010)

Decreto-Lei 68/2009 20-03-2009 Revogado Prolongamento do Subsídio de Desemprego 2010

Decreto-Lei 15/2010 09-03-2010 Revogado Prolongamento do Subsídio de Desemprego 2010. Produção de efeitos a 01-01-2010

Decreto-Lei 77/2010 24-06-2010 Em vigor Revoga: Decreto-Lei nº 324/2009; Decreto-Lei nº 15/2010; Lei nº 5/2010

Portaria 180/2010 25-03-2010 Em vigor Intempérie RA Madeira. Produção de efeitos a 20-02-2010

Decreto-Lei 150/2009 30-06-2009 Revogado Condição de recursos 80% para 110%. Alterado pelo Decreto-Lei nº 72/2010

Regulamentos Comunitários

Regulamento (CE) 883/2004 29-04-2004 Em vigor

Regulamento (CE) 987/2009 16-09-2009 Em vigor

Desemprego - Situações Específicas

Decreto-Lei 28/2011 16-06-2011 Em vigor Profissionais de espetáculos

Decreto-Lei 67/2000 26-04-2000 Em vigor Docentes

Decreto-Lei 320/2007 27-09-2007 Em vigor Militares, altera e republica o Decreto-Lei nº 320-A/2000. Alterado posteriormente pela Lei nº 55-A/2011

Lei 105/2009 14-09-2009 Em vigor Salários em Atraso

IAS-Indexante de Apoios Sociais

Lei 64-B/2001 30-12-2011 Em vigor Valor IAS 2012

Agregados Familiares

Decreto-Lei 70/2010 16-06-2010 Em vigor Agregados Familiares

Portaria 598/2010 02-08-2010 Em vigor Requerimentos Agregados Familiares

Código do Trabalho

Lei 105/2009 14-09-2009 Em vigor Regulamenta e altera o Código do Trabalho

Lei 7/2009 12-02-2009 Em vigor Aprova o Código do Trabalho

Código do Procedimento Administrativo

Decreto-Lei 6/1997 31-01-1996 Em vigor Código do Procedimento Administrativo, altera e republica o Decreto-Lei nº 442/1991

(1) Diploma revogado, mas ainda em produção no subsistema de DES por se aplicar a algumas situações específicas.


38

Analisando o impacto das inúmeras alterações legislativas resumidas na tabela anterior, em termos de subsistema de DES, pode-se começar por referir impacto no volume de alterações, ou seja, na estabilidade requisitos/subsistema.

Tal como foi referido anteriormente, no II, I.P. quando os projetos estão em manutenção só são constituídos projetos quando as funcionalidades a implementar são de elevada complexidade ou duração.

Posto isto, saliente-se que desde que assumi funções neste subsistema, em 2009, foi constituído um projeto em 2010, associado à implementação de um novo conceito de agregados familiares (uma das bases para a atribuição de prestações), implementado pelo Decreto-lei nº 70/2010, de 16 de junho (46).

E, no mesmo ano, um projeto para implementação do Decreto-lei nº 72/2010, de 18 de junho (que devido ao número de alterações republica a legislação de base do desemprego, o Decreto-lei nº 220/2006, de 3 de novembro), cuja implementação só terminou em 2011 (46).

E finalmente, neste ano, em 2012, foram já constituídos dois projetos, um para a implementação das novas alterações ao Decreto-lei nº 220/2006, de 3 de novembro, o Decreto-lei nº 64/2012 de 15 de março, e outro para implementação da eventualidade de desemprego para os trabalhadores independentes, associado ao Decreto-Lei nº 65/2012, de 15 de março.

Outro dos aspetos a salientar é o facto de existir, em algumas matérias, vários decretos-lei em vigor, por exemplo, a legislação base de desemprego - como se referiu o Decreto-lei nº 220/2006: de 3 de novembro - tem neste momento especificidades de acordo com quatro decretos-lei posteriores.

Por vezes um desses decretos-lei só se aplica a alguns processos, o que em termos de regras ou funcionalidades de sistema não é de todo relevante, uma vez que tem que ser igualmente desenvolvido.

Esta situação implica um nível de complexidade muito elevado em termos de funcionalidades, que se refletem diretamente nas atividades, de análise, requisitos funcionais e não funcionais, desenvolvimento, gestão de incidentes, helpdesk, etc.

Por último, outro dos aspetos importantes na implementação destas alterações diz respeito à urgência. Como habitualmente refletem medidas políticas urgentes têm que ser implementadas num curto espaço de tempo. Apesar do II, I.P. ter normalmente conhecimento dessas medidas antecipadamente, raramente está definido o nível de detalhe necessário para que se possa avançar significativamente com as respetivas soluções. Este facto implica que, na maioria das vezes, o planeamento dos projetos ou alterações tenha que ser efetuado com base em datas fixas de implementação, ou seja, planeado a partir da data fim.

Para ser possível concretizar as alterações, uma vez que não pode ser alterado o fator tempo, apenas podemos gerir os fatores: custo e funcionalidades. Relativamente ao custo, mesmo que quando é possível ultrapassar os constrangimentos orçamentais existentes, não podemos aumentar a equipa significativamente, porque o facto de trabalharem sobre as mesmas funcionalidades limita o número de pessoas que podem trabalhar em simultâneo (sobretudo em termos de produção de código).


39

Portanto, a vertente mais frequentemente alterada, para fazer face à data fixa de implementação das alterações, é a funcional. Ou seja, são divididas as funcionalidades em partes tão pequenas quanto possível, para que possam existir entradas faseadas em produção, em função das prioridades. Outra alternativa passa pela implementação de soluções de contingência, que têm normalmente um custo elevado em termos de manutenção futura, porque são potenciais geradoras de informação incompleta e de mais incidentes, uma vez que pela sua natureza não respeitam na íntegra as funcionalidades pretendidas.

4.3.3. Considerações Finais

Enquanto responsável pelo subsistema de DES passei a estar mais envolvida e por isso mais atenta ao contexto dos projetos, nomeadamente em termos socioeconómicos, o que resultou numa maior reflexão sobre as repercussões de certas medidas políticas.

A problemática da complexidade legislativa, pelo impacto imediato que tem no subsistema de DES, e de uma forma mais abrangente, na vida de todos nós enquanto cidadãos, levaram-me a investigar alguns aspetos dessa matéria, cujos fundamentos serão apresentados do subcapítulo seguinte.

4.4. Discussão da Problemática da Complexidade Legislativa

O objetivo deste subcapítulo é explorar a problemática da complexidade legislativa, tendo por base as referências sobre o tema, focando os aspetos mais relevantes da minha atividade profissional, em particular como responsável pelo subsistema de DES.

Dada a quase inexistência de estudos sobre a complexidade legislativa em Portugal selecionei para esta análise as referências existentes no contexto europeu, por ser aquele que mais se aproxima do contexto português, e também porque atualmente as questões legislativas, nomeadamente em termos de simplificação administrativa e legislativa fazem parte de uma política comum da União Europeia (UE) “integrada numa estratégia de reforma dos ambientes regulatórios, de modernização e qualificação dos serviços públicos e de dinamização da economia” (47).

Entre estes estudos foram depois selecionados apenas aqueles que dizem respeito a medidas aplicadas pelo governo, na sua maioria relativos à legislação tributária, por serem aqueles cujo âmbito mais se aproxima do meu trabalho e da missão do II, I.P., enquanto organismo público. Não foram exploradas as diferenças entre a legislação tributária e legislação relativa à eventualidade de desemprego, por não terem sido discutidas questões relacionadas com detalhes legais, mas sim com aspetos gerais associados à implementação da legislação.

4.4.1. Conceitos

A legislação é coleção de leis de um país. Em Portugal, o processo legislativo cabe à Assembleia da República ou ao Governo consoante as respetivas matérias de competência legislativa.

Os diplomas emanados da Assembleia da República têm a designação de Leis e os diplomas emanados do Governo têm a designação de Decretos-Lei.

O Parlamento de Portugal (48) “é constituído por uma única Câmara, designada Assembleia

da República. Sendo um dos órgãos de soberania consagrados na Constituição, para além do


40

Presidente da República, do Governo e dos Tribunais, é, nos termos da lei fundamental, “a assembleia representativa de todos os cidadãos portugueses”.

Compete à Assembleia da República assegurar a aprovação das leis fundamentais da

República e a vigilância pelo cumprimento da Constituição, das leis e dos atos do Governo e da Administração.” (48)

A iniciativa legislativa cabe:

� Aos Deputados ou aos Grupos Parlamentares - projetos de lei;

� Ao Governo ou às Assembleias Legislativas Regionais - propostas de lei;

� A grupos de cidadãos eleitores.

Ver anexo G para descrição e fluxograma do processo legislativo comum da assembleia da

república.

O Governo (49) “conduz a política geral do país e dirige a Administração Pública, que executa a política do Estado. O Governo tem funções políticas, legislativas e administrativas”.

“Compete ao Governo, no exercício de funções legislativas:

Fazer decretos-leis em matérias não reservadas à Assembleia da República;

Fazer decretos-leis em matérias de reserva relativa da Assembleia da República, mediante autorização desta;

Fazer decretos-leis de desenvolvimento dos princípios ou das bases gerais dos regimes jurídicos contidos em leis que a eles se circunscrevam.” (33)

Ver anexo H para descrição do processo legislativo do governo.

4.4.2. Definição e Causas da Complexidade Legislativa

Segundo um estudo recente (50), a maioria das partes interessadas na legislação tributária no Reino Unido parecem concordar com o facto esta ser complexa. Martin (2005b) citado por Jelfs (50) é perentório quando diz que a legislação fiscal do Reino Unido é "longa e complexa, e normalmente é redigida num estilo denso o que a torna inacessível ao leigo”. No mesmo sentido, Vann (1995) citado por Jelfs (50) descreve a legislação tributária Australiana como "tax rule madness".

Em termos de legislação tributária, a complexidade é definida por Slemrod (1996) citado por Jelfs (50) como “o custo total de recursos ou a soma dos custos de conformidade (efetuada por indivíduos e empresas) e as despesas administrativas (despesas incorridas pelo governo) incorridas no cumprimento dos requisitos do sistema.”

Esta definição é relevante porque fornece desde logo uma ligação entre a complexidade dos impostos e os custos de conformidade.

Jelfs (50) levanta algumas hipóteses para justificar a complexidade da legislação tributária do Reino Unido. Uma das razões apontadas é o número crescente de páginas da legislação

que, segundo o autor, resultam numa maior dificuldade na compreensão de todas as disposições legais. Martin (2005a) citado por Jelfs (50) refere que isto, em parte, se deve à introdução, por parte do Governo, de medidas que incentivam pouco a simplificação da legislação ou a reforma da legislação ineficaz.


41

Também em Portugal, segundo Lopes (51) a legislação fiscal tem sido sujeita anualmente a revisões frequentes e a várias emendas que não têm simplificado o sistema. Segundo a autora, por um lado, é difícil para a administração fiscal manter constantemente o sistema fiscal atualizado, o que consequentemente provoca as queixas dos contribuintes. Por outro lado, torna-se mais difícil para as empresas e cidadãos identificar todos os requisitos legais, resultando numa baixa adesão. E resume: “como Portugal não se pode dar ao luxo de reduzir os impostos sem reconsiderar a despesa, a reforma tributária deve incluir a transparência e confiabilidade dando prioridade a uma menor frequência de alterações fiscais.”

Boaventura Sousa Santos (52) vai ainda mais longe, do meu ponto de vista, referindo: “No entanto, com a edição de normas e mais normas, o resultado tem sido uma verdadeira inflação legislativa, que vem complicando e burocratizando o funcionamento do Estado. Os próprios operadores do direito acabam tendo dificuldades para lidar com tanta complexidade legislativa, o que não raro, é motivo de profunda angústia para advogados, juízes, promotores... e todos aqueles que buscam ser justos no exercício da profissão jurídica… O positivismo jurídico (definido como a consciência filosófica do conhecimento-regulação) não vem resolvendo as grandes questões do nosso tempo, pois os problemas são complexos e globais, exigindo que seja ultrapassada a mera racionalidade lógico-formal, que vem caracterizando o direito posto objetivamente.”

Outra das razões apontadas por Jelfs (50) para a complexidade é a linguagem utilizada na legislação.

Segundo vários autores esta questão é de tal forma controversa que merece por si própria alguma reflexão.

Jelfs (50) refere que um projeto levado a cabo no Reino Unido em 1996 para reescrever a legislação tributária, em Inglês moderno (simplificado) foi responsável por um aumento de 50% do cumprimento das disposições reformuladas. Outra das críticas sobre a utilidade do projeto citava o facto de se considerar pouco provável que o público em geral quisesse ler o direito fiscal, independentemente da clareza da linguagem, e que em paralelo os profissionais fiscais estavam satisfeitos com a terminologia clássica que havia sido definida pelos tribunais.

Avery Jones (53) comentou: "A minha objeção à reformulação da lei relaciona-se com o facto de eu não encontrar uma relação entre as causas (da complexidade) e a solução proposta. A solução parece-me ser uma aceitação implícita de que nada pode ser feito para eliminar as causas reais da complexidade que estão profundamente enraizadas na nossa cultura legal”.

Barnes em (54) parece corroborar desta falta de consenso, mas salienta que mesmo assim é muitas vezes reconhecido um grande problema com a legislação: nomeadamente a sua “incompreensibilidade”. Eagleson, citado por Barnes (54), identifica como causas para esse problema as “frases de extensão indevida, o labirinto de cláusulas, a parcialidade de nominalizações, o extravio do adverbial, o material desnecessário e repetido, e as definições desnecessárias.”

A questão da “incompreensibilidade” da legislação está normalmente associada à questão de quem é o público-alvo da legislação.

Barnes, em (54), cita a visão de vários autores que consideram que a legislação deve ser dirigida ao público em geral, como a de Eagleson, que associa a simplificação da linguagem ao movimento de direitos dos consumidores, ou como a de outros autores, que consideram


42

que o público em geral é uma das partes do acordo (ou tem uma relação direta) estabelecido na legislação, ao contrário dos habituais intermediários, os juristas. Esta visão segundo Sullivan, professora de Direito citada por Barnes (54) pode ainda levar-nos a refletir sobre a democracia e o Estado de Direito numa perspetiva funcional ao invés da puramente formal. Ou como refere Justice McHugh do Supremo Tribunal Australiano, citado por Barnes (54) “os indivíduos não podem conhecer os seus direitos e deveres se não tiverem acesso à lei ou se não conseguirem entendê-la”.

E em contraponto, é referida por Barnes (54) uma visão mais ortodoxa, segundo a qual a legislação é dirigida, não ao público em geral, mas a uma pequena classe de intérpretes

oficiais que funcionam como mediadores entre a legislação e o público. Isto leva estes autores a sugerir que a falha não é na legislação (embora admitam que pode ser imperfeita, como todas as coisas humanas), mas sim na comunicação da substância da legislação às pessoas afetadas por ela, através de materiais explicativos ou resumos que ilustrem em linguagem clara e simples, a natureza e efeito da lei em questão.

Apesar destas diferentes perspetivas todos os autores parecem sugerir que a linguagem, por muito importante que seja, não resolve os verdadeiros problemas de comunicação ou justiça, nomeadamente em termos de acesso e equidade do sistema jurídico, que o propósito de uma lei não é que ela seja entendida, mas sim que seja aplicada e que resolva os problemas a que se destina.

Gale, citado por Jelfs (50), aponta ainda outra causa para a complexidade legislativa e afirma que a maioria das pessoas concorda que os impostos devem ser simples, justos, exequíveis e devem favorecer a prosperidade económica, mas com o que geralmente não concordam é com a importância relativa de cada um destes fatores. A complexidade legislativa é, por vezes, consequência da tentativa dos governos de implementarem políticas que equilibrem esses mesmos fatores.

Em resumo, pensa-se que os impostos mais justos ou igualitários entram usualmente em conflito com a simplificação tributária. Os encargos fiscais implementados por meio de legislação definida para circunstâncias individuais, promovem a equidade, mas

aumentam a complexidade global do sistema fiscal, aumentando a extensão e complexidade da legislação.

Além disso, as taxas que variam com as características individuais criam oportunidades de fraude e evasão fiscal, o que pode por sua vez, exigir mais legislação antifraude. Segundo o autor ao tornar-se mais complexa, a legislação fiscal do Reino Unido, cria “brechas” que são exploradas pelos consultores fiscais para criarem esquemas de evasão complexos que, por sua vez, criam um ciclo de maior complexidade nas leis fiscais e nas estratégias de evasão fiscal.

Em um estudo sobre a produção legislativa no sistema jurídico Italiano, Schuck citado por Di Vita (55) enuncia as quatro características que definem um sistema jurídico como complexo: densidade, tecnicidade, diferenciação e indeterminação.

A densidade refere-se ao número excessivo de regras, que podem por vezes entrar em conflito umas com as outras. A tecnicidade está relacionada com a linguagem específica utilizada, que é muitas vezes um obstáculo à sua compreensão por pessoas comuns. A diferenciação define a falta de coordenação institucional, quando há um grande número de estruturas legislativas para a criação e elaboração de regras. E finalmente, a indeterminação, quando as regras são vagas ou imprecisas, com custos elevados de implementação, e com resultados nem sempre previsíveis ex ante, o que as transforma numa fonte de incerteza.


43

4.4.3. Exemplos da Complexidade Legislativa na Eventualidade de Desemprego

O objetivo dos exemplos que apresento de seguida, relativos à legislação da eventualidade de desemprego, é estabelecer um paralelismo entre esta legislação e alguns dos aspetos teóricos que definem a complexidade legislativa citados anteriormente.

Os aspetos quantitativos da complexidade, isto é, a densidade da legislação, o número elevado e crescente de páginas e as revisões frequentes, na legislação da eventualidade de desemprego podem ser avaliadas em função do elevado número de decretos-lei e alterações apresentados no ponto 4.3.4., do qual destaco as profundas alterações ao decreto-lei base desta eventualidade, que tal como referi, têm tido uma frequência anual.

Os exemplos seguintes pretendem salientar, por outro lado os aspetos qualitativos dessa complexidade, nomeadamente o grau de especificidade da legislação, quer pela particularidade das circunstâncias abrangidas por alguns artigos, quer pelo nível de detalhe.

No senso comum quando se fala em prestações de desemprego, pensa-se na atribuição de uma prestação quando ocorre essa eventualidade. O que já mais dificilmente ocorre a quem desconhece esta legislação é que não existe apenas uma prestação, mas sim 40 tipos de prestações diferentes relativas ao desemprego.

Algumas destas prestações são fáceis de deduzir pela legislação, tal como o subsídio social de desemprego ou o montante único, outras dizem respeito a legislação específica e por isso menos óbvias, como é o caso do subsídio desemprego para trabalhadores migrantes ou o subsídio desemprego para ex-militares, etc. Estes benefícios podem ter características completamente diferentes entre si; por exemplo, no subsídio de desemprego (geral) existem condições de atribuição/deferimento baseadas na informação existente noutros subsistemas da segurança social (de vinculo laboral, remunerações declaradas à segurança social, etc.), já o subsídio desemprego para trabalhadores migrantes depende essencialmente da informação que é comunicada pelos países estrangeiros. Um outro exemplo é o relativo à forma de pagamento: o subsídio de desemprego é pago em prestações mensais, o montante único é uma prestação paga de uma só vez e as majorações são percentagens pagas mensalmente em função do agregado familiar e dos respetivos rendimentos.

Apresento agora um exemplo mais pormenorizado relativo ao cálculo do período de duração das prestações de desemprego, designado por período de concessão das prestações de desemprego. A quarta alteração à legislação base do desemprego, ou seja, o Decreto-Lei n.º 64/2012, de 15 de março (56) refere o seguinte:

“Artigo 37.º [...] 1 - O período de concessão do subsídio de desemprego e do subsídio social de desemprego inicial é estabelecido em função da idade do beneficiário e do número de meses com registo de remunerações no período imediatamente anterior à data do desemprego, nos seguintes termos: a) Beneficiários com idade inferior a 30 anos: i) Com registo de remunerações num período inferior a 15 meses, 150 dias; ii) Com registo de remunerações num período igual ou superior a 15 meses e inferior a 24 meses, 210 dias; iii) Com registo de remunerações num período igual ou superior a 24 meses, 330 dias;


44

b) Beneficiários com idade igual ou superior a 30 anos e inferior a 40 anos: i) Com registo de remunerações num período inferior a 15 meses, 180 dias; ii) Com registo de remunerações num período igual ou superior a 15 meses e inferior a 24 meses, 330 dias; iii) Com registo de remunerações num período igual ou superior a 24 meses, 420 dias;

c) Beneficiários com idade igual ou superior a 40 anos e inferior a 50 anos: i) Com registo de remunerações num período inferior a 15 meses, 210 dias; ii) Com registo de remunerações num período igual ou superior a 15 meses e inferior a 24 meses, 360 dias; iii) Com registo de remunerações num período igual ou superior a 24 meses, 540 dias;

d) Beneficiários com idade igual ou superior a 50 anos: i) Com registo de remunerações num período inferior a 15 meses, 270 dias; ii) Com registo de remunerações num período igual ou superior a 15 meses e inferior a 24 meses, 480 dias; iii) Com registo de remunerações num período igual ou superior a 24 meses, 540 dias.

2 - Os períodos de concessão do subsídio de desemprego e do subsídio social de desemprego inicial previstos no número anterior são majorados em função da carreira contributiva no período imediatamente anterior à data do desemprego, nos seguintes termos: a) Para os beneficiários com idade inferior a 40 anos, um acréscimo de 30 dias por cada cinco anos com registo de remunerações nos últimos 20 anos; b) Para os beneficiários com idade igual ou superior a 40 anos e inferior a 50 anos, um acréscimo de 45 dias por cada cinco anos com registo de remunerações nos últimos 20 anos; c) Para os beneficiários com idade igual ou superior a 50 anos, um acréscimo de 60 dias por cada cinco anos com registo de remunerações nos últimos 20 anos.

3 - Para efeitos do disposto nos números anteriores são considerados os períodos de registo de remunerações posteriores ao termo da concessão das prestações devidas pela última situação de desemprego, sem prejuízo do disposto no número seguinte. 4 - (Anterior n.º 3.) 5 - Nas situações em que o trabalhador não tenha beneficiado dos acréscimos, previstos no n.º 2, por ter retomado o trabalho antes de ter esgotado o período máximo de concessão da prestação inicial de desemprego, os períodos de registo de remunerações que não tenham sido considerados relevam, para efeitos de acréscimo do período de concessão de prestações, em posterior situação de desemprego.”

De acordo com este artigo, podíamos referir, de uma forma simplista (uma vez que estamos a considerar este decreto-lei e artigo isoladamente e sem especificar o tipo de benefício), que para implementar o cálculo do período de concessão teríamos que determinar a idade do beneficiário, a carreira contributiva do mesmo desde a última situação de desemprego até ao limite dos últimos 20 anos, ou seja, o número de meses com registo de remunerações3 nos últimos 20 anos e os acréscimos não gozados de prestações anteriores.

Mas, na verdade, a funcionalidade acima é apenas uma parte do cálculo do período de atribuição dado que o Decreto-Lei refere ainda o seguinte:

“Artigo 6.º

Salvaguarda de direitos

Na primeira situação de desemprego subsidiado, ocorrida após a data da entrada em vigor do presente decreto-

lei, é garantido ao beneficiário o período de concessão do subsídio de desemprego a que teria direito no dia

anterior àquela data, ao abrigo das normas então em vigor.”

3 As entidades empregadoras têm a obrigação mensal de declarar as remunerações dos seus trabalhadores à segurança social. Estas remunerações mensais de todos os trabalhadores abrangidos pela Segurança Social constam no subsistema Gestão de Remunerações do SISS.


45

Com este artigo, o legislador parece ter como objetivo, único e claro, salvaguardar os “direitos adquiridos” pelos trabalhadores. No entanto, implementá-lo à letra implica em termos de funcionalidades do sistema de informação, que para cada situação de desemprego, para além dos cálculos acima descritos tenham ainda de ser efetuados os cálculos para a idade e carreira contributiva que o beneficiário teria “no dia anterior àquela data” ou seja, no dia 31-03-2012, dia anterior à entrada em vigor do novo decreto-lei, caso se trate da primeira situação de desemprego após essa data.

Por outras palavras, daqui a 20 anos ao analisar um primeiro pedido de desemprego para um determinado beneficiário teremos que verificar a sua carreira contributiva nos últimos 20 anos para determinar o período de concessão nessa altura e depois efetuar os mesmos cálculos para a data 31-03-2012 (também com os 20 anos anteriores a essa data), isto apenas para decidir o período de concessão do respetivo desemprego. Se multiplicarmos esta realidade por cada tipo de prestação e funcionalidades, e pensarmos que as prestações de desemprego estão interligadas com todos os outros subsistemas do SISS e se o associamos ao facto de serem tratadas cerca de 600 mil prestações por mês, poderemos já ter uma ideia mais aproximada da complexidade desta legislação.

De acordo com a minha visão e experiência, esta complexidade não decorre da natureza desta eventualidade, mas sim da complexidade que foi sendo acrescentada com o aumento da legislação e sobretudo com a especificidade e nível de detalhe com que foi concebida.

Contudo, afirmar que a legislação de desemprego (ou outra) é complexa levanta desde logo algumas questões:

� Como é que medimos a complexidade legislativa?

� Ainda que neste momento não seja possível medir a complexidade legislativa devemos mantê-la?

� Haverá algo que possamos medir que reflita a complexidade legislativa?

Refletindo novamente sobre o exemplo anterior, não devemos nós questionar, se a especificidade do período de concessão atribuído justifica em termos de benefício, justiça social, etc., o custo de implementação do mesmo? Mediremos nós o custo de desenvolvimento das funcionalidades (registo, correção, recálculos, anulações, etc.); o custo da capacidade necessária ao sistema de informação envolvido; o custo dos recursos envolvidos no desenvolvimento e manutenção do sistema; o custo dos recursos humanos necessários para operar com o sistema, efetuar o atendimento especializado ao beneficiário, tratar as reclamações, etc.? Imputaremos nós esse custo à legislação e ao cumprimento da mesma?

4.4.4. Consequências da Complexidade Legislativa versus Simplificação

James (57) apresenta algumas desvantagens da complexidade para um sistema fiscal:

� Tomada de decisões económicas mais difíceis, reduzindo clareza e segurança;

� Reduz o cumprimento por parte do contribuinte, seja deliberadamente ou por desconhecimento das regras;

� Gera injustiças, pois nem todos os contribuintes podem tirar proveito da complexidade no sistema;

� Torna a discussão da política fiscal e melhorias mais difíceis.


46

Um estudo similar nos EUA, Hall citado por Jelfs (50) identifica dois tipos de custo económico criado pelo crescimento e revisão periódica da legislação tributária:

� Custos indiretos associados a planeamento tributário, implementação e contencioso;

� Oportunidades económicas perdidas devido à incerteza do contribuinte.

Um estudo levado a cabo pelo Banco Mundial em 2006, citado por Jelfs (50), destaca as consequências desfavoráveis de grandes volumes de legislação, referindo que isso torna impossível que os consultores fiscais leiam e compreendam toda a legislação, obrigando as empresas a depender de especialistas. O estudo refere que os líderes empresariais e seus representantes muitas vezes tornam públicas as suas preocupações sobre a complexidade da legislação fiscal e sobre o efeito negativo que isso tem na execução dos seus negócios.

Um outro estudo citado por Jelfs (50) “Tenon Forum Think Tank’s 2005”, em que foram entrevistados diretores de pequenas e médias empresas no Reino Unido, 77% afirmaram que o sistema fiscal do Reino Unido era muito complexo e 73% desejaram a simplificação do sistema tributário e da legislação.

A ligação entre a complexidade e os custos de conformidade (cumprimento) e custos administrativos é, em si complexa (57), mas geralmente quanto maior é a complexidade maiores são os custos. Salienta-se a dificuldade em medir os custos de conformidade, em particular os custos que não estão ativos, sendo dado como exemplo os custos de não concretização de um negócio devido à complexidade do imposto e outros regulamentos. Neste artigo são também referidas algumas das desvantagens da complexidade citadas anteriormente, nomeadamente a redução do cumprimento das exigências do sistema tributário pelos contribuintes, o aumento da dificuldade na tomada de decisão associada à dificuldade em estimar receitas e custos devido à falta de clareza da legislação, bem como a injustiça social que pode advir dos contribuintes não serem igualmente capazes de tirar proveito da complexidade do sistema.

O mesmo artigo aponta as vantagens da simplificação, por contraponto às desvantagens da complexidade. Ou seja, é referido que a simplificação promove o cumprimento das regras por parte dos contribuintes, reduz os custos de conformidade e administrativos dos contribuintes e acima de tudo reduz as despesas públicas, que é o próprio fundamento do imposto, pelo que esse valor pode ser aplicado em importantes serviços públicos.

Cooper (58) descreve os fatores que caraterizam uma legislação simples:

� Previsibilidade - as regras e o seu âmbito são facilmente, e com precisão, compreendidas pelos contribuintes e conselheiros;

� Proporcionalidade - a complexidade da solução não é mais do que a razoavelmente necessária para atingir o objetivo pretendido;

� Consistência - trata de assuntos semelhantes da mesma forma sem a necessidade de fazer distinções arbitrárias;

� Conformidade - é fácil de cumprir pelos contribuintes, sem terem que incorrer em custos excessivos;

� Administração - é fácil de administrar pelas autoridades;


47

� Coordenação - ajusta-se facilmente a outras regras existentes;

� Expressão - é claramente expressa.

Partindo do tema da simplificação da linguagem, Barnes (54) refere que a simplificação deve ser vista de uma forma mais abrangente, pela adoção de políticas que tornem a legislação mais acessível e compreensível, que podem ser colocadas em prática através de diferentes formas, nomeadamente:

� Pela participação do público no processo de desenvolvimento das propostas legislativas;

� Fazendo alterações no processo de elaboração e redação de estilo;

� Tornando a legislação mais acessível (disponível);

� Simplificando e reafirmando a interpretação da legislação;

� Melhorando a difusão de informações sobre a natureza e o efeito das leis.

No seio da UE a simplificação legislativa é também uma temática amplamente discutida.

Na Comunicação da Comissão ao Conselho e ao Parlamento Europeu, de 16 de Março de 2005, intitulada “Legislar melhor para o crescimento e o emprego na União Europeia” refere-se (59):

“A complexidade da legislação comunitária revela-se contraproducente para as autoridades públicas, as empresas, os cidadãos e os parceiros sociais. Os condicionalismos legislativos e administrativos afectam mais especialmente as Pequenas e Médias Empresas (PME), que, entretanto, constituem dois terços do emprego no interior da UE.

Os Estados-Membros podem contribuir para reduzir a burocracia. A Comissão deseja que a melhoria da legislação se torne parte integrante dos planos de acção nacionais decorrentes da estratégia de Lisboa. Nesse sentido, recomenda aos Estados-Membros que:

Tomem medidas nacionais a favor de uma melhor legislação, entre as quais deverão figurar sistemas de avaliação de impacto e programas de simplificação.

Procedam a um diálogo preventivo com os serviços da Comissão para evitar a introdução de procedimentos não automaticamente exigidos por uma directiva, por ocasião da sua transposição, no que diz respeito aos domínios harmonizados reservados aos textos considerados essenciais.

Recorram a processos por infracção e controlos preventivos para melhorar a qualidade da legislação a nível da transparência, da legibilidade e da eficácia nos domínios não harmonizados, como a livre circulação de mercadorias.”

O Conselho Económico e Social (CES) europeu afirma no press release (60) que “é preciso dar passos urgentes para reduzir a complexidade legislativa no mercado único”.

“A regulamentação excessiva e morosa não é somente onerosa, como tem um impacto negativo na criação de emprego, pois penaliza o espírito empresarial e entrava o processo de arranque de novas empresas. Vários grupos de interesses à escala da União Europeia uniram as suas vozes para solicitarem uma redução da carga legislativa.”


48

“O CES sugere a adopção de códigos de boa conduta para os Estados-Membros e para as instituições da UE, advogando que a assunção de um papel activo pelos parceiros económicos e sociais daria um impulso revigorado ao processo de simplificação.”

4.4.5. Avaliação da Complexidade Legislativa

O Programa de Simplificação Administrativa e Legislativa - Simplex 2006 (61) definia a avaliação do impacto normativo como um instrumento para promover a melhoria da qualidade da legislação.

Este programa previa o controlo e a eliminação do excesso de encargos administrativos que os diplomas legais e regulamentares ou os procedimentos administrativos criam para os cidadãos e para as empresas antes desses diplomas serem aprovados, ou numa fase posterior, quando se tornam visíveis os impactos negativos produzidos. Nomeadamente através da:

� Simplificação preventiva - (61) “usualmente realizada através da avaliação ex-ante do impacto de medidas legislativas e/ou administrativas. Os testes de avaliação do impacto normativo (vulgarmente conhecidos por Regulatory Impact Assessement são os instrumentos mais usados para esse efeito. Encontram-se em vigor em alguns países europeus como o Reino Unido ou a Bélgica (teste Kafka). Outras abordagens, como a holandesa, que passam pela fixação de quotas regulatórias, baseadas na avaliação e quantificação dos custos administrativos e pelo controlo do “stock” da regulação (one in, one out), são também possíveis de aplicar nesta fase.”;

� Simplificação corretiva (ex-post) que (61) “tem como objectivo a alteração de processos e de procedimentos já constantes das leis e regulamentos em vigor, com base numa avaliação negativa sobre os seus impactos ou a sua pertinência.”

Posteriormente, respondendo ao desafio do Conselho Europeu de Março de 2007, Portugal assumiu o compromisso para a redução de encargos administrativos para as empresas, com o objetivo de até ao ano 2012 diminuir em 25% os encargos administrativos impostos pelas normas de origem nacional nos eventos relevantes do ciclo de vida das empresas. Adotando a metodologia PT SCM (adaptação portuguesa da metodologia Standard Cost Model (SCM)), para identificação e quantificação dos custos administrativos4 para as empresas, decorrentes da legislação que têm de cumprir (47).

Estas orientações e ferramenta, do meu ponto de vista, pecam sobretudo por não serem habitualmente utilizadas. Independentemente das limitações das mesmas ou de alguma dúvida sobre as conclusões que pudessem ser retiradas, a implementação das mesmas permitiria obter dados e experiência na medição do impacto normativo, fundamental para o custeio e consequente melhoria da eficácia da legislação.

Por outro lado, entendo ser fundamental que se adotem ferramentas para medir também os custos substantivos4, já que estes podem ser os mais significativos para as empresas e são-no certamente para o próprio estado.

4 De acordo com a metodologia PT SCM os custos de regulação dividem-se em Custos Financeiros diretos (por exemplo:

obrigações, multas, taxas, etc.) e Custos de Conformidade. Por sua vez estes dividem-se em Custos Administrativos e

Custos Substantivos. Entende-se por custos administrativos os encargos suportados pelas empresas para prestar informação

sobre a sua atividade. E por Custos Substantivos os encargos suportados pelas empresas/estado para alterar o seu produto

e/ou processo para cumprir os requisitos legais.


49

Estes custos são aqueles que têm maior impacto na atividade dos prestadores de serviços de tecnologias de informação, em geral, e no II, I.P. em particular, uma vez que este é responsável por implementar os requisitos dos clientes que correspondem geralmente a alterações legislativas.

A metodologia Standard Cost Model for Substantive Compliance Costs desenvolvida pelo Regulatory Reform Group, e que é bastante semelhante à metodologia SCM, propõe-se exatamente a medir os custos substantivos associados a uma regulamentação (62).

4.5. Conclusão

Ao que foi dito sobre simplificação e avaliação da complexidade legislativa acrescento ainda algumas ideias para eliminar a complexidade legislativa que decorrem da minha experiência profissional de mais de 10 anos na implementação de legislação.

Na minha perspetiva, uma forma simples de resolver o problema da complexidade legislativa, sobretudo em termos de redução de custos de implementação seria elaborar legislação que estabelecesse regras gerais com definição clara dos propósitos e objetivos das medidas, e passasse os detalhes de implementação para regulamentação pelas entidades competentes. Desta forma seria possível garantir que as políticas fossem definidas pelos respetivos governos, que a legislação fosse definida pelos legisladores e que a implementação coubesse a quem efetivamente a implementa.

Outra forma de garantir a redução dos custos de conformidade, seria criar sistematicamente equipas multidisciplinares no processo de produção das leis e seguir um processo de produção legislativa que garantisse a execução de todas as etapas previstas segundo os conceitos de qualidade da lei (ver anexo I (63) para exemplo dos aspetos a ter em consideração no processo de produção das leis).

Por último, reportando-me às tecnologias de informação, considero fundamental adotar uma metodologia de medição dos custos substantivos que inclua obrigatoriamente os custos de manutenção dessas mesmas tecnologias, porque tal como é do conhecimento geral, é aí que os custos mais relevantes de um sistema de informação se evidenciam.

O que vai de certa forma ao encontro das orientações expressas na resolução do Conselho de Ministros, para a Administração Pública, nomeadamente (64):

� “No segundo eixo de atuação (redução de custos), propõem-se… a obrigatoriedade de avaliação prévia e sucessiva dos custos e benefícios dos investimentos e despesas em Tecnologias de Informação e Comunicação (TIC)”;

� “Implementar um processo de avaliação de projetos e despesas TIC, ex ante e ex post, obrigatório e vinculativo, estabelecendo mecanismos formais de avaliação multicritério dos investimentos, garantindo que apenas são financiados e implementados os projetos que demonstrem reais garantias de retorno nas várias dimensões em análise, minimizando investimentos redundantes e desalinhados com as políticas nacionais para as TIC na Administração Pública”.


50

5. Conclusões

Em termos de percurso profissional destacaram-se os projetos na área de consultoria e a participação na construção do novo e atual Sistema de Informação da Segurança Social Portuguesa, porque permitiram desenvolver maior autonomia e polivalência em termos profissionais, adquirir importantes competências ao nível da gestão da mudança, planeamento e restantes disciplinas associadas à gestão de projetos. Essa experiência foi posteriormente evidenciada e consolidada, na gestão de projetos de desenvolvimento de software.

A atividade profissional no projeto Fundo de Garantia Salarial permitiu conhecer todas as fases do ciclo de vida de desenvolvimento de software, o que se refletiu no conhecimento das boas práticas nessa matéria, expressas na metodologia do II, I.P.

Essas boas práticas patentes nas metodologias que seguem a linguagem Unified Modeling Language, nomeadamente a metodologia Unified Process expressam-se através do: Desenvolvimento iterativo e incremental; Gestão de Requisitos; Uso de arquiteturas baseadas em componentes; Modelação; Verificação contínua da qualidade e Controlo de alterações.

A experiência adquirida num projeto de grande dimensão, como o projeto Desemprego, quer pela sua complexidade, quer pela exposição mediática, subsidiaram uma maior consciencialização pessoal para o contexto socioeconómico dos projetos.

Da exploração da temática da complexidade legislativa conclui-se que não existe uma definição clara do conceito, embora a maioria dos autores identifique características comuns na legislação complexa e concorde sobre as consequências negativas da mesma, sugerindo medidas de simplificação da legislação e avaliação da complexidade, nomeadamente através da avaliação dos custos de conformidade, como possíveis soluções para os problemas que lhe estão associados.

Identificou-se na legislação relativa à eventualidade de desemprego atributos que caracterizam a legislação complexa, mas não se evidenciou pela experiência profissional como responsável pelo subsistema de Desemprego a aplicação de nenhum instrumento para medição dos respetivos custos, o que sugere alguma incerteza no impacto das medidas aplicadas que seria profícuo colmatar.

Não se pode deixar de referir o desafio que constituiu retratar a construção e o novo Sistema de Informação da Segurança Social, pelo reduzido número de dados públicos e a natureza sensível dos mesmos. E ainda, a quase inexistência de artigos científicos sobre a complexidade legislativa ou simplificação e sobre a avaliação dos custos de conformidade da legislação ou medidas regulatórias.

Esta questão revela, do meu ponto de vista, o trabalho que há por fazer em matéria de avaliação dos custos de conformidade. Pelo que se sugere em termos de estudos futuros a adaptação e implementação de instrumentos/metodologias de avaliação dos custos de conformidade em medidas implementadas ou a implementar pela Administração Pública.

Perspetiva-se com isso a adoção pela Administração Pública de práticas sistemáticas de avaliação preventiva os encargos associados às propostas legislativas (avaliação ex-ante) e também o impacto depois do desenvolvimento das respetivas medidas (avaliação ex-post).

Em termos de atividade profissional futura perspetiva-se o desenvolvimento de projetos de maior responsabilidade e dimensão, eventualmente em novas áreas do saber, ou porventura, na definição de uma nova abordagem para a implementação de nova regulamentação.


51

Referências

(1) Portaria n.º 242/99. Estrutura orgânica do Instituto de Informática e Estatística da Solidariedade (IIES). “Diário da República”. I Série-B, n.º 80 (2012-04-06), p. 1855-1857.

(2) Decreto-Lei n.º 41-A/99. Estatutos do Instituto de Informática e Estatística da Solidariedade. “Diário da República”. I Série-A, n.º 33 (1999-02-09), p. 736(2)-736(7).

(3) Instituto de Segurança Social I.P.. Quem Somos [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 abril 21]; Disponível em: http://www2.seg-social.pt/left.asp?05.18.01.

(4) Decreto-Lei n.º 115/98. CAPÍTULO II, Serviços, organismos e órgãos, SECÇÃO III, Dos organismos e órgãos, Artigo 29.º, Instituto de Informática e Estatística da Solidariedade. “Diário da República”. I Série -A, n.º 102 (1998-05-04), p. 1973-1986.

(5) Decreto-Lei n.º 126/2011. CAPÍTULO II, Estrutura orgânica. “Diário da República”. 1.ª Série, n.º 249 (2011-12-29), p. 5509-5515.

(6) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Missão, Visão, Valores do II, I.P. [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 abril 01]; Disponível em: http://www2.seg-social.pt/inst.asp?05.10.01.01.

(7) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Balanço Social 2009 [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 março 22]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=31792&m=PDF.

(8) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Relatório de Gestão 2010 [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 março 22]; Disponível em: http://www2.seg-social.pt/%5CDownloads%5CII%5CRelatorio_Gestao_2010.pdf.

(9) Portaria n.º 635/2007. Estatutos do Instituto de Informática, I. P.. “Diário da República”. 1ª Série, n.º 104 (2007-05-30), p. 3538 a 3541.

(10) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Plano de Actividades 2011 [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 março 22]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=31878&m=PDF.

(11) Instituto de Informática I.P.. Quem Somos. Estrutura Orgânica. Organograma II, I.P. [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 março 21]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=35730&m=PDF.

(12) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Plano Estratégico de Sistemas de Informação 2011-2013 [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 abril 22]; http://www2.seg-social.pt/downloads/II/MTSS_Instituto_Informatica_PESI_vfinal.pdf.

(13) Azevedo L. Certificação ISO 27001 no Instituto de Informática. I.P (MTSS). Comunicação no Seminário Anual’ 10. Segurança de Informação e a Gestão de Serviços - O papel da norma ISO/IEC 27001; 2010 novembro 30; Lisboa, Fundação Cidade de Lisboa, Campo Grande. Portugal: [Online]. itSMF; c2010 [Consult. 2012 abril 04]; Disponível em: http://www.itsmf.pt/LinkClick.aspx?link=Eventos%2FSeminario_2010%2FitSMF+Portugal+-+Semin%C3%A1rio+2010+-+Luis+Azevedo+-+101130.pdf&tabid=167&mid=679.


52

(14) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Plano de Actividades 2011 [Online]. Lisboa: II, I.P.; c1999-2012 [Consult. 2012 abril 22]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=31878&m=PDF.

(15) Sinfic. Casos de sucesso. IIES: Consolidação do Sistema da Segurança Social [Online]. Sinfic [Consult. 2012 abril 22]; Disponível em: http://www.sinfic.pt/SinficWeb/displayconteudo.do2?numero=23734.

(16) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Relatório Gestão IIESS 2005. [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 22]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=19580&m=PDF.

(17) Decreto-Lei n.º 219/99. Instituição do Fundo de Garantia Salarial. “Diário da República”. I Série-A, n.º 137 (1999-06-15), p. 3420-3421.

(18) Decreto-Lei n.º 35/2004. Regulamenta a Lei n.º 99/2003, de 27 de Agosto, que aprovou o Código do trabalho, CAPÍTULO XXVI, Fundo de Garantia Salarial. “Diário da República”. I Série-A, n.º 177 (2004-07-29), p. 4810-4885.

(19) Decreto-Lei n.º 139/2001. Regulamento do Fundo de Garantia Salarial. “Diário da República”. I Série-A, n.º 96 (2001-04-24), p. 2351-2355.

(20) IGFSS, IP. Conta da Segurança Social 2002, VIII. BALANÇO E DEMONSTRAÇÃO DE RESULTADOS CONSOLIDADOS [Online] Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 25]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=12197&m=PDF.

(21) IGFSS, IP. Conta da Segurança Social 2006, VIII. BALANÇO E DEMONSTRAÇÃO DE RESULTADOS CONSOLIDADOS [Online] Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 25]; Disponível em: http://www2.seg-social.pt/downloads/igf/conta_2006_final.pdf último acesso 25-04-2012.

(22) RUP Training - Notions and Fundamentals IIES, Student Guide. U.S.A.: Sun Microsystems; 2003. Module 4.

(23) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Relatório de Atividades IIES 2006 [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 22]; Disponível em: http://www2.seg-social.pt/inst.asp?05.10.01.05.

(24) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Plano de Actividades IIES 2005 [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 22]; Disponível em: http://www2.seg-social.pt/inst.asp?05.10.01.05.

(25) Scott K. The Unified Process Explained. Indianapolis, U.S.A.: Pearson Education, Inc.; 2002. Chapter 1, Overview; p. 7-13. Chapter 7, The Inception Phase; p. 87-100. Chapter 8, The Elaboration Phase; p.101-26.

(26) Kruchten P, Booch G, Rumbaugh J, Jacobson I. The Rational Unified Process: An Introduction. 2ª ed. U.S.A.: Addison-Wesley; 2000. Chapter 1, Software Development Best Practices; p. 4-16. Chapter 6, A Use-Case-Driven Process; p. 97-109. Chapter 8, The Business Modeling Workflow; p. 139-54.

(27) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Relatório de Atividades IIES 2005 [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 22]; Disponível em: http://www2.seg-social.pt/inst.asp?05.10.01.05.


53

(28) Pires M. O Novo Sistema de Informação da Segurança Social - Impacto na Vida dos Cidadãos e Empresas. Comunicação no 6º Congresso Nacional da Administração Pública. ”Os grandes passos da Reforma”; 2008 outubro 29-30; Lisboa. Portugal: INA; 2008.

(29) Booch G, Rumbaugh J, Jacobson I. The Unified Modeling Language User Guide. U.S.A.: Addison-Wesley; 1998. p.10-4.

(30) Object Management Group. Unified Modeling Language [Online]. Object Management Group; c1997-2012 [Atualizado em 2012 maio 21; Consult. 2012 abril 22]. Disponível em: http://www.uml.org/.

(31) IBM. Rational Unified Process [Online]. IBM [Consult. 2012 abril 22]. Disponível em: http://www-01.ibm.com/software/awdtools/rup/.

(32) Harmon P, Watson M. Understanding UML: The Developer’s Guide. San Francisco, U.S.A.: Morgan Kaufmann Publishers, Inc.; 1998. p. 27-46.

(33) Lei Constitucional n.º 1/2005. Constituição da República Portuguesa, Sétima revisão constitucional. “Diário da República”. I Série-A, n.º 155 (2005-08-12), p. 4642-4686.

(34) Decreto-Lei n.º 4/2007. Aprova as bases gerais do sistema de segurança social. “Diário da República”. 1.ª Série, n.º11 (2007-01-16), p. 345-356.

(35) Decreto-Lei n.º 72/2010. Terceira alteração ao Decreto -Lei n.º 220/2006, de 3 de Novembro. “Diário da República”. 1.ª Série, n.º 117 (2010-06-18), p. 2144-2164.

(36) ISS, I.P.. Publicações. Guias Práticos. Layoff [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 29]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=22570&m=PDF.

(37) Direção-Geral da Segurança Social, Instituto de Informática I.P.. Segurança Social em Números 2011 - Continente e Regiões Autónomas. Distribuição Percentual das Despesas Correntes da Segurança Social em 2010 [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 28]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=34057&m=PDF.

(38) Pordata. Despesa da Segurança Social [Online]. Lisboa: cPordata [Consult. 2012 abril 28]; Disponível em: http://www.pordata.pt/Portugal/Despesa+da+Seguranca+Social+total+e+por+tipo-100.

(39) Decreto-Lei n.º 72/2010. Terceira alteração ao Decreto -Lei n.º 220/2006, de 3 de Novembro, CAPÍTULO V, Duração das prestações. “Diário da República”. 1.ª Série, n.º 117 (2010-06-18), p. 2144-2164.

(40) Direção-Geral da Segurança Social, Instituto de Informática I.P.. Segurança Social em Números 2011 - Continente e Regiões Autónomas. Número de beneficiários de algumas prestações [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 28]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=34057&m=PDF.

(41) Pordata. Beneficiários das prestações de desemprego [Online]. Lisboa: cPordata [Consult. 2012 abril 28]; Disponível em: População no desemprego - http://www.pordata.pt/Portugal/Beneficiarios+das+prestacoes+de+desemprego+da+Seguranca+Social+no+total+de+desempregados+inscritos+nos+centros+de+emprego+e+de+formacao+profissional+(percentagem)-709.


54

(42) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Relatório de Atividades 2010 [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 22]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=34887&m=PDF.

(43) I.N.C.M. S.A.. Diário da República Eletrónico [Online]. cI.N.C.M. S.A. [Consult. 2012 abril 29]; Disponível em: http://dre.pt/.

(44) ISS, I.P.. Publicações. Guias Práticos. Subsídio de Desemprego [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 29]; Disponível em: http://195.245.197.202/preview_documentos.asp?r=23663&m=PDF.

(45) ISS, I.P.. Publicações. Guias Práticos. Subsídio Social de Desemprego, Inicial ou Subsequente ao Subsídio de Desemprego [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 29]; Disponível em: http://195.245.197.202/preview_documentos.asp?r=21519&m=PDF.

(46) Instituto de Informática I.P.. Quem Somos. Instrumentos de Gestão. Plano de Atividades 2010 [Online]. Lisboa: II, I.P.; 1999-2012 [Consult. 2012 abril 29]; Disponível em: http://www2.seg-social.pt/preview_documentos.asp?r=34887&m=PDF.

(47) AMA: Agência para a Modernização Administrativa - Presidência do Conselho de Ministros. Guia Prático para a Quantificação dos Encargos Administrativos de acordo com a metodologia Standard Cost Model – Manual PT SCM [Online]. Lisboa: AMA; c2009-2011 [Consult. 2012 junho 14]; Disponível em: http://www.simplex.pt/downloads/manualSCM.pdf.

(48) Assembleia da República. Parlamento [Online]. Lisboa: Assembleia da República; c2008 [Consult. 2012 abril 29]; Disponível em: http://www.parlamento.pt/.

(49) Governo da República Portuguesa. O Governo [Online]. Lisboa: Governo da República Portuguesa; c2012 [Consult. 2012 abril 29]; Disponível em: http://www.portugal.gov.pt/pt/a-democracia-portuguesa/o-governo/o-governo.aspx.

(50) Jelfs P. Would a ‘flat tax’ simplify the UK’s corporation tax legislation and reduce the associated compliance costs? [Tese de Mestrado]. [Birmingham]: University of Birmingham; 2010. 97 p. [Online]. University of Birmingham [Consult. 2012 junho 14]; Disponível em: http://etheses.bham.ac.uk/1172/.

(51) Lopes C. The Portuguese Tax System: Complexity and enforceability. Revista Universo Contábil [Online]. 2008 [Consult. 2012 junho 14]; 4(4): 140-163. Disponível em: http://www.doaj.org/doaj?func=openurl&genre=article&issn=18093337&date=2008&volume=4&issue=4&spage=140.

(52) Santos B. A Crítica da Razão Indolente. Portugal: Edições Afrontamento; 2000. Vol 1. 376 p.

(53) Jones A. Tax law: rules or principles?. Fiscal Studies [Online]. 1996 [Consult. 2012 junho 14]; 17(3): 63-89. Disponível em: http://www.ifs.org.uk/fs/articles/fsaveryjones.pdf.

(54) Barnes J. The Continuing Debate About ‘Plain Language’ Legislation: A Law Reform Conundrum. Statute Law Review [Online]. Oxford University Press; c2006 [Consult. 2012 junho 14]; 27(2), 83–132. Disponível em: http://slr.oxfordjournals.org/content/27/2/83.full.


55

(55) Di Vita G. Production of laws and delays in court decisions. International Review of Law and Economics [Online]. 2010 setembro [Consult. 2012 junho 14]; 30(3): 276-81. Disponível em: http://linkinghub.elsevier.com/retrieve/pii/S0144818810000098.

(56) Decreto-Lei n.º 64/2012. Procede à quarta alteração ao Decreto -Lei n.º 220/2006, de 3 de novembro. “Diário da República”. 1.ª Série, n.º54 (2012-03-15), p. 1237-1242.

(57) James S. Tax Simplification is not a simple issue: the reasons for difficulty and a possible strategy. University of Exeter [Online]. 2007 [Consult. 2012 junho 14]; 18(7): 1-18. Disponível em: http://mpra.ub.uni-muenchen.de/19281/.

(58) Cooper, G. Themes and issues in tax simplification. Australian Tax Forum [Online]. 1993 [Consult. 2012 junho 14]; 10(4): 417-60. Disponível em: http://www.taxinstitute.com.au/4FE77526-D565-5B5B-E8B95E9276CD9A1F.

(59) European Commission. European Commission Better Regulation European Commission [Online]. European Commission [Atualizado em 2011 agosto 23; Consult. 2012 junho 14]. Disponível em: http://ec.europa.eu/governance/better_regulation/impact_en.htm.

(60) European Union. É preciso dar passos urgentes para reduzir a complexidade legislativa no mercado único afirma o CES europeu [Online]. Official web site of the European Commission [Atualizado em 2011 agosto 23; Consult. 2012 junho 14]. Disponível em: http://europa.eu/rapid/pressReleasesAction.do?reference=CES/00/87&format=HTML&aged=1&language=PT&guiLanguage=en.

(61) Direção-Geral da Política de Justiça. Ministério da Justiça [Online]. Direção-Geral da Política de Justiça [Consult. 2012 junho 14]. Disponível em: http://www.dgpj.mj.pt/sections/politica-legislativa/anexos/avaliacao-do-impacto/anexos9170/programa-simplex-2006/downloadFile/file/2006ProgramaSimplex.pdf?nocache=1291115688.19.

(62) Regulatory Reform Group. Standard Cost Model for Substantive Compliance Costs: Measurement of substantive compliance costs for existing regulations - Handbook and step-by-step plan [Online]. Regulatory Reform Group; c2007 [Consult. 2012 junho 14]; Disponível em: http://www.irr-network.org/document/610/Regulatory_Reform_Group_%282007b%29_Standard_Cost_Model_for_Substantive_Compliance_Costs.html.

(63) Fundaçao Francisco Manuel dos Santos. Feitura de leis: Portugal e a Europa [Online]. Fundaçao Francisco Manuel dos Santos; c2012 [Consult. 2012 junho 14]. Disponível em: http://www.ffms.pt/estudo/107/feitura-de-leis-portugal-e-a-europa.

(64) Resolução do Conselho de Ministros n.º 12/2012. Plano global estratégico de racionalização das TIC na Administração Central. “Diário da República”. 1.ª Série, n.º 27 (2012-2-07), p. 596-605.


56

ANEXO A: COMPETÊNCIAS DOS DEPARTAMENTOS DO II, I.P

As competências dos departamentos que constituem a estrutura hierarquizada do II, I.P. são as seguintes (12):

� Departamento de Arquitetura de Sistemas e Estratégia Tecnológica (DASET), cujas

competências são definir, normalizar, planear e controlar a arquitetura de sistemas, a estratégia tecnológica, a acreditação de soluções aplicacionais e a visão tecnológica do planeamento estratégico de sistemas de informação;

� Departamento de Planeamento, Auditoria e Qualidade (DPAQ), a quem compete definir, normalizar, planear e controlar o sistema de planeamento estratégico e operacional, gestão de projetos, gestão orçamental, gestão do desempenho organizacional, gestão da qualidade, auditoria e controlo interno, gestão de riscos e de segurança de informação;

� Departamento de Soluções Aplicacionais Transversais (DSAT), com a competência de gerir a relação do II com as entidades clientes, bem como a gestão e o acompanhamento do ciclo de vida dos projetos de desenvolvimento aplicacional transversais ao MTSS e respetiva manutenção evolutiva e corretiva;

� Departamento de Soluções Aplicacionais da Segurança Social e Reabilitação (DSASSR), a quem compete a gestão e o acompanhamento do ciclo de vida dos projetos de desenvolvimento aplicacional, nas áreas específicas da segurança social e da reabilitação e respetiva manutenção evolutiva e corretiva;

� Departamento de Soluções Aplicacionais do Emprego, Formação Profissional e Relações Laborais (DSAEFPRL), cujas competências serão a gestão e o acompanhamento do ciclo de vida dos projetos de desenvolvimento aplicacional, nas áreas específicas do emprego, formação profissional e relações laborais e respetiva manutenção evolutiva e corretiva, à medida que os sistemas de informação dos respetivos organismos for sendo incorporada no sistema global de informação gerido pelo II;

� Departamento de Gestão de Informação (DGI), a quem compete conceber, planear, executar e controlar os projetos de produção e recolha de dados com vista ao seu tratamento como informação estatística e à sua utilização como indicadores de gestão pelos organismos do MTSS, nos domínios do suporte à decisão;

� Departamento de Operações de Sistemas e Apoio a Clientes (DOSAC), a quem compete gerir as infraestruturas de tecnologias de informação e comunicações, assegurar a exploração dos sistemas e prestar os serviços de apoio aos utilizadores dos equipamentos e soluções aplicacionais;

� Departamento de Administração-Geral (DAG), com a competência de assegurar e apoiar o funcionamento interno do II, nomeadamente, nas áreas da gestão dos recursos humanos, da gestão financeira e contabilística, da gestão de aquisições e contratos e do apoio jurídico.


57

ANEXO B: MODELO DE GESTÃO DO II, I.P.

Fonte: (12).

Modelo de Gestão

O II, I.P. tem adotado mecanismos de gestão flexíveis e inovadores, cujos resultados são orientados, sobretudo, para a satisfação das necessidades dos clientes, tendo vindo este esforço a ser reconhecido através das diversas certificações, quer do Sistema de Gestão da Qualidade, quer do Sistema de Gestão de Informação do Instituto.

Com o objetivo de clarificar e comunicar corporativamente a estratégia do II, I.P., definir e acompanhar o cumprimento dos objetivos operacionais de forma a colmatar desvios atempadamente, a Gestão do Desempenho Organizacional no II, I.P. é realizada através de diversos instrumentos, entre os quais se destacam:

� Gestão por Objetivos;

� Sistema de Planeamento e Controle de Gestão;

� Balanced Scorecard;

� Sistema de Gestão da Qualidade.

Gestão por Objetivos

A Gestão por Objetivos adotada pelo II, I.P. tem por base uma atitude de orientação para resultados, tal como determinado pelo SIADAP – Sistema Integrado de Avaliação do Desempenho da Administração Pública.

Para um controlo de gestão eficaz, indispensável a um sistema de gestão por objetivos, está implementado o processo de monitorização periódica do desempenho do II, I.P., assente no reporte regular dos níveis de desempenho alcançados para cada um dos objetivos fixados.

Trata-se de um processo que garante um controlo interativo, que incentiva a adoção de uma atitude dinâmica permanente, por parte de todos os dirigentes e que privilegia a ação e a tomada de decisão, em tempo útil, fomentando a responsabilização.

Sistema de Planeamento e Controlo de Gestão

O ciclo de Planeamento e Controlo de Gestão atualmente em funcionamento no II, I.P. passa por diversos passos, nomeadamente:

� Carta de Missão negociada entre a Tutela e o Conselho Diretivo do Instituto;

� Planeamento Estratégico Trianual de Sistemas de Informação, de acordo com os Planos Estratégicos dos Organismos do MTSS considerados no seu âmbito;

� Plano Anual de Atividades, que operacionaliza a estratégia definida;

� Quadro de Avaliação e Responsabilidade (QUAR), que contém os objetivos considerados mais relevantes para a avaliação de desempenho anual do Instituto;

� Monitorização periódica do grau de execução do Plano de Atividades e dos projetos que dele fazem parte, do QUAR e da Carta de Missão;


58

� Relatório Anual de Atividades.

Com base no Plano Estratégico de Sistemas de Informação (PESI), nas orientações da Tutela, na definição de prioridades do II, I.P. e na Carta de Missão do Conselho Diretivo, são fixados os objetivos operacionais anuais, despoletando-se, a partir daí, o processo de elaboração do Plano de Atividades.

Balanced Scorecard

O sistema de avaliação de desempenho organizacional, com base no modelo de Balanced Scorecard (BSC), permite uma leitura global e integrada do desempenho do II, I.P., analisado e medido segundo as quatro perspetivas mais adequadas à atividade do Instituto e encaradas como mais representativas da evolução do cumprimento da sua missão organizacional:

� Contribuição Corporativa;

� Utilizadores;

� Processos internos;

� Aprendizagem e Inovação.

Assim, tendo presente o necessário alinhamento estratégico com a Carta de Missão, os objetivos e projetos a definir são enquadrados nas quatro perspetivas do BSC acima indicadas.

Para cada uma das quatro perspetivas, são definidos, de acordo com os objetivos estratégicos, os objetivos operacionais e respetivos indicadores e metas e os projetos a considerar em cada ano, garantindo-se, dessa forma, a ligação e a coerência entre as iniciativas operacionais (objetivos e projetos) e a estratégia da organização.

Sistema de Gestão da Qualidade

O Modelo do Sistema de Gestão da Qualidade do II, I.P. está fundamentalmente orientado para a satisfação do cliente, baseado numa abordagem por processos e ciclo de melhoria contínua.


59

ANEXO C: RECURSOS DO II, I.P.

Recursos Humanos

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, 108 mulheres (39%) e 169 homens (61%).

O grupo de pessoal com maior número de efetivos é o Informático, que desempenha funções de TIC, que regista 194 pessoas (70%) do total de efetivos. Seguem-se os grupos de pessoal de técnico superior com 36 efetivos (13%), de assistente técnico, com 21 efetivos (8%) e o dos Dirigentes com 21 efetivos (8%).

A idade média no Instituto é de 42 anos, sendo a faixa etária onde se registam maior número de colaboradores, a compreendida entre os 35 e 39 anos. A distribuição do total de efetivos por género é de 108 mulheres (39%) e de 169 homens (61%).

A percentagem de efetivos com habilitação superior – mestrado, licenciatura e bacharelato – era de 63%.

Verificou-se a participação de 264 (95%) em duas ou mais ações de formação. Foram despendidas, em ações de formação, um total de 234.867 €.

O II, I.P. apresenta um nível de externalização parcial para os serviços de Gestão Aplicacional, Helpdesk e Gestão de Infraestrutura. Para o serviço de Redes e Comunicações a externalização do serviço é inexistente (12).

Recursos Financeiros (8)

De acordo com últimos dados públicos divulgados, o orçamento executado pelo II, I.P. em 2010 foi de 39.976.788 euros.

Composição do Orçamento Corrigido (valores arredondados):

Aquisição Bens de Capital 15.581.000 €

Aquisição Bens e Serviços 12.578.000 €

Despesas com Pessoal 11.719.000 €

Subsídios 93.000 €

Juros e Outros Encargos 5.000 €

Outras Despesas 2.000 €


60

Recursos Materiais

Postos de Trabalho 12.000

Postos de Trabalho Virtualizados 80

Impressoras Laser Monocromáticas de Rede 3.000

Impressoras Laser Monocromáticas USB 1.300

Servidores de Suporte as Redes Locais 461

Servidores de Suporte a Infraestrura Distribuída 150

Servidores Virtualizados 200

Equipamentos Centrais

92 Servidores SUN Solaris (total de servidores físicos e virtuais)

17 Servidores HP-UX (total de servidores físicos e virtuais)

1 Servidor Windows (Gestão Storage)

2 Arrays de Storage

2 Gateway NAS

2 Robots de Backups

Comunicações

620 Circuitos (562)

1228 Routers

548 Equipamentos Ativos


61

ANEXO D: ARQUITETURA DO II, I.P.

Fonte: (12).

Arquitetura Lógica do II, I.P.

Figura 9 - Arquitetura lógica do II, I.P.

Apresentação

Aplicacional

Dados


62

Arquitetura Global de Rede do II, I.P.

Figura 10 - Arquitetura global de rede do II, I.P.

Fonte: Instituto de Informática, IP


63

ANEXO E: DIAGRAMAS UNIFIED MODELING LANGUAGE

Fonte: (29).

“A class diagram shows a set of classes, interfaces, and collaborations and their relationships.”

Figura 11 - Diagrama de classes

“An object diagram shows a set of objects and their relationships.”

Figura 12 - Diagrama de objetos


64

“A component diagram shows a set of components and their relationships.”

Figura 13 - Diagrama de componentes

“A deployment diagram shows of nodes and their relationships.”

Figura 14 - Diagrama de deployment

“A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.”

Figura 15 - Diagrama de casos de uso


65

“A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.”

Figura 16 - Diagrama de sequência

“A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.”

Figura 17 - Diagrama de colaboração

“A statechart diagram shows a state machine, consisting of states, transitions, events, and activities.”

Figura 18 - Diagrama de estados


66

“An activity diagram shows the flow from activity to activity within a system.”

Figura 19 - Diagrama de atividades


67

ANEXO F: CICLO DE VIDA DE DESENVOLVIMENTO DE SOFTWARE; ARTEFACTOS

Objetivos das fases do ciclo de vida de desenvolvimento de software (25):

Conceção: O principal objetivo da fase de conceção é o de obter uma visão, âmbito e aceitação homogénea do projeto perante todos os stakeholders.

Esta fase é de extrema importância para o desenvolvimento de novos projetos ou projetos já existentes quando existam requisitos de negócio significativos e riscos de projeto que necessitem ser cuidadosamente analisados antes do projeto continuar. Para projetos com um foco mais orientado a alterações e novas pequenas funcionalidades, esta fase é bastante breve, mas continua focada em garantir que o projeto vale a pena executar e de que é possível executá-lo.

Elaboração: 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. A arquitetura evolui tendo como base os requisitos mais significativos do sistema (aqueles que têm maior impacto na arquitetura do sistema) e através da análise dos riscos. A estabilidade da arquitetura é avaliada através dos diferentes protótipos de arquitetura que devem ser realizados.

Construção: O principal objetivo da fase de construção é o de clarificar os restantes requisitos que possam existir e o completar a implementação do sistema baseada na arquitetura base definida na fase anterior.

Transição: O foco da fase de transição é o de assegurar que o produto final está pronto para os utilizadores finais o poderem explorar. Esta fase pode conter várias iterações e incluir testes de preparação do produto para lançamento em produção bem como executar pequenos ajustes com base nos utilizadores finais. Todo o input vindo dos utilizadores finais nesta fase não podem nem devem comprometer o sistema final, pois essa informação já deve ter sido utilizada para a própria criação do sistema atempadamente.


68

Tabela 7 - Alguns dos artefactos previstos nas diferentes fases do ciclo de vida dos projetos

Fase de Conceção

Definição do Âmbito do Projecto (Visão)

O objetivo deste documento é recolher, analisar e definir as necessidades de alto nível e as características do sistema. Está focado nas necessidades dos stakeholders e porque é que essas necessidades existem.

Definição da Arquitetura Este documento descreve qual a arquitetura de software utilizada para este sistema e o modo como esta é representada. Descreve ainda como a arquitetura de software contribui para solucionar todos os requisitos de sistema (para além da funcionalidade, ex.: Segurança, Fiabilidade, Disponibilidade, Escalabilidade, etc.). Se existir alguma característica especial, esta deve ser claramente descrita.

Riscos Este documento identifica e permite a monitorização dos riscos inerentes ao projeto.

Modelo de Casos de Uso O objetivo deste documento é identificar e descrever as funcionalidades do sistema, assim como identificar todos os atores que com ele interagem. Pretende-se também apresentar, o diagrama Geral de Casos de Uso e a respetiva ligação entre os vários Casos de Uso e os Atores.

Plano de Projeto O objetivo é apresentar uma imagem do plano de projeto que se encontra no sistema de informação de gestão.

Fase de Elaboração

Protótipo de Arquitetura O objetivo da prova de arquitetura é validar as opções de arquitetura feitas para o projeto (de que modo a arquitetura tenta fazer face aos requisitos não funcionais). Um ou mais protótipos arquitetónicos executáveis devem ser criados para explorar as funcionalidades críticas e os cenários mais críticos do sistema, do ponto de vista da arquitetura.

Requisitos não Funcionais Este documento identifica e define todos os requisitos não funcionais do sistema (Segurança, Fiabilidade, Disponibilidade, Escalabilidade, Performance, Facilidade de Manutenção, Portabilidade, Extensibilidade, etc.).

Modelo de Análise e Desenho

Toda a informação deste modelo encontra-se na ferramenta de modelação.

Diagramas de Sequência (Parte do Modelo de Análise e Desenho)

Realização de todos os casos de uso, ao nível de análise.

Realização também, ao nível de desenho, do(s) caso(s) de uso selecionado(s) para fazer a prova de arquitetura.

Modelo de Dados Lógico Modelo lógico de base de dados na ferramenta interna.

Plano de Testes Conjunto de artefactos que permitem testar a aplicação (testes de integração, testes funcionais, testes sistema, testes de carga).

Fase de Construção

Sistema Código Fonte, Ficheiros de Propriedades, Scripts, Ecrãs Standard, Testes Unitários, Javadoc do sistema, Javadoc dos serviços públicos, etc.

Manual de Deployment O manual deployment descreve o jogo de tarefas necessárias à instalação e teste do produto desenvolvido, tais que permitam realizar eficazmente a sua transição para a comunidade de utilizadores (plano de deployment).

Modelo de Dados Físico Modelo físico de base de dados.

Fase de Transição

Release Notes Contem informação sobre bugs corrigidos, alterações, novas funcionalidades para uma determinada distribuição da aplicação.

Relatório Final de Testes Relatório genérico de testes por Build Acreditada.


69

ANEXO G: DESCRIÇÃO E FLUXOGRAMA DO PROCESSO LEGISLATIVO COMUM

O processo legislativo comum é descrito da seguinte forma (48):

“A iniciativa legislativa cabe aos Deputados ou aos Grupos Parlamentares - neste caso chamam-se projetos de lei e também ao Governo ou às Assembleias Legislativas Regionais - neste caso chamam-se propostas de lei.

Também grupos de cidadãos eleitores podem exercer o direito de iniciativa legislativa junto da Assembleia da República, bem como participar no procedimento legislativo a que derem origem, nos termos do artigo 167.º da Constituição e da Lei nº 17/2003 de 4 de junho.

Depois de ser admitida pelo Presidente da Assembleia, a iniciativa é objeto de um parecer da Comissão especializada a quem foi distribuída, seguindo-se o seu debate na generalidade, sempre feito em reunião Plenária, que termina com a votação na generalidade (sobre as linhas gerais da iniciativa).

Segue-se um debate e votação na especialidade (artigo por artigo), que pode ser feito em

Plenário ou em Comissão.

O texto final é submetido a uma votação final global sempre feita em Plenário.

A iniciativa aprovada chama-se Decreto da Assembleia da República.

O Decreto, assinado pelo Presidente da Assembleia da República, é enviado ao Presidente da República para promulgação. Após a promulgação o decreto assume a designação de Lei, é enviado ao Governo para referenda (assinatura do Primeiro Ministro) e depois remetido à Imprensa Nacional para publicação na 1ª série do Diário da

República.”

A figura seguinte mostra o fluxograma do processo legislativo comum (48):


70

Figura 20 - Fluxograma do processo legislativo comum


71

ANEXO H: DESCRIÇÃO DO PROCESSO LEGISLATIVO DO GOVERNO

Fonte: (49).

“Como é que o Governo faz uma lei (cuja designação rigorosa é "Decreto-Lei")?

Um ministro toma a iniciativa (redige-a ou pede a peritos para a redigirem).

Envia-a à Presidência do Conselho de Ministros, que verifica se é adequada, oportuna e correcta, fazendo-se os acertos necessários entre o Ministro proponente e a Presidência do Conselho de Ministros.

Depois, é enviada aos outros Ministros que a analisam, designadamente recorrendo aos seus auxiliares directos ou aos seus serviços.

A opinião do Ministro é transmitida ao Secretário de Estado que representa o Ministério na reunião de Secretários de Estado.

A iniciativa é analisada na Reunião de Secretários de Estado e, se se verificar acordo, aprova-se o projecto, que será agendado para Reunião do Conselho de Ministros.

O Primeiro-Ministro e os Ministros recebem os documentos da agenda do Conselho de Ministros.

O Conselho de Ministros pode aprovar a proposta como lhe é apresentada, emendá-la, adiá-la ou mesmo rejeitá-la.

Depois de aprovado, o diploma é assinado pelos Ministros com competência em razão das diversas matérias e pelo Primeiro-Ministro e enviado ao Presidente da República para promulgação. Uma vez promulgado, é referendado pelo Primeiro-Ministro e enviado para publicação no Diário da República.”


72

ANEXO I: ESTUDO SOBRE A FEITURA DAS LEIS: PORTUGAL E A EUROPA

Fonte: (63).

“Este estudo pretende dar a conhecer os métodos utilizados na elaboração da lei, numa perspectiva comparativa, recorrendo a países seleccionados pelas «boas práticas» adoptadas.

Passos da Feitura das Leis a abordar

No processo de produção legislativa, tal como orientado pelo conceito de qualidade da lei, podem distinguir-se as seguintes etapas, cujo desenrolar concreto o projecto pretende reconstituir através de uma pesquisa comparativa.

Planeamento legislativo

A importância do planeamento legislativo para a qualidade da legislação. O factor «tempo» na elaboração da lei.

Gestão dos projectos legislativos

Inventariação das fontes jurídicas e informações factuais necessárias à identificação do problema. Definição clara dos objectivos do projecto.

Formação de uma equipa interdisciplinar.

Definição do período de preparação e redacção do projecto legislativo.

Definição dos recursos financeiros necessários.

Definição do procedimento de consulta: entidades a consultar; modalidades da consulta; período de consulta; recolha da informação; elaboração e publicação do relatório do procedimento de consulta.

Consulta / participação legislativa

A importância desta fase na metodologia de preparação da lei.

Avaliação legislativa

A avaliação como metodologia fundamental na preparação da lei:

� Tipos de avaliação (ex ante e ex post);

� Critérios de avaliação: metodologias desenvolvidas;

� Entidades responsáveis pelo procedimento de avaliação;

� Limites e dificuldades da avaliação legislativa.

Execução da lei

A execução como momento fundamental no procedimento legislativo.

Aspectos essenciais:

� A consideração do período de vacatio legis;

� A regulamentação da lei, quando necessária;


73

� A preparação dos aspectos humanos (formação dos aplicadores da lei) e aspectos materiais (adequação do software informático; elaboração atempada de impressos; preparação de manuais de instruções, sempre que necessário).

Comunicação legislativa

Modalidades de publicação da lei como primeiro factor de acessibilidade para os cidadãos.”

Utilização da Metodologia Unified Process e Reflexão sobre ... · Reflexão sobre a Complexidade...

Documents

Transcript of Utilização da Metodologia Unified Process e Reflexão sobre ... · Reflexão sobre a Complexidade...