metodologias de desenvolvimento de sistemas do governo...

Governo Eletrônico – O que um líder governamental deve saber Página 1 de 23

Metodologias de Desenvolvimento de Sistemas de Governo Eletrônico

1. Metodologias para o Desenvolvimento de Sistema de Informação.

As metodologias, especificamente as do ciclo de vida de desenvolvimento dos

sistemas, fornecem o framework e os conjuntos de procedimentos nos quais um grande

número das tarefas envolvidas no desenvolvimento do governo eletrônico pode ser

realizada. A maior parte das metodologias abrange o amplo desenvolvimento de

atividades, desde a iniciação do projeto até a revisão de pós-implementação. A

metodologia para o desenvolvimento do sistema é uma abordagem formal e estruturada

que define e descreve sequencialmente todas as fases, tarefas e considerações que

são necessárias para que um projeto seja bem sucedido. O framework e o conjunto de

procedimentos garantirão que cada fase de desenvolvimento seja cuidadosamente

planejada, controlada e aprovada; que cada uma esteja em conformidade com o

conjunto de padrões; que cada uma seja adequadamente documentada; e que cada

uma tenha a equipe apropriada.

A partir do ponto de vista de gestão e controle, as metodologias dos sistemas de

informação irão:

• Fazer uso da experiência de especialistas e de outros desenvolvedores de

sistema como referência, e assim fornecer aos gerentes que são novos no

processo, uma lista de verificação das etapas que devem ser tomadas e das

questões que devem ser respondidas, de modo a facilitar o desenvolvimento dos

sistemas de informação.

• Fornecer um registro histórico do processo de desenvolvimento, através da

utilização de uma metodologia formal e da solicitação de documentações que

podem ser utilizadas no planejamento e nas avaliações futuras dos sistemas de

informação.


• Permitir que os usuários/gerentes tenham um melhor controle do progresso do

projeto, e assim aumentar a utilidade dos resultados finais.

• Permitir a transferência de modelo de uma aplicação para outra e a transferência

de pessoas de um projeto para outro.

Portanto, é essencial que o desenvolvimento dos sistemas de governo eletrônico

seja realizado de acordo com um conjunto de procedimentos ou de metodologias

formais.

Antes do sistema de governo eletrônico ser desenvolvido, é necessário realizar

uma avaliação profunda dos processos de negócios associados ao sistema, incluindo as

interações dentro ou entre as agências governamentais. Os sistemas de informação são

elaborados para informatizar e reformular os processos relacionados ao negócio, de

modo a melhorar a efetividade, a eficiência e a produtividade dos negócios

governamentais. Obviamente, que sem incentivar os processos comerciais, ou o fluxo

comercial, o fluxo da informação nunca seria incentivado dentro da agência ou entre as

agências governamentais. Este é o motivo pelo qual a Remodelagem do Processo de

Negócios (BPR) e a reformulação têm-se tornado bastante populares nos países

industriais desde a década de 80.

Existem três tipos diferentes de desenvolvimento de sistema de informação com

resultados diversos:

• Os sistemas de informação que possuem um software de elaboração

personalizado, ou seja, o software de aplicação do sistema é elaborado de forma

customizada para atender as necessidades especiais dos usuários dos sistemas

de informação a serem desenvolvidos.

• Os sistemas de informação que utilizam pacotes de software, ou seja, softwares

desenvolvidos por terceiros que podem ser vendedores ou consultores, que são

utilizados como um software de aplicação fundamental. Logicamente que algum

trabalho de customização pode ser inevitável.

• Reengenharia dos sistemas de informação já existentes, por exemplo, os

códigos e dados existentes são reformulados e migrados para um novo


ambiente e uma nova plataforma de tecnologia avançada de software para

modernizar e aumentar a funcionalidade dos sistemas de informações

existentes. Ou a “herança” antiga dos sistemas é ajustada para se adequar ao

moderno sistema, através do uso de produtos de conectividade.

Com o desenvolvimento da tecnologia de software, os sistemas de informação

estão cada vez mais sendo desenvolvidos em pacotes de software. Independente de

que tipo de sistema de informação mencionado acima está sendo desenvolvido, uma

metodologia adequada de engenharia de sistema da informação precisa ser adotada

para garantir o sucesso do desenvolvimento do sistema.

Segue abaixo os quatro métodos diferentes de sistemas desenvolvidos:

1.1. O Método de Orientação de Dados - é utilizado quando os dados/informações

necessários para a realização dos trabalhos da instituição formam a base de mudança

do sistema. O método de orientação dos dados é adequado para o processamento de

grandes e não-homogêneas quantidades de informação e para procedimentos muito

dinâmicos.

1.2. O Método Funcional - é utilizado quando as unidades organizacionais (funções) e

suas comunicações mútuas formam a base. O método funcional é adequado para o

processamento de procedimentos complicados com diversas superfícies ou pontos de

contato e regras de processamento. Além disso, o método é adequado para as tarefas

bem definidas.

1.3. O Método Evolucionário - envolve um desenvolvimento sucessivo. As partes do

sistema de alta prioridade são introduzidas antes das partes de baixa prioridade, mas de

tal forma que todas as partes do sistema formem a parte da totalidade planejada. O

método evolucionário é adequado para a introdução dos sistemas em fases, ou quando

algumas partes do sistema são mais importantes do que outras. Além disso, este

método é bem adequado para sistemas complicados.

1.4. O Método de Protótipo - é utilizado quando se deseja um modelo funcional do

futuro sistema. O método de protótipo é adequado para altas tarefas não-estruturadas,

tais como ambientes dinâmicos, situações experimentais, sistemas de diálogo e para

preparar as organizações para a introdução dos sistemas de governo eletrônico. O


Protótipo é um método em que o desenvolvimento das versões de testes (protótipos) de

um sistema é realizado em uma escala muito ampla. O método também é chamado de

desenvolvimento de sistema experimental, desenvolvimento de sistemas com protótipos

ou de desenvolvimento de sistemas interativos.

A seleção do método de desenvolvimento dos sistemas baseia-se na avaliação

da totalidade das quatro principais áreas e leva-se em conta: a natureza das tarefas; a

organização envolvida; a tecnologia disponível; e o pessoal, que inclui os usuários e os

profissionais técnicos.

2. Engenharia de Sistema do Governo Eletrônico

O desenvolvimento efetivo e eficiente dos sistemas de governo eletrônico é

baseado em diversos fatores, incluindo a compreensão das exigências do usuário e a

capacidade de determinar os meios mais eficazes para atendê-los. O primeiro exige um

conhecimento detalhado e especialização no negócio do usuário. Isto é essencial e

requer a disponibilidade e o envolvimento de gestores e usuários com conhecimento

especializado de seus negócios. O segundo, a determinação dos meios para atender as

exigências do usuário, exige o envolvimento dos analistas de sistema do governo

eletrônico que são especialistas em tecnologia da informação atual. Portanto, o

desenvolvimento do sistema de governo eletrônico exige uma parceria para a

modelagem: os usuários fornecem o modelo comercial e os analistas de sistemas do

governo eletrônico fornecem o modelo técnico.

Isto é fácil de dizer, mas na prática, é difícil de fazer. O modelo de sistema do

governo eletrônico, assim como a análise dos processos comerciais é, na melhor das

hipóteses, uma ciência inexata, pois é altamente dependente de uma comunicação

exata, precisa e clara da informação e das ideias entre usuários, analistas e designers.

Caso se pretenda obter um desenvolvimento de sistema de governo eletrônico bem

sucedido, deve-se seguir as metodologias de engenharia de sistema de governo

eletrônico, as quais resumem e incorporam a experiência e as lições de

desenvolvimento dos sistemas anteriores, independentemente se estas foram bem

sucedidas ou não.


Com o objetivo de realizar qualquer conjunto de tarefas de forma eficaz a equipe

precisa ter um plano de trabalho ou um procedimento. Sem isto, as tarefas serão

realizadas de forma aleatória e com pouca coordenação, caso esta esteja presente. Os

resultados são diversos produtos intermediários que raramente se adequam em um

conjunto coeso, e, pior do que isto, o produto final raramente atende as especificações

iniciais. Em alguns casos, devido à falta de plano de trabalho, não há especificações

iniciais. Os planos de trabalho detalhados para o desenvolvimento dos sistemas de

governo eletrônico são chamados de metodologias. De fato, a metodologia é um

sistema de princípios, práticas e procedimentos aplicados para, e informado através de

um ramo específico de conhecimento. Conforme havia sido mencionado no parágrafo

inicial, as metodologias fornecem o framework e os ajustes de procedimentos nos quais

a miríade das tarefas envolvidas no desenvolvimento do governo eletrônico pode ser

realizada. A maior parte das metodologias abrange o amplo desenvolvimento de

atividades, desde a iniciação do projeto até a revisão de pós-implementação.

A engenharia de sistema do governo eletrônico leva a ganhos em produtividade

e de qualidade de desenvolvimento dos sistemas. Algumas das questões importantes

relacionadas ao desenvolvimento do sistema de informação, que são direcionadas

através dos métodos de engenharia de sistema do governo eletrônico são as seguintes:

2.1. Administração de Dados e Gestão de Recurso da Informação

A engenharia de sistema do governo eletrônico dá uma grande importância à

administração de dados e à gestão de recurso da informação, e é um veículo poderoso

para o estabelecimento da administração de dados e das funções de gestão de recurso

da informação em uma organização. A administração de dados é uma função que define

os padrões, o acompanhamento e o controle da informação em uma organização. A

gestão do recurso da informação tem o mesmo propósito da administração de dados,

mas também inclui o planejamento, a organização, o controle de dados e os modelos de

processo definindo as configurações das instalações de hardware, software e de rede, e

o treinamento das pessoas que são necessárias para o suporte dos sistemas de

governo eletrônico da organização.

2.2. Produtividade e Qualidade do Sistema


O aumento da produtividade com uma baixa qualidade não servirá para a

obtenção do resultado desejado do governo eletrônico; produtividade e qualidade

devem ser melhoradas em conjunto. A engenharia de sistema do governo eletrônico

assegura e garante a qualidade através da coleta das exigências comerciais antes da

criação de soluções. O rigor das técnicas e as fases desta metodologia garantem que a

qualidade inicial seja mantida ao longo da implementação. Apesar de que certamente a

organização gastará alguns recursos preciosos para estabelecer e manter as funções

de gestão de recursos da informação, o aumento no desenvolvimento de sistemas de

produtividade utilizando a engenharia de sistema do governo eletrônico compensará

este investimento.

2.3. Gestão da Mudança e Evolução

A engenharia de sistema do governo eletrônico fornece um mecanismo para

gerir a mudança em uma organização. A adição, eliminação ou revisão de uma regra

comercial requer uma avaliação do modelo de dados e do processo a partir de uma

ampla perspectiva. Isto pode levar a modificações em diversos sistemas. As mudanças

na tecnologia ou nas exigências de sistema exigem modificações em todos os modelos

de sistema, assim como em todos os sistemas implementados. Através da separação

dos aspectos que são tecnologicamente independentes da gestão da mudança das

implementações que são dependentes de tecnologia, a manutenção do sistema é um

processo evolucionário que permite que uma organização controle seu próprio destino.

2.4. Migração para uma Arquitetura Alternativa

Uma vez que os modelos dos dados e dos processos tecnologicamente

independentes tenham sido desenvolvidos para uma área funcional, eles fornecem as

bases para a formulação e a implementação do sistema. Em alguns casos, o ambiente

de destino para a implementação de uma área funcional particular já pode ter sido

especificado. Entretanto, em diversas situações, os dados e os modelos de negócios se

tornam a linha de base para avaliar as tecnologias alternativas. Isto permite que uma

organização selecione configurações ideais de hardware e de software, e que a rede

baseada no orçamento disponível atenda suas necessidades. Pode ser necessário mais

de um ambiente de destino para satisfazer as necessidades comerciais representadas

pelos modelos de dados e de processo. Entretanto, ao invés de meramente servir como


interface entre os diferentes ambientes, eles podem ser completamente integrados e

podem aproveitar os principais fatores de cada ambiente.

2.5. Reengenharia e Engenharia Reversa

A reengenharia enfatiza a racionalização dos processos de negócios de uma

organização para se obter o máximo de vantagens de uma moderna tecnologia da

informação e para se obter uma abordagem total dos dados de construção e dos

modelos comerciais. Ela rende resultados de alta qualidade em um curto período de

tempo enquanto que também garante a compreensão por parte do usuário. Para as

organizações com sistemas atuais que não se encontram bem documentados, pode ser

necessária uma abordagem completa e uma engenharia reversa. A engenharia de

sistema do governo eletrônico utiliza os princípios de normalização dos negócios e os

princípios de engenharia reversa para extrair os modelos de base de dados das

estruturas de dados e do código de programas e desenvolve dados tecnologicamente

independentes e modelos de processo que são capazes de adaptar diferentes

plataformas dependentes de tecnologia. Este processo de engenharia reversa é

possível para aquelas organizações que não estão sujeitas à mudança por causa de

sua regulamentação ou devido a outras restrições.

3. Desenvolvimento de Sistemas Estruturados do Governo Eletrônico

A engenharia de sistema do governo permite que uma organização maximize as

vantagens obtidas das tecnologias emergentes. Os benefícios variam desde as novas

ideias dentro da visão comercial estratégica de uma organização até o planejamento

detalhado e a utilização otimizada das novas tecnologias. Pode-se obter benefícios a

curto e a longo prazo. Uma vez estabelecido, o retorno da implementação da

engenharia do sistema de governo eletrônico garante não apenas a produtividade e a

qualidade, mas também o sucesso em longo prazo da organização.

Por este motivo, este módulo fornece uma breve introdução da metodologia de

desenvolvimento de um sistema estruturado de governo eletrônico, que é uma das

técnicas mais importantes de engenharia de sistema do governo eletrônico e que é

muito útil, em particular, para o amplo e complexo desenvolvimento do sistema de


governo eletrônico. A medida em que o tamanho do projeto diminui, algumas fases de

desenvolvimento podem ser combinadas.

Considerando que um projeto de governo eletrônico é realizado de acordo com

um padrão normal e ordenado, pode-se esperar que ele siga as seguintes fases gerais:

• Inicialização do projeto

• Análise de exigências, incluindo a análise do negócio, a avaliação dos

componentes existentes do sistema, a identificação de problemas e a análise de

viabilidade de abordagens alternativas; a formulação lógica, incluindo a

reformulação de fluxo dos negócios, o incentivo do fluxo da informação e a

formulação da arquitetura do sistema.

• Formulação física, incluindo as especificações de hardware, software e

instalações de comunicação, formulação de rede e cabo e segurança do

sistema.

• Implementação, incluindo o estabelecimento de base de dados, entrada de

dados e desenvolvimento de software de aplicação.

• Operação, incluindo a fusão do sistema no ambiente normal de negócio,

atualização dos dados e manutenção do sistema.

• Avaliação de pós-implementação.

Existem diferentes formas de se dividir em fases o ciclo de vida de

desenvolvimento do sistema da informação. Entretanto, elas podem ser divididas em

três estágios principais: análise, modelo e implementação. Estes três estágios são

agrupados (precedido e realizado) através da inicialização do projeto e da revisão do

mesmo. Além disso, todas estas atividades incluem as tarefas administrativas de

planejamento, agendamento e controle.

3.1. Análise Preliminar

A inicialização do projeto é realizada através da análise preliminar. A análise

preliminar constitui a primeira e talvez a fase mais crucial do desenvolvimento de um

projeto. Em muitos casos ela se torna o próprio projeto inteiro, uma vez que o


desenvolvimento da informação nesta fase pode indicar que não é necessário, possível

ou desejável um trabalho adicional. Em todos os casos, os resultados da fase de análise

determinam se há algum problema a ser resolvido; se existe alguma solução possível

para o problema e se o desenvolvimento da solução para o problema é benéfico

financeiramente para o usuário e para a agência governamental como um todo.

O principal objetivo da análise primária é decidir se um projeto deve ser iniciado

ou não para desenvolver um sistema de governo eletrônico solicitado pelos usuários.

Mesmo nesta fase inicial, os resultados do estudo preliminar determinarão se existem

benefícios suficientes antecipados para justificar a continuidade do projeto para a

próxima fase de desenvolvimento.

Uma análise preliminar detalhada deve ser direcionada para os seguintes itens:

• Os problemas atuais a serem eliminados a partir do ambiente do usuário e a

exploração das oportunidades comerciais atuais e futuras.

• A definição da missão do sistema e a tradução das necessidades comerciais do

usuário em um conjunto claro de objetivos de projetos comerciais.

• O ajuste de delimitadores para a área de estudo do projeto.

• A identificação de possíveis restrições e riscos do projeto.

• A busca inicial para potenciais soluções de implementação do sistema.

• Análise de custo-benefício.

Enquanto se identifica os problemas atuais, geralmente é dada muita atenção à

forma como a tecnologia da informação poderia ser utilizada para melhorar a

efetividade, eficiência, produtividade e qualidade das agências governamentais.

Entretanto, isto está longe de ser o suficiente. Deve-se dar uma forte ênfase à análise

dos processos comerciais atuais da organização para ver se eles se adéquam ao seu

propósito. O novo sistema de governo eletrônico deve ser integrado ao ambiente

comercial existente apenas se for justificável, através da demonstração de eficiência dos

processos comerciais atuais. Caso contrário, deve-se considerar a hipótese de

reformulação dos processos comerciais.


Os problemas e/ou as oportunidades identificadas ou descritas pelos usuários

devem ser priorizadas por ordem de importância. Esta classificação é necessária para

diferenciar as questões que são muito importantes e aquelas que, apesar de serem

úteis para o direcionamento, não são essenciais para o projeto de imediato. Um modo

possível de classificá-las poderia ser como segue adiante:

3.1.1. Essencial. Requisitos sem os quais o usuário não poderia operar

adequadamente no ambiente comercial.

3.1.2. Adaptável. Requisitos que, se necessário, podem ser parcialmente modificados

para permitir modos alternativos de operação.

3.1.3. Bom ter. Requisitos que o usuário está disposto a documentar, mas que podem

ser excluídos da lista de exigências do sistema caso estas se demonstrem muito

custosas de serem atendidas.

Os objetivos do projeto devem direcionar os problemas e/ou as oportunidades

que foram identificadas durante a análise da situação atual. Os objetivos do projeto

devem ser definidos em um formato conciso, mensurável e atingível.

Na realidade um estudo formal das possibilidades deve ser conduzido durante

esta fase. Através deste estudo, deve-se obter um acordo do âmbito do projeto entre a

gestão da organização do usuário e a equipe do projeto. Juntamente com o relatório

estão as justificativas para o projeto, os limites claramente definidas para o

desenvolvimento, e um modelo de plano de trabalho indicando como o desenvolvimento

deve ser realizado.

3.2. Análise de Requisitos

A análise de requisitos tenta descobrir o que é desejável e verdadeiramente

necessário aos usuários; tenta esclarecer os produtos que irão satisfazer um conjunto

completo de desejos; e descobrir quem desempenhará a maior parte no processo de

requisitos. Obviamente que a análise de requisitos é essencial para o desenvolvimento

bem sucedido de um sistema de governo eletrônico porque se os desenvolvedores do

sistema não sabem o que o usuário (por exemplo, as empresas ou os cidadãos) precisa,

ou se não se comunicam adequadamente com os usuários, as funções e o desempenho

do sistema não poderão ser definidos corretamente. Qualquer sistema de governo


eletrônico que falhe em atender as necessidades reais dos usuários finais não irá durar

muito tempo.

A determinação das exigências começa com uma análise minuciosa dos fluxos

dos negócios atuais e das estruturas organizacionais que sejam relevantes para o

sistema proposto. Através da coleta de dados e através de entrevistas com os usuários

do sistema que será desenvolvido, a análise pretende responder as questões que são

especificadas nos parágrafos seguintes.

3.3. Atividades da Fase de Análise

A forma mais importante de conduzir uma análise de requisitos é entrevistando

os usuários, em particular as pessoas que são fundamentais para o processo comercial

e os usuários finais do sistema. A partir de diferentes níveis de sistemas de governo

eletrônico, diferentes níveis de usuários precisam ser selecionados para entrevistas. Ao

entrevistar os usuários, as principais questões são em relação a aprendizagem sobre o

negócio do usuário, compreender a terminologia do usuário e fazer as perguntas certas.

A sequência lógica da entrevista é:

• Em primeiro lugar, averiguar sobre o fluxo do negócio e de informação na

organização. Inicie com as saídas: Que informação é necessária para realizar o

negócio? Como os dados devem fluir entre as agências e os indivíduos?

Determine a freqüência, o prazo e a precisão.

• Em segundo lugar, identificar as entradas impulsionadas pelas saídas: Que

informação é necessária para produzir cada uma das saídas? Quais informações

estão disponíveis? Quando? Onde? Quais informações novas precisam ser

armazenadas?

O objetivo da análise de requisitos é documentar as funções, processos,

atividades e dados de usuários existentes. As atividades na fase de análise são as

seguintes: análise de função atual; desenvolvimento do modelo funcional atual;

processo atual e análise de atividade; desenvolvimento do modelo de processo atual;

fonte de dados atuais e análise de uso; análise de dados atuais; e desenvolvimento do

modelo de dados atual. Após esta análise, pode ser recomendado realizar uma

abordagem adequada para atender as exigências do usuário, a qual geralmente é


selecionada a partir do: desenvolvimento de um sistema personalizado; implementação

de um pacote de vendedor/fornecedor com ou sem modificação; e reengenharia do

sistema computacional atual. O modelo de qualquer novo sistema precisa ser atributo a

partir da compreensão do sistema antigo. Mesmo para um sistema completamente

novo, é necessário considerar cuidadosamente a utilização total de todos os recursos

existentes.

A validação da análise de requisitos é importante o suficiente para justificar um

tratamento separado. Toda a documentação analítica precisa ser validada para garantir

que todas as partes concordam de que as condições apresentadas na documentação

representam precisamente o ambiente, e que os documentos gerados contêm as

definições que são completas, precisas, inequívocas e testáveis.

As análises requeridas devem resultar em um Documento de Requisitos (DR),

que define os problemas e as demandas do usuário e as soluções gerais necessárias. A

linguagem deve ser orientada para o negócio do usuário e jargões computacionais

devem ser evitados. O DR algumas vezes é utilizado como uma Solicitação de Proposta

(SDP) quando o usuário propõe o projeto para contratantes externos. Entretanto um DR

escrito pelo usuário geralmente é inadequado para estimar o desenvolvimento porque o

mesmo pode não estar ciente do que o sistema baseado em computador pode fazer, e,

portanto o (DR) geralmente pode ser vago. Um usuário pode não perceber corretamente

suas próprias necessidades se ele não estiver atualizado com as tecnologias de

computação e de comunicação. Outros problemas surgem devido a dificuldades de

comunicação. Não se pode esperar que uma pessoa não-técnica aprenda linguagem

computacional e os jargões para explicar seus requisitos a um analista de sistemas. A

equipe de projeto é quem deve notar e resolver qualquer problema relacionado a isto.

As experiências de diversos analistas de sistemas têm demonstrado que vale a pena

que a equipe do projeto gaste algum tempo trabalhando para ajudar o usuário a

escrever um bom documento de requisitos.

3.4. Participação dos Usuários

É obrigatório que durante esta fase seja obtida uma participação ativa dos

usuários, incluindo empresas, cidadãos e funcionários do governo, e qualquer outro que

possa ser necessário porque eles são importantes no sistema. Isto é, sem sombra de


dúvidas, um fator extremamente fundamental para o sucesso. Por exemplo, as

necessidades e os objetivos do negócio de um projeto não podem ser desenvolvidos

adequadamente sem o comprometimento estável do usuário para auxiliar na fase inicial

do processo a definir os mesmos. Este é o único modo de garantir que o sistema

solicitado esteja precisamente alinhado com as metas do negócio de seus

departamentos e com as metas de toda a organização. Portanto, os usuários precisam

participar ativamente e articular suas próprias necessidades. De fato esta declaração

permanece válida para todos os produtos distribuídos que são produzidos durante as

fases de análise preliminar e de requisitos. Isto enfatiza que o envolvimento do usuário

deve ser visto como propício para o sucesso do projeto. O sistema que será

desenvolvido será tão eficiente em apoiar as áreas funcionais do usuário de acordo com

a participação dos usuários no desenvolvimento das exigências do sistema,

especialmente durante os estágios essenciais do processo de análise. Através das

técnicas de desenvolvimento direcionadas ao usuário, tais como os protótipos, mais e

mais sistemas de governo eletrônico serão desenvolvidos com sucesso pela equipe de

usuários e analistas de sistema que trabalham em estreita colaboração durante todo o

projeto.

Os projetos mais bem sucedidos geralmente são realizados sob uma

responsabilidade formal dos usuários. Apesar do sistema poder ser desenvolvido por

profissionais de computação e de comunicação, a responsabilidade final do projeto recai

nas mãos dos usuários conhecedores e capazes, que são oficialmente responsáveis

pelo novo sistema.

3.5. Treinamento dos Usuários

É importante familiarizar os usuários que irão participar diretamente do projeto

com as técnicas de definição de requisitos que serão utilizadas. Isto ajudará a unir a

lacuna de comunicação que possa existir entre os usuários e os desenvolvedores de

sistema. Devem ser desenvolvidos cursos especificamente para auxiliar a remover a

nuvem de mistério ao redor do desenvolvimento de um sistema de governo eletrônico.

No geral, estes cursos descrevem o processo de desenvolvimento do sistema em

termos simples que sejam fáceis de serem compreendidos a partir do ponto de vista do

usuário. Durante estes seminários, os conceitos especializados (e algumas vezes

esotéricos) do sistema de governo eletrônico e o vocabulário utilizado pelos


desenvolvedores de sistema de informação também são explicados, juntamente com

uma breve descrição de diversas ferramentas gráficas e técnicas que são aplicadas

durante o processo comercial e as tarefas de modelagem de dados. Devido ao

investimento que será utilizado no desenvolvimento de um grande sistema de governo

eletrônico, sem mencionar o fato de que tal sistema durará pelo menos entre 10 a 15

anos, um curso de um a cinco dias de duração é um preço pequeno a ser pago para se

tentar entregar um sistema de alta qualidade que pretende atender verdadeiramente as

necessidades do usuário.

3.6. Modelo do Sistema

A proposta de modelo do sistema é definir a arquitetura interna do sistema de

governo eletrônico. Para uma ampla e complexa aplicação, as questões do modelo

associadas com as características de desempenho, usabilidade e manutenção do

sistema são de grande importância. Consequentemente, os modelos de dados físicos e

do processo devem ser elaborados de tal forma que ofereça o máximo de flexibilidade

possível enquanto leva em conta as restrições físicas que possam ser impostas pela

tecnologia que está sendo selecionada para ser implementada no sistema. Qualquer

desvio dos requisitos originais no processo funcional e nos modelos de dados que

possam ser necessários para atender o critério especifico do sistema operacional

devem ser adequadamente documentados e discutidos minuciosamente com os

usuários. As estratégias para testar o sistema, a conversão de dados, o treinamento do

usuário final e a instalação do sistema também devem ser cuidadosamente elaboradas.

Com base na análise de requisitos do usuário pode-se definir as funções do

sistema a serem desenvolvidas. Durante o desenvolvimento das funções, os

desenvolvedores do sistema precisam capturar todas as funções relevantes e

compreender as evidentes, ocultas e acessórias. As funções evidentes são aquelas que

devem ser realizadas de modo que seja visível ou evidente para os usuários, se

possível. As funções ocultas devem ser as mais imperceptíveis possível para o usuário.

As funções acessórias são aquelas que o usuário gostaria que estivessem presentes,

mas não se elas não tiverem algum custo diretamente ou se elas comprometerem

outras funções. Classificar a lista de funções em ocultas e evidentes ajuda a identificar

as possibilidades que podem ser negligenciadas. Isto ocorre porque ao se classificar


deste modo, se enfatizam as funções do sistema, que de outra forma poderiam ser

subestimadas.

A definição das funções deve ser produzida colaborativamente com os usuários

através do desenvolvimento de uma lista inicial das funções potenciais e da

classificação de cada função como evidente, oculta ou acessória. As novas ideias

podem ajudar a descobrir funções ocultas não mencionadas que irão ampliar a lista de

funções. Durante o processo de classificação destas funções, deve-se buscar por

funções com formulação que implique alguma restrição da solução e deve-se

transformar tal texto em declarações de problemas, ao invés de priorizar a busca de

declarações de soluções; finalmente deve-se criar uma lista de funções acessórias.

Existem diversas questões que também são importantes, as quais precisam ser

elaboradas dentro de um modelo de sistema lógico. Elas estão identificando as

restrições e os riscos, definindo as preferências e limitando as expectativas do sistema a

ser desenvolvido.

Identificar as restrições e os riscos que existem no desenvolvimento do sistema

é uma questão importante. As restrições técnicas e comerciais e os riscos, pertencem

às mesmas condições que foram consideradas fora da influencia direta ou do controle

dos membros da equipe do projeto. Entretanto, ao mesmo tempo, eles podem ter um

impacto direto no âmbito do projeto, em seu cronograma e nas propostas de soluções

alternativas de implementação. As restrições ou os riscos que podem afetar o projeto

incluem os seguintes itens: estabilidade organizacional em termos de políticas, funções

e estruturas; regulamentações governamentais; limitações de orçamento; considerações

políticas; considerações de cronograma; considerações legais; considerações

ambientais; limitações operacionais; disponibilidade de dados; considerações com

relação a hardware/software/rede; considerações pessoais; limitações técnicas; e riscos

associados com a utilização de novas tecnologias não testadas. Para que a solução do

projeto final seja aceitável, todas as restrições ou riscos devem ser atendidos. Portanto,

uma restrição ou um risco deve ser definido em termos que permitam que os

participantes determinem objetivamente se estes foram atendidos ou não no produto

final.


Definir as preferências é outra tarefa durante a fase de análise do sistema. A

preferência é desejável, porém é uma condição opcional ou um atributo. Qualquer

solução de modelo final que atenda todas as restrições é considerada como uma

solução aceitável, porém algumas soluções aceitáveis podem ser preferíveis a outras.

As preferências permitem que o designer do sistema possa comparar as soluções

aceitáveis e escolher as melhores. É melhor elaborar preferências mensuráveis já que

estas são utilizadas pelos designers para orientá-los a satisfazer seus clientes. Portanto,

as preferências não serão de muita valia, a não ser que cada uma seja definida em

termos que possibilitem os designers determinarem em que grau a preferência será

atendida.

Limitar as expectativas do sistema a ser desenvolvido também é importante. Se

o(a) desenvolvedor(a) considera o processo de elaboração como uma forma de atender

todas as expectativas e de evitar todos os desapontamentos, ele/ela nunca será bem

sucedido(a). É importante compreender, definir, comunicar e controlar as expectativas

de todas as pessoas envolvidas. Com o objetivo de levantar e documentar as

expectativas e as limitações deve-se gerar primeiramente uma lista das expectativas

específicas dos usuários representativos. Os desenvolvedores do sistema precisam

trabalhar com a lista para compreender e generalizar cada expectativa. Eles precisam

então negociar para limitar as expectativas a um nível razoável, deixando aberta todas

as possibilidades para as futuras modificações do sistema, porém excluindo

definitivamente tudo que não possa ser razoavelmente esperado. Ao se definir um

limite, a fonte da limitação deve ser documentada, porque as limitações de hoje podem

se tornar as oportunidades de amanhã.

Um modelo de sistema lógico identifica as relações lógicas dos elementos

internos e externos que são essenciais para o sistema, por exemplo, os fluxos de

processos comerciais que o sistema irá apoiar e os fluxos de informação que serão

processados pelo sistema. Os fluxos de processos comerciais representam o modelo de

negócio da informação e os fluxos de informação descrevem o modelo de

dados/informações da organização. Os modelos de negócios e os modelos de

dados/informações são independentes tecnologicamente e direcionam a arquitetura do

sistema a um nível lógico. O modelo de sistema lógico também identifica as funções

realizadas pelo novo sistema ou pelo sistema melhorado e especifica o que o novo

sistema ou o sistema melhorado fará para apoiar o fluxo de negócios da organização.


O modelo lógico deve ser um documento não-técnico acessível aos profissionais

do sistema e também aos usuários. Uma vez que o usuário-gerente tenha confiança de

que o novo sistema irá atender as necessidades da organização e aprove o modelo

lógico, o modelo físico do sistema poderá ser iniciado.

O modelo físico determina a arquitetura do sistema em um nível físico, o qual é

tecnologicamente dependente, e desenvolve o modelo do sistema. O modelo físico de

um sistema de governo eletrônico inclui as especificações de como o modelo lógico será

implementado. Isto envolve coisas como as especificações de todos os procedimentos

manuais e computadorizados; arquitetura do sistema e topologia de rede; seleção de

hardware e software computacionais; modelo dos arquivos de dados físicos solicitados;

especificações de todos os programas e/ou procedimentos necessários; e segurança

física do sistema. Este processo é razoavelmente técnico e requer a participação do

usuário, especialmente ao detalhar os procedimentos de processamento de dados do

manual.

O modelo finalizado do sistema físico deve ser documentado em dois níveis.

Deve-se redigir uma visão geral do modelo que inclua as descrições do sistema e dos

subsistemas de aplicação; as inter-relações dos subsistemas; a arquitetura do sistema;

os procedimentos de operação ou de captura de dados; e o procedimento de auditoria.

Também se deve incluir uma descrição de suas bases de dados, uma amostra dos

documentos ou dos formatos de entrada/saída, e as medidas de segurança do sistema.

Também deve detalhar a relação e a interface do sistema atual para outros sistemas de

governo eletrônico dentro do ambiente organizacional. Esta visão geral do modelo deve

ser aprovada pela gerência da agência governamental antes que as descrições técnicas

detalhadas sejam especificadas.

Além da visão geral do modelo e do segundo nível de documentação, devem-se

detalhar as especificações para um dicionário de dados, arquivos, banco de dados,

documentos de entrada/saída, telas, programas e procedimentos, um sistema de

cabeamento e programas de treinamento de usuários.

3.7. Implementação do Sistema

O principal propósito da fase de implementação é entregar um sistema

operacional completo aos usuários. Com base nas especificações de modelo do sistema


que foram produzidas durante as fases anteriores, os programas de software são

codificados, testados e gradualmente integrados em um sistema completo. Os

procedimentos manuais e administrativos do sistema são finalizados e testados em

conjunto com a porção automática do sistema. Os manuais de documentação do

usuário e do sistema são finalizados e a equipe é adequadamente treinada. Os dados

dos arquivos antigos são acondicionados nas novas estruturas de arquivos/banco de

dados do sistema. O equipamento e as instalações adequadas de

hardware/software/rede são instalados nos locais do usuário e o sistema e seus

materiais de apoio são transferidos para o ambiente de produção. Se necessário, o

sistema é ajustado durante o primeiro mês após sua instalação na produção.

Os usuários precisam participar dos testes do software, programas,

procedimentos e bases de dados da aplicação para que possam entender melhor o

sistema. Diversas técnicas podem ser utilizadas para garantir a qualidade. Deve-se dar

uma atenção especial à documentação. Programas de treinamento devem ser

desenvolvidos para os usuários que estão em diferentes níveis e materiais relacionados

ao novo sistema como parte do processo de implementação. Estes devem incluir a

preparação de informativos e de seminários para a transmissão da informação geral

relacionada ao sistema; aulas específicas e materiais para fornecer um treinamento

detalhado dos conceitos e procedimentos do sistema; um programa de treinamento em

serviço ou prático para aqueles que serão indicados para trabalhar diariamente com o

novo sistema.

É necessário realizar um teste de aceitação antes de colocar o novo sistema em

operação. Todas as funções prometidas e produtos a serem distribuídos devem ser

demonstrados no teste de aceitação. O sistema é finalizado como um projeto global

quando:

• O novo sistema é ajustado e funciona sem problemas.

• A conversão ou a exclusão de quaisquer sistemas antigos é finalizada. A

exclusão deve ser feita, se possível, em etapas.

• Os usuários finais são treinados e se sentem à vontade com o sistema.


• É realizada uma revisão do projeto posteriormente e todos os itens que podem

beneficiar os projetos futuros estão documentados.

• Define-se a responsabilidade e o método de manutenção em andamento.

Sempre haverá a necessidade de modificar um sistema para melhorá-lo,

adicionar novas características ou arrumar quaisquer problemas que ainda permanecem

após a aceitação ou a garantia do sistema terminar. Na maior parte das vezes, o

negócio do usuário irá mudar com o tempo e do mesmo modo seus requisitos também

mudarão. Estas mudanças ou melhorias tornam a manutenção do sistema

indispensável.

A conversão deve ser um processo bem planejado, no qual os usuários devem

participar. Arquivos e documentos devem ser criados, os formulários devem ser

impressos e os novos procedimentos devem ser instituídos.

Deve ser desenvolvida uma versão preliminar dos diferentes tipos de manuais do

sistema que são necessários para utilizar, operar e manter o sistema em produção.

Neste estágio inicial da fase de implementação, estes manuais podem ser

desenvolvidos como um esboço. Entretanto, eles devem conter informação suficiente

para apoiar os usuários e eventualmente a equipe de operações do sistema durante o

ciclo de aceitação do usuário e dos testes de aceitação da produção.

O guia do usuário do sistema deve ser sempre escrito em uma linguagem que

seja de fácil compreensão a partir do ponto de vista do usuário. Os jargões técnicos

devem ser evitados. Os usuários não precisam saber como o sistema funciona

internamente, mas deve saber como lidar com os componentes automatizados de um

modo adequado e eficaz.

O guia de manutenção do sistema descreve as funções de alto nível e facilita

que elas sejam realizadas pela aplicação do software, focando-se primeiramente na

perspectiva técnica. Ele contém narrativas gerais do programa e descreve as

características técnicas importantes do sistema (ou seja, sua arquitetura interna e

externa). Seu objetivo primário apoiar os esforços da equipe de manutenção. Entretanto,

ele não descreve necessariamente as especificações do programa em detalhes. A

informação detalhada associada com o programa pode estar em um guia separado.


O guia de operações do sistema fornece uma descrição do documento detalhado

que é exigido pelo pessoal do centro de informação/dados para operar o sistema

durante a produção. Comumente, o tipo de informação que deve ser descrita para cada

trabalho de produção dentro de um ciclo de processamento específico (diário, semanal,

mensal ou anual) inclui a preparação do trabalho, a execução do trabalho e a

distribuição do resultado do trabalho.

Um pacote de treinamento do sistema deve ser preparado durante a fase de

implementação. Os materiais do treinamento devem ser desenvolvidos em um esboço

desde o estágio inicial desta fase. O esboço deve conter informações suficientes para

apoiar o treinamento inicial dos participantes da equipe de usuários que irão conduzir os

testes de aceitação do usuário. A estratégia detalhada de treinamento do sistema deve

ser revisada para se verificar se toda a informação referente ao novo sistema foi

produzida. Além disso, o esboço do pacote de treinamento do sistema deve ser

analisado para verificar se o mesmo é preciso e se atende os objetivos de treinamento

definidos.

O esboço final dos materiais de treinamento formal deve preparar e treinar de

modo adequado os usuários e o pessoal de operações do sistema e de manutenção em

como utilizar, operar e apoiar o sistema de forma mais efetiva antes de sua

implementação no ambiente de produção. Os materiais de treinamento podem incluir

folhetos, slides, transparências e outros. Estes materiais devem ser designados de cima

para baixo, descrevendo o sistema desde uma forma bem generalizada até uma forma

bem específica. Em algumas instâncias, será necessário modelar alguns componentes

específicos do pacote de treinamento para que se adéquem às necessidades

específicas do público-alvo.

Uma vez que o sistema esteja em operação, deve-se realizar uma avaliação

pós-implementação. O propósito de se realizar isto é para determinar quão bem o

sistema atende os objetivos planejados. O desempenho geral e o nível de operabilidade

de todo o sistema devem ser julgados a partir do ponto de vista do tempo de resposta

dos programas online; do tempo de execução dos programas de lote; do tempo de

execução dos utilitários do sistema para que estes sejam efetuados; das instalações de

segurança; do equipamento do computador instalado; da operação do computador e

das instruções de controle do trabalho; da documentação geral do usuário/sistema; e da


efetividade da rede de comunicação do sistema, assim como a partir de qualquer

indicador adicional relacionado com os objetivos originais. A avaliação pode ser

realizada pela equipe do projeto ou pelos auditores dos sistemas internos.

A otimização pós-implementação do sistema pode ser realizada com base nos

resultados da avaliação. As áreas específicas em que os requisitos originais do sistema

não tenham sido completamente atendidos devem ser identificadas. A equipe do projeto

também deve determinar as causas dos problemas e deve aplicar as medidas

adequadas. Um conjunto completo de documentos do sistema e de otimização do

sistema de produção deve também ser incluído na tarefa de otimização.

A metodologia de desenvolvimento do sistema de governo eletrônico introduzida

neste módulo baseia-se nos princípios e nas práticas do ciclo de vida de

desenvolvimento do sistema. Existem diferentes tipos de sistemas de governo

eletrônico. Entretanto, os três estágios principais permanecem sendo os mesmos, ou

seja, a análise, a formulação e a implementação. Algumas destas fases e atividades

dentro dos estágios serão diferentes, dependendo de que tipo de desenvolvimento de

sistema de governo eletrônico esteja sendo realizado.

4. Gestão do Projeto

O planejamento, a organização, o recrutamento e o controle são as quatro

principais atividades que fazem que os programas/projetos sejam bem sucedidos.

Os projetos bem sucedidos precisam ter uma inicialização bem definida – um

plano escrito que defina o que será entregue e como isto será obtido. Um critério de

aceitação mensurável deve ser documentado de modo que este possa ser utilizado

como referência para se verificar que as promessas foram atendidas.

Durante o desenvolvimento deve-se realizar um monitoramento minucioso para

garantir que o projeto procede de acordo com o planejado. A equipe do time do projeto

deve ter uma experiência adequada para produzir o produto. Os documentos devem ser

produzidos corretamente para as pessoas certas, mesmo em uma situação de curto

prazo, pois a gestão deve dar conta de que a documentação é um dos aspectos mais

importantes do projeto. São necessárias frequentes revisões do projeto para medir o


progresso em relação ao cronograma. Quando ocorre um problema, este deve ser

noticiado pelo menos uma vez e, se possível, resolvido; caso contrário, as estimativas e

os cronogramas devem ser reelaborados e as expectativas devem ser reajustadas de

acordo com a necessidade.

No final, a satisfação do usuário deve ser a primeira preocupação da equipe do

projeto. O produto que a equipe entrega deve ser de acordo com o que foi prometido. O

custo do projeto precisa ser controlado para que esteja “razoavelmente perto” da

estimativa calculada. Não deve haver desacordos com relação à aceitação. O método

preciso e detalhado que será utilizado para demonstrar as funções exigidas do produto

deve ser aprovado pelos usuários antes do tempo.

Uma equipe organizacional eficiente, para um projeto de sistema de governo

eletrônico de pequeno ou médio porte deve ser composta pelo gerente do projeto, o

líder do projeto, os analistas de sistema e os programadores de software.

Cada pessoa da equipe possui uma descrição de trabalho específica. Os

analistas de sistema são responsáveis pela análise do sistema e pela formulação lógica

do sistema. A formulação física e a implementação do sistema são acompanhadas de

perto pelos analistas de sistema e programadores. Os programadores criam os

softwares de aplicação e conduzem a formulação da base de dados. O líder do projeto

realiza uma supervisão minuciosa através da liderança de atividades técnicas

resolvendo quaisquer problemas do sistema. A principal responsabilidade do líder do

projeto é garantir a qualidade do produto. O gerente do projeto, a quem o líder do

projeto se reporta, está presente para fornecer liderança de gerenciamento e para lidar

com todas as comunicações entre a equipe do projeto e a parte externa. As

responsabilidades do gerente do projeto incluem a gestão geral dos recursos do projeto

e a implementação bem sucedida dos objetivos, saídas e atividades do projeto.

Em um projeto amplo, os analistas de sistema podem ser divididos em diversas

equipes. Através desta abordagem, as equipes individuais podem lidar com sua porção

do projeto como um subsistema, ou como um projeto isolado. Os termos de referência

dos líderes das equipes precisam ser claramente definidos e todos os líderes de equipe

precisam se reportar e serem supervisionados pelo líder do projeto.


Os gerentes do projeto são a chave para garantir o sucesso de qualquer projeto

de sistema de governo eletrônico. Eles são responsáveis pelo sucesso da formulação,

implementação, integração, operação e manutenção dos sistemas. A parte mais difícil

do desenvolvimento do sistema de governo eletrônico é se certificar de que o gerente do

projeto, como integrador do sistema, entende exatamente o que os usuários querem e

garante que eles não falam uma linguagem diferente dos usuários. No geral, os usuários

buscam mais do que conhecimento técnico de seus integradores de sistemas. Os

gerentes do projeto devem ter uma boa compreensão do negócio central dos usuários

do sistema de governo eletrônico. Uma solução meramente técnica apenas pode

beneficiar minimamente os usuários. Um gerente de projeto deve ter os seguintes

atributos:

4.1. Deve ter um vasto conhecimento da organização vertical do negócio e

preferencialmente deve ter um cargo executivo nesta linha.

4.2. Deve ser capaz de trabalhar com os gerentes de linha no negócio para definir as

exigências e realizar a implementação atual dos sistemas de governo eletrônico.

4.3. Deve ter uma compreensão profunda dos conceitos técnicos relevantes e

capacidade para traduzi-los em requisitos comerciais e em requisitos para o

desenvolvimento técnico dos sistemas.

4.4. Deve ser um bom comunicador, trabalhar bem com as equipes e ter boas aptidões

de negociação.

4.5. Precisa ser uma pessoa que saiba direcionar os detalhes, que possa traçar as

linhas atuais de tempo para a finalização de um determinado projeto, traçar os pontos

de partida e ser o ponto único de referência, como integrador do sistema, para os

usuários.

metodologias de desenvolvimento de sistemas do governo...

Documents