DCC/NPPG
GERENCIAMENTO DO ESCOPO: PROJETO DE DOCUMENTAÇÃO E
PADRÕES EM MAINFRAME, PARA INSTITUIÇÕES FINANCEIRAS
Sávio Almeida Silveira
Sávio Almeida Silveira
M o n o g r a f i a a p r e s e n t a d a n o C u r s o d e
P ó s - G r a d u a ç ã o e m G e r e n c i a m e n t o d e
P r o j e t o s , d a E s c o l a P o l i t é c n i c a , d a
U n i v e r s i d a d e F e d e r a l d o R i o d e J a n e i r o .
Orientadores:
Alexsandro Amarante da Silva
Daniel Martins Ramos
Fortaleza Dezembro, 2007
Sávio Almeida Silveira
Orientadores:
Alexsandro Amarante da Silva
Daniel Martins Ramos
Monografia submetida ao Curso de Pós-graduação Gerenciamento de Projetos, da Escola Politécnica, da Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Aprovado por:
_____________________________________ Eduardo Linhares Qualharini
_____________________________________ Alexsandro Amarante da Silva
_____________________________________ Humberto Augusto Correia Vieira
Fortaleza Dezembro, 2007
SILVEIRA, Sávio.
Escopo de Projeto de Documentação e Padrões
de Sistemas de Mainframe em Instituições Financeiras / SILVEIRA, S. A. - Ceará: UFRJ / EP 2007.
viii, 32f. il.; 29,7cm.
Orientador: Alexsandro Amarante da Silva, Daniel Martins Ramos.
Monografia (especialização) – UFRJ / Escola Politécnica / Curso de Especialização em Gerenciamento de Projetos, NPPG, 2006.
Referências Bibliográficas: f. 32
1. Documentação. 2. Padrões. 3. Gerencia de Projetos I. AMARANTE, A. S., MARTINS, D. R. II. Universidade Federal do Rio de Janeiro, Escola Politécnica, Pós-Graduação III. Especialista.
A minha família que sempre me apoiou em
crescer profissionalmente e aos meus amigos
que também são responsáveis pelas minhas
conquistas e em muito me ajudaram na
conclusão deste curso.
GERENCIAMENTO DO ESCOPO: PROJETO DE DOCUMENTAÇÃO E PADRÕES
EM MAINFRAME, PARA INSTITUIÇÕES FINANCEIRAS
Sávio Almeida Silveira
Resumo da Monografia submetida ao corpo docente do curso de Pós-Graduação em Gerenciamento de Projetos – Universidade Federal do Rio de Janeiro – UFRJ, como parte dos requisitos necessários à obtenção do título de Especialista em Gerenciamento de Projetos.
Este trabalho aborda os conceitos, ferramentas, processos de software e o aspecto gerencial de uma Instituição Financeira. Inicialmente é feita uma abordagem sobre as instituições financeiras brasileiras e sobre ferramentas utilizadas na instituição financeira do estudo de caso, descrevendo seus componentes, processos de implementação e histórico tanto no ramo da tecnologia da informação, como dentro da própria instituição. Por fim, apresenta-se um estudo de caso que descreve o projeto de documentação e padronização de um sistema da plataforma Mainframe, seguido de algumas críticas e sugestões e os artefatos utilizados durante o projeto.
Palavras-chave: Documentação, Padrões, Gerência de Projetos
Fortaleza Dezembro, 2007
1.1 Justificativa ... 01
1.2 Objetivo ... 01
1.3 Estrutura do Trabalho ... 02
2. INSTITUIÇÃO E TECNOLOGIA DA INFORMAÇÃO ... 03
2.1 Instituições Financeiras no Brasil ... 03
2.2 COBOL ... 05
2.3 Mainframe ... 09
2.4 UML ... 11
2.5 RUP ... 16
2.6 Sobre RUP e UML ... 19
3. ESTUDO DE CASO: PROJETO DE DOCUMENTAÇÃO DE MAINFRAME ... 21
3.1 Histórico do Mainframe na Instituição ... 21
3.2 A necessidade do projeto ... 22
3.3 O Sistema Piloto ... 22
3.4 O Início do projeto ... 23
3.5 PMBoK ... 24
3.6 Gestão do Escopo e Alinhamento com o Projeto ... 25
3.7 A Construção do Projeto ... 27
4. CRÍTICAS, SUGESTÕES AO PROJETO ... 28
4.1 Crítica à gerência de projetos – O impacto do gerente de prjetos ... 28
4.2 Crítica à gerência do tempo – A falta de clareza no tempo do projeto ... 28
4.3 Crítica à gerência de Recursos Humanos – A divisão da equipe ... 29
5. CONSIDERAÇÕES FINAIS ... REFERÊNCIAS BIBLIOGRÁFICAS
31 ... 32
Figura 1: Uso do COBOL em relação as liguagens de programação atuais... 09
Figura 2: Diagrama de Caso de Uso para Sistema de Vendas (UML). ... 13
Figura 3: Diagrama de Sequência para Sistema de Vendas (UML) ... 14
Figura 4: Diagrama de Classe para Sistema de Vendas (UML) ... 15
Figura 5: Diagrama de Atividade para Sistema de Vendas (UML). ... 16
Figura 6: Fases e Disciplinas do Rational Unified Process (RUP)... 17
Figura 7: Áreas de Conhecimento do PMBoK... 21
Figura 8: Exemplo de EAP... 22
LISTA DE QUADROS Quadro 1: A Estrutura do Sistema Financeiro Brasileiro. ... 03
BACEN – Banco Central do Brasil BASA – Banco da Amazônia
BNB – Banco do Nordeste do Brasil
CGPC – Conselho de Gestão da Previdência Complementar CMN – Conselho Monetário Nacional
CNSP – Conselho Nacional de Seguros Privados COBOL – Commom Bussiness Oriented Language CODASYL – Conference on Data Systems Languages CVM – Comissão de Valores Mobiliários
EAP – Estrutura Analítica do Projeto EJB – Enterprise JavaBeans
HSBC – Hong Kong and Shanghai Banking Corporation IRB – Brasil Resseguros
IBM – Internation Bussiness Machines NBS – National Bureau of Standarts
PMBoK – Project Management Body of Knowledge PMI – Project Management Institute
RCA – Radio Corporation of America RUP – Rational Unified Process
SPC – Secretaria de Previdência Complementar SUSEP – Superintendência de Seguros Privados UML – Unified Modeling Language
técnicas para conduzir atividades que satisfaçam os requisitos de um ou mais projetos. Ela inclui: a identificação dos requisitos, o estabelecimento de objetivos claros e alcançáveis, o balanceamento das competências de qualidade, escopo, tempo e custo, além de adaptar as especificações e planos para aproximá-las às necessidades dos stakeholders.
A gerência de projetos pode ser utilizada em quaisquer projetos provindos das mais diversas áreas. A construção civil e a informática fazem bastante uso destas técnicas para a realização das mais diversas obras e sistemas.
1.1 Justificativa
As instituições financeiras vêm enfrentando problemas com relação aos sistemas da plataforma Mainframe devido à falta de documentação e padronização tanto nos processos de desenvolvimento como nos de manutenção desses sistemas. Com a constante melhoria na gerência de projetos, muitas instituições financeiras passaram a adotar práticas de gerência e a incorporar seus sistemas aos novos processos.
Mesmo com a melhoria das tecnologias de software e hardware, grande parte das instituições financeiras ainda utiliza a plataforma Mainframe, pois ela ainda garante grande estabilidade e segurança nas transações bancárias com resultados satisfatórios mesmo se comparados com outras plataformas.
A partir disto, surge a necessidade de remodelagem de processos e criação de padrões que venham a modernizar e melhorar os sistemas criados na plataforma Mainframe para evitar prejuízos à instituição e garantir os processos de manutenção de forma rápida e correta.
Os maiores problemas neste tipo de projeto ocorrem na fase de elaboração do escopo, considerando que se trata de uma fase que requer o conhecimento de diversas pessoas que possam estar desligadas da instituição ou alocadas em outros projetos da instituição.
1.2 Objetivo
O objetivo deste trabalho é a análise do escopo e do gerenciamento de um projeto de documentação e definição de padrões de um sistema na plataforma Mainframe de uma
determinada instituição financeira. É interessante o estudo de caso deste projeto já que ele servirá como base para os demais sistemas Mainframe da instituição em questão.
Serão apresentadas as técnicas de gerência da equipe envolvida no projeto, principais dificuldades e desafios, riscos e artefatos utilizados no projeto.
Este trabalho apresenta um pouco sobre cada tecnologia utilizada no projeto de documentação apresentado no estudo de caso. Pode-se citar a Unified Modeling Language como a linguagem de modelagem dos projetos, o Rational Unified Process como processo de desenvolvimento de software, a Gerência de projetos com PMBoK como referência para metodologia de gerência para a instituição Financeira, o COBOL como linguagem de programação e o Mainframe como equipamento utilizado.
1.3 Estrutura do Trabalho
Este trabalho é composto de 4 capítulos. O capítulo 1 mostra os objetivos e a justificativa do trabalho abordado. No capítulo 2 são abordados os tipos de instituições financeiras e as tecnologias envolvidas no projeto. O capítulo 3 descreve as práticas de gestão do escopo segundo o PMBoK e faz um estudo de caso de implantação de projeto de documentação de sistema de Mainframe em uma instituição financeira bancária de caráter misto, ou seja, um banco de desenvolvimento que possui serviços comerciais. O capítulo 4 traz críticas e sugestões com relação à forma de gerenciamento do projeto e contém as considerações finais deste trabalho. Os artefatos produzidos no projeto estão dispostos nas páginas de anexos.
2. INSTITUIÇÃO E TECNOLOGIA DA INFORMAÇÃO 2.1 Instituições Financeiras no Brasil
O Sistema Financeiro Nacional pode ser definido como o conjunto de instituições e órgãos que regulam, fiscalizam e executam as operações relativas à circulação da moeda e do crédito.
Os órgãos normativos do Sistema Financeiro Nacional são: o Conselho Monetário Nacional (CMN), o Conselho Nacional de Seguros Privados (CNSP) e o Conselho de Gestão da Previdência Complementar (CGPC).
O quadro abaixo demonstra a estrutura do Sistema Financeiro nacional de forma mais detalhada.
Quadro 1: A estrutura do Sistema Financeiro Brasileiro.
Fonte: www.editoraferreira.com.br/publique/media/01SFN.pdf- acessado em 22/11/2007
A finalidade do Conselho Monetário Nacional é formular a política da moeda e do crédito, objetivando o progresso econômico e social do país. O CMN é o órgão máximo do
Sistema Financeiro nacional, com funções deliberativas, cujas normas são de observância obrigatória por todas as instituições do sistema financeiro.
As entidades supervisoras do sistema financeiro do Brasil são: o Banco Central do Brasil (BACEN), a Comissão de Valores Mobiliários (CVM), A Superintendência de Seguros Privados (SUSEP), a Brasil Resseguros (IRB) e a Secretaria de Previdência Complementar (SPC).
O Banco Central do Brasil, entidade autárquica vinculada ao Ministério da Fazenda, funciona como o “banco dos bancos”. Compete-lhe cumprir as funções que lhe são atribuídas pela legislação em vigor e executar as normas expedidas pelo CMV. Suas funções podem ser divididas da seguinte forma:
Funções Executivas – quando apenas implementa as resoluções do CMV;
Funções de controle ou fiscalização – quando direta ou indiretamente controla o cumprimento dos dispositivos regulamentares;
Funções próprias – quando exerce que lhe foram atribuídas pela lei.
As demais instituições funcionam como operadores no Sistema Financeiro Nacional. Consideram-se instituições financeiras, para efeitos da legislação em vigor, as pessoas jurídicas, públicas ou privadas, que tenham como atividade principal ou acessoria à coleta, intermediação ou aplicação de recursos financeiros próprios ou de terceiros, em moeda nacional ou estrangeira, e a custódia de valor de propriedade de terceiros. As instituições financeiras só podem funcionar no Brasil mediante prévia autorização do Banco Central do Brasil ou, quando estrangeiras, por intermédio de decreto do presidente da república.
As instituições financeiras são autorizadas a captar recursos junto ao público sob a forma de depósito à vista, podendo, por isso, criar moeda escritural: os bancos comerciais, as caixas econômicas, as cooperativas de crédito, bancos cooperativos e os bancos múltiplos com carteira comercial.
Os bancos comerciais formam o grupo mais importante de instituições depositárias, tanto em termos de número quanto de tamanho. Desempenham funções semelhantes às instituições de poupança, ou seja, recebem depósitos (passivos) e fazem empréstimos (ativos). Dentro da indústria de bancos comerciais, a estrutura e a composição de ativos e passivos variam substancialmente entre bancos de tamanhos distintos. Tem como objetivo principal proporcionar o suprimento oportuno e adequado dos recursos necessários para financiar, a curto e médio prazo, o comércio, a indústria, as empresas prestadoras de serviços, as pessoas físicas e terceiros em geral. A captação de depósitos à vista,
livremente movimentáveis, é atividade típica do banco comercial. Como exemplo de bancos comerciais, podemos citar: Itaú, HSBC, Unibanco, entre outros.
O governo federal do Brasil controla alguns bancos comerciais e outras instituições financeiras. Instituições financeiras controladas pelo governo possuem um papel importante na indústria brasileira de bancos. Estas instituições detêm uma parcela significativa no total de depósitos e de ativos do sistema bancário e uma presença mais forte em mercados como financiamento imobiliário e empréstimos agrícolas que o setor de bancos privados. Além disso, bancos de desenvolvimento atuam como agências de desenvolvimento regionais.
Um banco de desenvolvimento é aquele que financia normalmente a uma taxa de juros inferior à do mercado e tem como objetivo proporcionar o suprimento oportuno e adequado dos recursos necessários ao financiamento, em médio e longo prazo, de programas e projetos que visem a promover o desenvolvimento econômico e social do respectivo estado ou região onde tenha sede, cabendo-lhe apoiar prioritariamente o setor privado. Dentre os bancos de desenvolvimento brasileiros destacam-se o Banco do Nordeste (BNB) que atua em toda a região nordeste e norte do Espírito Santo e norte de Minas Gerais, o Banco da Amazônia (BASA) que atua em toda a região norte e parte do Maranhão.
Os Bancos de Investimento são Instituições financeiras privadas especializadas em operações de participação societária de caráter temporário, de financiamento da atividade produtiva para suprimento de capital fixo e de giro e de administração de recursos de terceiros.
Os Bancos Múltiplos são Instituições financeiras privadas ou públicas que realizam as operações ativas, passivas e acessórias das diversas instituições financeiras, por intermédio das seguintes carteiras: comercial, de investimento e/ou de desenvolvimento, de crédito imobiliário, de arrendamento mercantil e de crédito, financiamento e investimento. Essas operações estão sujeitas às mesmas normas legais e regulamentares aplicáveis às instituições singulares correspondentes às suas carteiras.
2.2 COBOL
A linguagem de programação mais utilizada nas instituições financeiras e principalmente na plataforma Mainframe é o COBOL. O COBOL (Common Bussiness
Oriented Language) é uma linguagem de programação estruturada desenvolvida em 1959
pela Conference on Data System Languages (CODASYL), também chamada de comitê de Curto Prazo. Este foi um dos três comitês propostos numa reunião no Pentágono em Maio de 1959, organizado por Charles Phillips do Departamento de Defesa dos Estados Unidos.
O Comitê de Curto Prazo (CODASYL) foi formado para recomendar as diretrizes de uma linguagem para negócios. Foi constituído por membros representantes de seis fabricantes de computadores e três órgãos governamentais, a saber: Burroughs Corporation, IBM,
Minneapolis-Honeywell (Honeywell Labs), RCA, Sperry Rand, e Sylvania Electric Products, e
a Força Aérea dos Estados Unidos, o David Taylor Model Basin e a Agência Nacional de Padrões (National Bureau of Standards ou NBS). Este comitê foi presidido por um membro do NBS. Um comitê de Médio Prazo e outro de Longo Prazo foram também propostos na reunião do Pentágono. Entretanto, embora tenha sido formado, o Comitê de Médio Prazo nunca chegou a funcionar; e o Comitê de Longo Prazo nem chegou a ser formado. Por fim, um subcomitê do Comitê de Curto Prazo desenvolveu as especificações da linguagem COBOL. As especificações do COBOL foram finalizadas no final de 1959 e tiveram a aprovação da CODASYL em janeiro de 1960. Por este motivo, a primeira versão do COBOL é chamada de COBOL60. As especificações do COBOL foram inspiradas em grande parte pela linguagem FLOW-MATIC criada por Grace Hopper, e pela linguagem COMTRAN da IBM de autoria de Bob Bemer.
Embora o COBOL tenha sido proposto originalmente como solução para resolver problemas de programação do governo e das forças armadas americanas, programas COBOL continuam em uso na maioria das empresas comerciais em todo o mundo, notadamente nas instituições financeiras e em praticamente todos os sistemas operacionais, incluindo o IBM z/OS, o Microsoft Windows e a família Unix/Linux. A base global de código é imensa e os aplicativos, de tempos em tempos, estão sujeitos a manutenção. O custo de reescrever um aplicativo COBOL, já depurado, em uma nova linguagem não justifica os benefícios que possa eventualmente trazer. No fim dos anos 90 o Gartner Group, uma empresa de pesquisa na área de processamento de dados, estimou que dos 300 bilhões de linhas de código-fonte existentes no mundo, 80% deles, cerca de 240 bilhões de linhas eram escritas em COBOL. Eles também reportaram que mais da metade dos novos aplicativos de missões críticas ainda estavam sendo desenvolvidos usando o COBOL.
Ao se aproximar o fim do século XX, houve uma febre de atividade de programadores COBOL para corrigir os efeitos do bug do milênio, em certos casos em sistemas desenvolvidos por estes mesmos programadores há décadas. Este problema foi mais crítico no código COBOL porque as datas são primordiais em aplicativos comerciais, e a maioria dos aplicativos comerciais foram escritos em COBOL.
Algumas pessoas acreditam que o uso de aritmética decimal codificada em binário fez com que programas desenvolvidos sem a previsão de datas com ano de 4 dígitos ficassem particularmente vulneráveis a falhas com o problema do ano 2000; entretanto é difícil justificar esta opinião. Outros argumentam que a aritmética BCD do COBOL evitou
muitos outros problemas que poderiam ocorrer com o uso ingênuo do ponto flutuante em cálculos financeiros.
O COBOL provou ser durável e adaptável. O padrão atual do COBOL é o COBOL2002. O COBOL2002 suporta agora conveniências modernas como Unicode, geração de XML e convenção de chamadas de/para linguagens como o C, inclusão como linguagem de primeira classe em ambientes de desenvolvimento como o .NET da Microsoft e a capacidade de operar em ambientes fechados como Java (incluindo COBOL em instâncias de EJB) e acesso a qualquer base SQL.
A motivação do desenvolvimento do COBOL era de facilitar a programação tornando a linguagem a mais próxima possível do inglês. Embora esta ideia pareça razoável, na prática a tarefa mais difícil na programação é reduzir uma computação complexa numa sequência de passos simples, não associando estes passos com uma linguagem natural. Os críticos argumentam que a sintaxe prolixa e a estrutura geral do COBOL só servem para aumentar o tamanho do programa e dificultar o desenvolvimento do pensamento preciso necessário para o desenvolvimento de software. O cientista de computação Edsger Dijkstra observou no artigo (de título “How do we tell truths that might hurt?”) em 1975, a seguinte frase: "O uso do COBOL mutila a mente; seu ensino deveria, portanto, ser considerado um crime". Dijkstra estava muito bem impressionado pelas ideias de Michael A. Jackson sobre a "Programação Estruturada" em COBOL (Jackson Structured Programming).
Dentre as desvantagens mais discutidas do COBOL podemos citar: a) Códigos muito longos;
b) Formato rígido, de poucas maneiras de se usar.
c) Não recomendado para alguns tipos específicos de programas e aplicativos. Por outro lado, os defensores do COBOL argumentam que os que o criticam e ironizam a linguagem nunca foram programadores COBOL e geralmente o desconhecem. Na maioria das versões atuais os compiladores não fazem distinção entre maiúsculas e minúsculas, embora o compilador vá transformar em maiúsculas todas as palavras-chave antes de processá-las.
Dentre as vantagens apontas do COBOL, podemos citar: a) Simplicidade de código, Legibilidade;
b) Alta portabilidade; c) Fácil Manutenção; d) Estabilidade;
e) Segurança.
O COBOL possui uma estrutura hierárquica, onde cada elemento desta hierarquia constitui um ou mais elementos subordinados. Os níveis de hierarquia são as divisões (Divisions), as seções (Sections), os parágrafos (Paragraphs) e as sentenças (Sentences
and Statements). Em um programa COBOL existem quatro divisões principais onde cada
divisão disponibiliza uma parte de informação importante para o compilador. As sequências em que estas divisões são especificadas devem seguir a ordem:
Divisão de Identificação (Identification Division) contém informações sobre o programa tanto para o compilador como para o próprio programador.
Divisão de Ambiente (Evironment Division) que contém as especificações da plataforma a qual o programa será rodado.
Divisão de Dados (Data Division) contém as variáveis, itens de grupo e outras datas para processamento do programa.
Divisão de Procedimentos (Procedure Division) que contém o corpo do programa, suas funções e todo o desenvolvimento do algoritmo do programa.
Alguns compiladores de COBOL requerem que todas as quatro divisões estejam presentes, enquanto outros só necessitam de algumas delas.
O COBOL ainda é bastante utilizado na plataforma Mainframe, que por sua vez é utilizado por várias instituições financeiras. Apesar de ser considerado uma linguagem ultrapassada, o COBOL ainda é muito utilizado e vem sendo adaptado aos novos processos e práticas de desenvolvimento de software.
A figura 1 mostra o declínio do uso do COBOL por parte da plataforma baixa (Windows). Mesmo depois de cinquenta anos, o COBOL ainda ocupa espaço no meio das linguagens de programação atuais, ficando com 0.7% de abrangência, décimo sétimo lugar em uso no mundo e praticamente dominante na plataforma alta.
Figura 1: Uso do COBOL em relação às linguagens de programação atuais. Fonte: http://www.tiobe.com/tiobe_index/COBOL.html - acessado em 22/11/2007
2.3 Mainframe
Um mainframe é um computador de grande porte, dedicado normalmente ao processamento de um volume grande de informações. Os mainframes são capazes de oferecer serviços de processamento a milhares de usuários através de milhares de terminais conectados diretamente ou através de uma rede. O termo mainframe se refere ao gabinete principal que alojava a unidade central de processamento nos primeiros computadores.
Embora os Mainframes venham perdendo espaço para os servidores de arquitetura PC e servidores Unix, de custo bem menor, ainda são muito usados em ambientes comerciais como instituições financeiras, empresas de aviação e até mesmo por outros tipos de instituições como universidades, entre outros.
São computadores que geralmente ocupam um grande espaço e necessitam de um ambiente especial para seu funcionamento, que inclui instalações de refrigeração. Os
mainframes são capazes de realizar operações em grande velocidade e sobre um volume
muito grande de dados.
Os mainframes surgiram em 1946 e foram sendo aperfeiçoados. Em 7 de abril de 1964, a IBM apresentou o System/360, mainframe que, na época, foi o maior projeto de uma
empresa. Desde então, outras empresas como a HP e a Burroughs (atual Unisys) lançaram seus modelos de mainframe.
Contemporâneos aos /360 da IBM foram os Burrough B-200, B-300 e B-500 (de pequeno porte) e os B-5500 (de grande porte).
Posteriormente a IBM lançou a série /370, e a Burroughs por sua vez lançou as máquinas de terceira geração: 3500 e 6500, sucedidas pela série 700: 3700 e B-6700.
No fim da década de 70, ao mesmo tempo em que surgiam os sistemas destinados a grandes corporações, começaram a reduzir o tamanho de uma série das máquinas para chegar a clientes menores. A IBM lançou o /3 e a Burroughs a série B-1700 e posteriormente o B-700, máquinas de quarta geração, cujo software básico era escrito em MIL (Micro Implemented Language) e SDL (Software Development Language). Foram as primeiras máquinas Burroughs microprogramáveis, o que lhes dava uma flexibilidade ímpar. Estas máquinas marcaram o início do uso de circuitos integrados com tecnologia TTL com integração em média escala (MSI).
Atualmente a IBM produz quatro versões de mainframes, denominados System Z
series, que modernizados, suportam diversos sistemas operacionais: z/OS®, z/OS.e,
z/VM®, z/VSE™, VSE/ESA™, TPF, z/TPF e Linux on System z™.
A distinção entre supercomputadores e mainframes não é clara e direta, mas geralmente falando, os supercomputadores são utilizados na solução de problemas em que o tempo de cálculo é um limite, enquanto os mainframes são utilizados em tarefas que exigem alta disponibilidade e envolvem alta taxa de transferência de dados (internos ou externos ao sistema). Como consequência:
Os supercomputadores são mais complexos do ponto de vista do programador, devido ao alto grau de paralelismo na execução das instruções e pelo fato de que, ao contrário dos mainframes, não existe uma camada de abstração que esconde estas questões;
Os supercomputadores são otimizados para realização de tarefas complicadas utilizando principalmente a memória, enquanto os mainframes são otimizados para realizar tarefas que acessam grandes quantidades de informação oriunda de bases de dados;
Normalmente os supercomputadores são utilizados em aplicações científicas e militares, enquanto os mainframes são voltados a aplicações civis, sejam governamentais ou empresariais. A análise de modelos de clima, análise estrutural de proteínas e processamento de filmes digitais são tarefas bastante apropriadas para os
supercomputadores. O processamento de cartões de crédito, gerenciamento de contas bancárias, negociações mercantis e processamento de seguro social são tarefas normalmente realizadas por mainframes. (Uma exceção: certas aplicações militares exigem um nível de segurança muito alto, que é uma forte característica dos mainframes);
As tarefas executadas pelos supercomputadores toleram interrupções (por exemplo, cálculos de modelos de previsão de aquecimento global ou pesquisa acadêmica). Os
mainframes executam tarefas que exigem alta disponibilidade, podendo executar serviços
continuamente por anos (por exemplo, sistemas de emissão de passagens aéreas ou processamento de cartões de crédito);
Os supercomputadores são construídos para atender uma finalidade específica. Os
mainframes são construídos para realizar uma grande variedade de tarefas de execução
diária;
Os mainframes suportam totalmente o software antigo (no caso da IBM, inclusive aplicações escritas na década de 60) convivendo com novas versões. No caso dos supercomputadores, a tendência é ignorar a compatibilidade retroativa de software no projeto de novos sistemas;
Os mainframes possuem um grande número de processadores que auxiliam os processadores centrais. Eles são utilizados em funções de criptografia, gerenciamento de
Input e Output, monitoração do ambiente, manipulação de memória, e etc. Devido a esta
característica o número de processadores dos mainframes é muito maior do que se esperaria. Os projetos de supercomputadores não incluem este grande número de processadores de uso específico já que eles não adicionam poder de processamento de cálculo.
2.4 Unified Modeling Language – UML
A UML foi concebida para modelar sistemas de vários tipos, mas ela não é apenas uma linguagem visual, já que seus modelos podem ser utilizados para gerar código em diferentes linguagens de programação e tabelas de bancos de dados relacionais.
A documentação gerada pela UML aborda a arquitetura do sistema e todos os seus detalhes como os requisitos funcionais e os de teste. Esta documentação soluciona muitos problemas relacionados ao desenvolvimento do sistema como, por exemplo:
a) A comunicação de modelos conceituais do sistema com a equipe de desenvolvimento.
b) Previne a perda do conhecimento gerado pelo desenvolvimento do sistema no caso da saída de membro da equipe.
c) Pode explicar os elementos de um sistema de maneira melhor do que a linguagem escrita e a falada.
A UML é composta por objetos, relacionamentos e diagramas.
Os objetos da UML ou “coisas” são os elementos que formam os diagramas e podem ser pertinentes à estrutura, comportamento, agrupamentos e anotações. Os objetos da UML podem constituir as partes conceituais ou físicas do sistema como classes, interfaces, casos de uso e componentes. Os objetos que se referem ao comportamento do sistema no tempo e espaço correspondem à parte dinâmica da UML. Há dois tipos de comportamento: as interações, compostas por mensagens trocadas por objetos do sistema e o estados que representam o ciclo de vida do objeto no sistema.
Os relacionamentos entre objetos que podem ser classificados como dependência, associação e generalização. A dependência é um relacionamento onde a mudança em um dos objetos reflete na mudança da semântica do outro. A associação é um relacionamento estrutural que pode representar uma agregação entre o todo e suas partes. A generalização é uma relação que permite representar a abstração de classe, ou herança.
Os diagramas são agrupamentos de objetos da UML e seus relacionamentos. Eles são uma apresentação gráfica de um conjunto de elementos relacionados entre si e permite construir diferentes visões de um sistema. Não há problemas quanto a repetição de elementos em diagramas distintos, já que cada diagrama representa o sistema em diferentes perspectivas.
A UML é composta pelos seguintes diagramas:
Diagrama de Casos de uso: mostra um conjunto de casos de uso, seus atores e as relações destes casos de uso com estes atores. Os atores não são somente usuários do sistema, eles podem ser outros sistemas que interagem com o sistema em questão. A figura 2 mostra um exemplo de diagrama de casos uso para um sistema de vendas. Este exemplo de sistema é o mais comumente apresentado em cursos de UML.
Figura 2: Diagrama de caso de uso para sistema de vendas (UML)
Fonte: www.conceptdraw.com/en/sampletour/uml_erd/ - acessado em 22/11/2007
Diagrama de Sequência: mostra as mensagens trocadas entre os objetos durante o tempo. A figura 3 nos mostra um exemplo de diagrama de sequência no sistema de pedidos, onde se pode ver a sequência de comunicação entre os objetos do sistema.
Figura 3: Diagrama de seqüência para sistema de vendas (UML)
Fonte: www.conceptdraw.com/en/sampletour/uml_erd/ - acessado em 22/11/2007
Diagrama de Interação: modela a interação entre os objetos incluindo tanto as mensagens que eles trocam como seus relacionamentos.
Diagrama de classe: representa as classes, interfaces e seus relacionamentos. Este diagrama é mais comum em projetos de software que envolva uma linguagem de programação orientada a objetos. A figura 4 representa um diagrama de classe para o sistema de vendas. Estão presentes as classes com seus atributos e funções e os relacionamentos. Geralmente o diagrama de classes é mais utilizado em sistemas orientados a objetos.
Figura 4: Diagrama de classe para sistema de vendas (UML)
Fonte: www.conceptdraw.com/en/sampletour/uml_erd/ - acessado em 22/11/2007
Diagrama de Estados: mostra uma máquina de estados (semelhante a um autômato) com seus estados, transições, eventos e atividades.
Diagrama de Objetos: mostra os objetos do sistema e seus relacionamentos. Representa o funcionamento do Diagrama de classes em um determinado momento.
Diagrama de componentes: mostra a organização e as dependências entre os componentes, destacando a implementação estática do sistema. Este diagrama também se relaciona com o Diagrama de Classes já que um conjunto de classes e interfaces forma um componente.
Diagrama de Atividades: mostra o fluxo das atividades de uma determinada rotina do sistema. Ele também modela o comportamento dinâmico do sistema. A figura 5 representa o
diagrama de atividades da função de busca (check) de um produto (no caso, um scanner) no estoque do sistema de vendas.
Figura 5: Diagrama de atividades para sistema de vendas (UML)
Fonte: msdn2.microsoft.com/en-us/library/ms838235.aspx - acessado em 22/11/2007
Diagrama de Deployment: representa a configuração dos componentes e nos associados durante a execução do sistema.
Estes recursos permitem a documentação de requisitos, arquitetura, design, códigos fonte, planos de projeto, testes, protótipos e versões do sistema.
2.5 Rational Unified Process – RUP
O Rational Unified Process (RUP) fornece uma abordagem disciplinada para assumir tarefas dentro de uma organização de desenvolvimento e seu objetivo é assegurar a produção de software de alta qualidade que satisfaça as necessidades de seus usuários finais dentro de prazo e orçamento previsíveis.
O RUP captura muito das melhores práticas no desenvolvimento de software. Dentre essas práticas, podemos citar como principais:
b) Gerenciar requisitos;
c) Usar arquiteturas baseadas em componentes; d) Modelar visualmente o software;
e) Verificar continuamente a qualidade do software; f) Controlar mudanças do software.
O processo do RUP é baseado em duas dimensões ou estruturas: um eixo horizontal e um eixo vertical. O eixo horizontal representa o tempo e mostra os aspectos de como o ciclo de vida do software se desdobra. Nele podemos ver as transações ou iterações de cada fase. O eixo vertical mostra os fluxos essenciais do processo, que agrupa logicamente por natureza. Estes fluxos são divididos em fases ou disciplinas.
A UML fornece a forma para expressar modelos visuais de sistemas, enquanto o RUP mostra a melhor maneira de desenvolver os sistemas utilizando a UML como vocabulário. O RUP descreve quais modelos ou diagramas o usuário precisa, o porquê da necessidade e como construí-los durante um projeto de desenvolvimento de software.
A figura 6 mostra as disciplinas do RUP (eixo vertical) e suas fases (eixo horizontal) de acordo com o ciclo de vida do projeto. O gráfico ilustra o nível de esforço que cada disciplina realiza de acordo com cada fase num período de tempo.
Figura 6: Fases e Disciplinas do Ration Unified Process (RUP)
Fonte: http://dn.codegear.com/article/33319 - acessado em 02/10/2007
A abordagem iterativa sugerida pelo RUP é superior a abordagem linear ou em cascata, já que essa abordagem deixa levar em conta as mudanças dos requisitos, que geralmente causam atrasos e estouros de orçamento se mal administrados. A Integração progressiva dos elementos facilita a descoberta de erros e divide o esforço maciço do final de projetos em cascata com as outras fases de cada iteração. Essa abordagem também facilita a reutilização de componentes, resultado de uma arquitetura robusta proporcionada pela iteratividade do processo.
O gerenciamento dos requisitos melhora o controle de projetos complexos, já que existe uma boa compreensão dos requisitos através dos artefatos, documentos gerados e dos diagramas da UML. A qualidade do software é aperfeiçoada atingindo a satisfação do cliente e os custos e demoras do projeto podem ser reduzidos, já que erros identificados podem ser prevenidos mais cedo.
O uso de componentes pode trazer vários benefícios como a redução do esforço no desenvolvimento, o teste gradual de cada componente e a formação de uma arquitetura robusta que pode ser articulada.
A modelagem visual do software evita equívocos com relação ao comportamento e construção do sistema. Ela também proporciona uma identificação mais rápida de inconsistências e expõe arquiteturas não modulares e inflexíveis.
A avaliação de status do projeto é feita de forma objetiva e não subjetiva, porque são avaliados os resultados dos testes não documentos em papel. Essa avaliação objetiva expõe inconsistência de requisitos, construções e implementações. Nessa verificação contínua da qualidade do software, os testes são concentrados em áreas de alto risco, aumentando a qualidade e efetividade dessas áreas.
Controlar as mudanças do software oferece várias soluções para o desenvolvimento do mesmo:
a) O fluxo de mudanças de requisitos é definido e repetível. b) Solicitações de mudanças facilitam comunicações claras.
c) Mudanças podem ser mantidas em um sistema robusto e personalizável. d) A propagação da mudança é avaliável e controlada.
e) As estatísticas de índice de mudança fornecem boas medidas para avaliar objetivamente o status do projeto.
O Rational Unified Process traz essas melhores práticas juntas de forma satisfatória para uma ampla faixa de projetos e organizações.
2.6 Sobre RUP E UML
Em grandes empresa e instituições financeiras as ferramentas mais populares para projeto de desenvolvimento de software são a UML (Unified Modeling Language) e o RUP (Rational Unified Process). A UML foi originalmente criada para modelar sistemas baseados em software e tem sido utilizado para vários domínios:
a) Sistemas Corporativos de Informações; b) Sistemas Bancários e Financeiros; c) Telecomunicações;
d) Sistemas de Defesa e Aeroespaciais; e) Sistemas Eletrônicos Médicos;
f) Serviços Distribuídos baseados na web; g) Dentre outros.
Apesar de ter sido concebida para especificação de sistemas de software, atualmente a UML também é utilizada para modelar outros tipos de sistemas, como
workflow, estrutura e comportamento de dispositivos eletrônicos e mecânicos, design de hardware e processos de negócio.
A gerência de projetos de desenvolvimento nos diversos tipos de sistemas citados é administrada através do RUP. Este processo define as etapas do projeto e quem executará cada atividade. A premissa do RUP é que o software é baseado em componentes, ou seja, o software é composto por partes interconectadas via interfaces bem definida. A ferramenta utilizada pelo RUP para especificar estes componentes é a UML. As características fundamentais que definem o RUP são:
a) Dirigido por Casos de Uso; b) Centrado na arquitetura; c) Iterativo e Incremental.
Na UML, os casos de uso documentam as interações entre usuário e sistema. Os casos de uso compreendem ações entre duas ou mais partes que resultam em um valor, que é a funcionalidade do sistema. Logo, todo o conjunto de casos de uso descreve todas as funcionalidades do sistema e forma o Diagrama de Casos de Uso. Este diagrama é utilizado como base para a definição de outros diagramas da UML que definirão a implementação de cada um ou de um conjunto de casos de uso. Estes casos de uso definidos não fazem parte apenas da fase inicial do projeto do sistema. Os testes do sistema
também são configurados com base no digrama de casos de uso fazendo assim que estes diagramas iniciem e encerrem o processo de desenvolvimento.
A arquitetura de software apresenta aspectos estáticos e dinâmicos de um sistema como componentes, subsistemas e processamento corrente. A arquitetura mostra como estes aspectos serão implementados.
3. ESTUDO DE CASO: PROJETO DE DOCUMENTAÇÃO DE MAINFRAME 3.1 Histórico do Mainframe na Instituição
A instituição financeira deste estudo de caso cogitou a mudança da tecnologia
Mainframe para outro tipo de tecnologia. Foi feito um estudo sobre as propostas de diversas
outras empresas para substituição do Mainframe, assim como todo o processo de transição e funcionamento das novas tecnologias candidatas.
Esta ideia poderia trazer alguns benefícios a instituição como: a) Alta performance dos sistemas.
b) Alinhamento dos sistemas com novas tecnologias e linguagens de programação. c) Utilização dos novos bancos de dados no lugar do antigo VSAM.
d) Possibilidade de atualização de funcionários. e) Melhoria no tempo de resposta para erros.
Apesar de estas características parecerem muito boas, o processo de migração do
Mainframe apresenta alguns pontos cruciais que acabaram fazendo com que a gerência
abandonasse a ideia.
A migração da linguagem de programação COBOL para uma linguagem mais nova se mostrou ineficiente em diversas empresas. Isto acontece porque a maioria das novas linguagens de programação tem estrutura diferente da estrutura do COBOL.
A adaptação de linguagens de programação que diferem na estrutura traz riscos com relação ao funcionamento do programa e pode exigir a reescrita de todo o código.
A grande quantidade de código a ser migrado, reprogramado e testado novamente seria outro motivo para o abandono da ideia, já que seria um esforço muito grande para a instituição e os resultados não seriam tão previsíveis devido a grande quantidade de riscos.
O fator crucial para o engavetamento do projeto seria a possível falta de estabilidade do sistema migrado. O Mainframe oferece a garantia de que o sistema “não caia”, ou seja, não fique offline num período estimado de noventa anos. Em todo o uso do Mainframe na instituição, em torno de trinta anos nunca aconteceu de os sistemas ficarem offline, apenas parando em épocas de manutenção programada. O Mainframe da instituição é monitorado vinte e quatro horas por dia pela IBM e caso alguma peça tenha problemas, imediatamente é mandado um técnico para a instituição antes que o problema se reflita nos sistemas.
A nova plataforma não garantia a mesma estabilidade que o Mainframe e o resultado da migração seria imprevisível com relação à estabilidade. A instituição pagaria multa para o
Banco Central caso determinados sistemas parassem, e o valor estimado de certos sistemas é de vinte e dois mil reais por minuto offline.
Foram apontados outros problemas como: a resistência de funcionários antigos com as novas tecnologias, gastos com treinamento, alta rotatividade dos terceirizados da instituição, e o exemplo de outras instituições que optaram por não fazer a migração.
Com a análise destes pontos negativos, a instituição optou por não fazer esta migração. Frente a esses fatos, decidiu-se pela adaptação da tecnologia de Mainframe e COBOL aos novos processos de desenvolvimento de software e gerência de projetos. Foi iniciado o projeto de Documentação e Criação dos padrões de Mainframe.
3.2 A Necessidade do Projeto
O projeto se fez necessário devido a inviabilidade de substituição das tecnologias de
Mainframe e COBOL e pela urgência de adaptação dos sistemas e processos de
desenvolvimento e manutenção do Mainframe ao RUP, utilizando o PMBoK para gerência de projetos.
Seria utilizado como piloto do projeto um sistema crítico da instituição. Este sistema seria responsável pela entrada de dados de agências e órgãos da instituição financeira em seus sistemas de Contas Correntes e Contabilidade. Após a Finalização do Projeto, ele seria replicado aos demais sistemas da plataforma Mainframe da Instituição.
3.3 O Sistema Piloto
O sistema piloto para este projeto deveria ser crítico para a instituição, mas não muito extenso para que não demandasse muito tempo ou uma equipe muito grande. O sistema escolhido é responsável pelo envio de Eventos Contábeis ao sistema de Contas Correntes e para o sistema de Contabilidade. Este sistema é chamado de SEDE.
A principal função do sistema SEDE é criticar, relatar erros e enviar os Eventos Contábeis devidamente formatados nos padrões da Contabilidade e do sistema de Contas Correntes.
O sistema SEDE foi concebido para facilitar a manutenção de todos os outros sistemas da instituição que trabalham com Eventos contábeis. Antes do sistema SEDE, a manutenção era complicada, pois a alteração de um único sistema poderia demandar novas alterações em todos os outros sistemas que se comunicavam com a Contabilidade e o
sistema de Contas Correntes. O sistema SEDE pode ser dividido em duas componentes: a parte Batch e a parte On-line.
A parte Batch é responsável por todo o disparo automático de programas do sistema que independem de usuários. Esses programas são responsáveis por cálculos, críticas e entregas de Eventos Contábeis aos outros sistemas da Instituição.
A parte On-line caracteriza-se pela interação com o usuário que a utiliza para consultas, manutenções e disparo de relatórios de acordo com algum filtro disponível.
3.4 O Início do Projeto
O projeto teve início com a apresentação do termo de abertura e o documento de visão. O documento de visão traz informações sobre os casos de uso, equipe e detalhes técnicos do projeto. A equipe teve quatro membros, um gerente de projeto e um gestor. O gestor seria a pessoa a qual os membros deveriam mostrar as entregas e o andamento do projeto junto ao gerente de projetos. Um dos membros da equipe trabalharia como um orientador avaliando os padrões criados e dando opiniões sobre mudanças que deveriam ser tomadas. Em uma primeira reunião, foi decidido que a equipe iniciaria o trabalho seguindo os padrões dos sistemas da plataforma baixa (microcomputadores convencionais), fazendo as devidas adaptações.
Esses passos seriam: a definição, a criação e a escrita dos documentos de definição dos Casos de Uso. Cada diagrama de Casos de Uso descreveria as duas partes do sistema piloto do projeto: a parte chama de Batch e a parte chama de On-line.
Os diagramas de casos de uso foram elaborados em quinze dias pelo analista sênior e pelo analista júnior. O analista sênior é o atual responsável pelo sistema e fornecia toda informação, códigos fonte e detalhes sobre o sistema. O analista Júnior redigiria os diagramas e documentos utilizando as informações para estudar o sistema e o processo de elaboração da documentação para a nova plataforma.
A elaboração do documento de especificação dos casos de uso foi a primeira dificuldade encontrada pela equipe. Outros analistas forneceram ajuda, mostrando como a especificação era confeccionada para a plataforma baixa. O documento elaborado na plataforma baixa possuía uma linguagem muito técnica já que servia de canal de comunicação entre o analista de sistemas e o programador. A equipe do projeto terminou cinco documentos, cada um deles referenciando um caso de uso, num período total de um mês. Dois dos casos de uso eram críticos para o sistema e seus respectivos documentos continham vinte páginas cada e os outros possuíam em torno de cinco páginas.
Com todos os passos iniciais finalizados, a equipe participou de uma reunião para discutir o projeto e apresentar os resultados. Até então, o gerente de projetos não tinha participado em momento algum do processo, ficando a cargo da equipe a tomada de decisões. Na reunião, foram sugeridas mudanças nos diagramas e os documentos de especificação foram criticados. A queixa maior para os documentos foi de que eles eram altamente técnicos a ponto de que uma pessoa que não fosse da área de mainframe tivesse dificuldade para entendê-los. Os gestores presentes pediram apoio ao gerente de projetos e resolveram que outro caminho deveria ser tomado.
A nova decisão foi de que o processo deveria ser reiniciado, mantendo apenas os diagramas de casos de uso. O novo início contaria com a presença maior do gerente de projetos e o RUP seria seguido de maneira reversa no que diz respeito aos documentos.
3.5 PMBoK
Durante o início do projeto, o analista júnior decidiu utilizar o PMBoK como guia para uma metodologia de gerência para o projeto. O guia PMBoK (Project Management Body of
Knowledge) contém um conjunto de conhecimentos e práticas da área de gerência de
projetos levantados pelo Project Management Institute (PMI).
O PMBoK é dividido em nove áreas de conhecimento. VARGAS (2003) descreve os 9 áreas de conhecimento:
a) Gerenciamento de Integração: Tem como objetivo assegurar que todos os elementos do projeto sejam adequadamente coordenados.
b) Gerenciamento de Escopo: Tem como objetivo assegurar que no projeto esteja incluído todo o trabalho requerido, e somente o trabalho requerido, para concluí-lo de maneira bem sucedida.
c) Gerenciamento de Tempo: Tem como objetivo assegurar a conclusão do projeto no prazo previsto.
d) Gerenciamento de Custo: Tem como objetivo assegurar que um projeto seja concluído de acordo com seu orçamento previsto.
e) Gerenciamento dos Recursos Humanos: Tem como objetivo fazer uso mais efetivo do pessoal envolvido no projeto.
f) Gerenciamento das Aquisições: Tem como objetivo adquirir bens e serviços de fora da organização promotora. Também conhecido como gerenciamento de suprimentos.
g) Gerenciamento de Risco: Tem como objetivo identificar, analisar e dar respostas ao risco do projeto.
h) Gerenciamento da Qualidade: Tem como objetivo assegurar que os produtos ou serviços do projeto estarão em conformidade com o solicitado pelo cliente ou contratante.
i) Gerenciamento das Comunicações: Tem como objetivo assegurar que as informações do projeto sejam adequadamente obtidas e disseminadas.
A figura 7 nos mostra uma representação de todas as áreas de conhecimento do PMBoK.
Figura 7: Áreas de Conhecimento do PMBoK
Fonte: http://www.e-uptech.com.br/uptech/HTML/servicos.htm# - acessado em 02/10/2007
3.6 Gestão do Escopo e Alinhamento com o Projeto
O gerenciamento do escopo inclui os processos requeridos para assegurar que todo o trabalho necessário esteja incluso no projeto para que este seja concluído com sucesso. Tudo que for incluso no escopo deve ser definido e assumido controle, além de tudo que não deve ser adicionado ao projeto.
Os processos de gerenciamento do escopo são:
a) Planejamento do Escopo: a criação do plano de gerenciamento do escopo documenta como o escopo e a Estrutura Analítica do Projeto (EAP) devem ser definidos, verificados e controlados.
c) Criação da Estrutura Analítica do Projeto (EAP): dividir as entregas e o projeto em componentes menores e mais fáceis de gerenciar.
d) Verificação do Escopo: formalização do aceite das entregas do projeto. e) Controle do Escopo: controlar as mudanças do escopo do projeto.
A primeira fase do Projeto de Documentação e Padrões de Mainframe, descrito no próximo capítulo, foi uma oportunidade para uso de algumas técnicas do PMBoK para garantir que os membros da equipe construíssem os documentos de forma e de maneira corretas. A construção da EAP foi uma das técnicas utilizadas juntamente com o controle e a verificação do escopo.
Para a verificação do escopo, a equipe fazia as entregas em partes menores e uma pessoa fora do projeto fazia o aceite das entregas verificado se os documentos estavam construídos da maneira correta.
A figura abaixo mostra um exemplo de EAP de construção de um sistema.
Figura 8: Exemplo de EAP
3.7 A Construção do Projeto
A nova construção do projeto contaria com novos documentos além dos diagramas de casos de uso. Seriam os novos documentos: a matriz de rastreamento, os diagramas de atividades e o arquivo de modelo de dados.
A matriz de rastreamento é o documento que mostra todas as dependências entre programas e arquivos do sistema SEDE. O foco da matriz de rastreamento são os chamados arquivos VSAM. Os arquivos VSAM representam o conceito de tabelas na plataforma alta (Mainframe) e são permanentes no sistema. Através destes arquivos, o sistema emite relatórios, consultas e guarda as informações.
Os diagramas de atividades mostram os passos ou atividades realizadas por cada tipo de programa que compõe o sistema. Os passos variam desde a abertura de arquivos temporários, passando pelo processo de escrita de arquivos VSAM, até a finalização de um determinado programa.
O modelo de dados é o principal documento desta nova fase do projeto. O modelo descreve cada campo dos arquivos VSAM, o modo de preenchimento e valores possíveis de cada campo e observações e comportamentos específicos de cada item descrito. O modelo descreve cerca de vinte arquivos VSAM contendo em média quarenta e cinco campos.
Com a entrega dos documentos, uma apresentação aos ambientes da instituição ligados ao Mainframe foi marcada para debate do novo padrão de documentação desenvolvido. Com as informações a serem coletadas da apresentação, será feito o refinamento dos padrões para que melhorem as condições de trabalho de quem usará os padrões no cotidiano.
4. CRÍTICAS E SUGESTÕES AO PROJETO
4.1 Crítica à Gerência de Projetos - O Impacto do Gerente de Projetos
Na fase inicial do projeto, um dos grandes impactos foi a ausência do gerente de projetos. Isto ocorreu devido ao fato de a instituição financeira não ter formalizado o cargo de gerente de projeto, porque ainda estava em processo de aprovação por parte da diretoria. O gestor do ambiente teve de conduzir o projeto como gerente, mas não possuía o tempo necessário, já que tinha outras equipes para gerenciar ao mesmo tempo.
A equipe do projeto acabou tendo que tomar várias decisões por conta própria e decidir a formulação dos padrões. Essa atitude gerou uma alteração no escopo, pois que alguns membros da equipe perderam o foco das atividades. O resultado disso foi o descarte dos documentos de especificação dos casos de uso, os quais demandaram bastante esforço e tempo da equipe.
Uma semana antes da reunião para avaliação das especificações, o cargo de gerente de projetos havia sido institucionalizado, e um gerente nomeado para acompanhar a equipe. Ele pôde acompanhar a reunião e sugerir as mudanças necessárias para colocar a equipe de volta no caminho certo.
A presença do gerente de projetos não resolveu totalmente o problema, tendo em vista que este foi nomeado para gerenciar várias equipes, o que criava uma disputa por seu tempo disponível.
Uma sugestão para este problema seria a nomeação de uma quantidade maior de gerentes de projeto ou uma diminuição da quantidade de projetos supervisionada pelo mesmo. Infelizmente isto pode não ocorrer, já que, por se tratar de uma instituição financeira pública, a abertura de novos cargos e contratação de funcionários depende da autorização do governo e de processos seletivos.
4.2 Crítica à Gerência do Tempo – A Falta de Clareza no Tempo do Projeto
Apesar de ser um projeto interno à instituição, o tempo do projeto segue um fator determinante: a aposentadoria do administrador do sistema, que também é o analista sênior da equipe. O projeto tinha nove meses de duração, só que existem outros fatores que afetam esta vasta quantidade de tempo: a disponibilidade do analista sênior, o fato de que o analista júnior deve aprender o máximo possível sobre todo o sistema para que possa substituir (em parte) o analista sênior, e a curva de aprendizado do sistema e dos processos da instituição financeira.
Os gestores do ambiente de tecnologia decidiram que noventa por cento dos esforços do analista júnior deveriam ser depositados na construção dos documentos pedidos. O grande problema desta decisão é que apenas o conteúdo teórico não suprirá as necessidades futuras após o projeto e traz possíveis ambiguidades e dúvidas com relação a documentação. A gestão do ambiente tomou essa decisão já que a ideia deste projeto era antiga, mas nunca consegui pô-la em execução, pois os analistas responsáveis acabavam se aprofundando nas questões práticas do sistema SEDE, deixando o projeto de documentação de lado.
Uma sugestão para essa questão seria uma nova divisão entre o tempo da teoria e o da prática. Neste caso, documentação teria a maior parte do dia disponível (em torno de sessenta a setenta por cento do tempo hábil), e o resto do tempo seria dedicado às atividades de administração do sistema, onde predominariam as atividades simples e de pequeno porte para o analista júnior. O gerente de projetos poderia supervisionar estas atividades e demandar as quantidades necessárias de documentos a serem produzidos num período de tempo para que a documentação não fosse abandonada.
4.3 Crítica à Gerência de Recursos Humanos – A Divisão da Equipe
Outro problema que ocorreu no projeto foi a dissolução da equipe inicial. Restaram ao projeto apenas o gerente, o analista sênior e o analista júnior. Os outros dois analistas foram alocados em outros projetos, e agora teriam participação apenas para opinar nos novos padrões a serem desenvolvidos nas reuniões agendadas. A Instituição tem capacidades limitadas quanto à contratação de novos funcionários. Isso porque suas demandas aumentam gradativamente, mas o corpo de funcionários não pode aumentar até um determinado limite exigido por lei.
A saída de membros da equipe é comum em projetos internos, pois os projetos externos têm maior prioridade, podendo até mesmo parar algum projeto concorrente. Isso sempre foi um dos grandes motivos da descontinuidade de projetos importantes como o de documentação e padronização. Mesmo com a saída de dois membros, o resto da equipe seria mantido (apesar de ter somente dois analistas), pois o projeto já foi parado inúmeras vezes e desta vez existe o fator da aposentadoria do analista sênior, o que deixaria o sistema sem qualquer documento caso o projeto não fosse executado.
Uma sugestão para este problema seria a priorização de alguns dos projetos internos indispensáveis. Além disso, os membros e o gerente de projetos deveriam ser alertados sobre a possibilidade de saída de alguma pessoa da equipe com maior antecedência, para
que a alocação de atividades prioritárias fosse feita focando os analistas que não deixariam o projeto antes de seu término.
5. CONSIDERAÇÕES FINAIS
Com a entrega dos últimos documentos aos gestores, o projeto continuará expandindo-se para outros sistemas, onde será submetido à análise pelos administradores e desenvolvedores destes demais sistemas da instituição financeira.
Os objetivos do projeto foram atingidos com o esforço e dedicação da equipe, que se empenhou em manter um controle sobre o escopo do projeto para que seu resultado fosse o mesmo esperado pelos gestores da instituição.
A experiência com as técnicas do PMBoK foi extremamente gratificante, pois ela manteve o projeto coeso e fiel ao seu escopo original. Apesar dos documentos iniciais não terem sido aceitos como documentação oficial, eles serão utilizados por toda a duração do projeto como referência a todos os envolvidos no sistema SEDE, principalmente seus desenvolvedores.
Uma sugestão para trabalhos futuros seria a expansão deste projeto a todos os sistemas da plataforma Mainframe da instituição. Estes sistemas carecem de documentação e seus administradores se retiram do quadro de funcionários com o passar dos anos. Dentre outros trabalhos futuros, podemos citar a capacitação de funcionários para o Mainframe através da implantação destes projetos nos demais sistemas, já que a instituição possui uma demanda para analistas e desenvolvedores para Mainframe.
A prática deste tipo de projeto é aconselhada pelo Banco Central, pois isto facilita sua fiscalização, melhora a imagem da instituição e traz melhorias na administração, manutenção e desenvolvimento dos sistemas em Mainframe.
REFERÊNCIAS BIBLIOGRÁFICAS
BEZERRA, Eduardo. Princípios de Análise e Projetos de Sistemas com UML. 8ª Ed. Rio de Janeiro: Campus, 2003
JORDÃO, Claudius; GOMES, Edgar A.; BORGES, Elizabeth; Mello, Jonatan; GRIMALDI, Marcelo; MENDES, Marcelo; POSSI, Marcus; FILHO, Mauro R.; Marquet, Sueli.
Gerenciamento de Projetos Guia do Profissional: Volume 1: Abordagem Geral e Definição do escopo. 1ª Ed. Rio de Janeiro: Brasport, 2006.
KRUCHTEN, Philippe. Introdução ao RUP Rational Unified Process. 1ª Ed. Rio de Janeiro: Editora Ciência Moderna, 2003.
MARTINS, J.C.C. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML. 3ª Ed. Rio de Janeiro: Brasport, 2006.
PMI. PMBoK – Guide to the Project Body of Knowledge. 3ª Ed Pennsylvania USA: PMI, 2004.
SAADE, Joel. COBOL Sem Mistérios. 1ª Ed São Paulo: Novatec, 1997
SAMMET, J.E., "The Early History of COBOL." In History of Programming Languages, by
Wexelblat, 1ª ed. New York: ACM Monograph Series, 1981.
SAUNDERS, Anthony; SANVICENTE, Antônio Zoratto (Trad.). Administração de instituições financeiras . 1ª Ed. São Paulo: Atlas, 2000.
ANEXO I – Documento de Visão
Visão
Data Versão Descrição Autor
31/07/2007 1.0 Abertura do Documento. Sávio Almeida Silveira
07/08/2007 1.1 Revisão do Documento
Sávio Almeida Silveira Yara Maria Almeida
Freire
Introdução
Finalidade
A finalidade deste documento é coletar, analisar e definir necessidades e características de alto nível dos envolvidos e usuários-alvo do projeto.
Referências
Documentação do SEDE.
Contextualização do Problema
O sistema de Contabilidade (S220) e o sistema de Contas Correntes (S048) são acessados por diversos órgãos e sistemas da Instituição Financeira através de diferentes formas e padrões. Surgiu a necessidade da criação de um sistema que atuasse como intermediário/canalizador no fluxo de informações entre estes dois sistemas. O objetivo era padronizar as informações enviadas para esses sistemas e facilitar sua manutenção, tornando-a uniforme.
Descrição do Problema
O problema: Existência de diversas formas de enviar informações
para o S220-Contabilidade e o S048-Contas Correntes
Afeta:
Usuários e Órgãos da Instituição Financeira que utilizam o sistema de Contas Correntes e o sistema de Contabilidade. Manutenção nos diversos sistemas que enviam as informações para o S220 e S048.
Impactos:
O envio de informações para os sistemas de Contas Correntes (S048) e para o sistema de Contabilidade (S220) não segue um padrão. Essa situação dificulta a manutenção de todos os sistemas envolvidos. Gerando retrabalho a cada nova alteração
Soluções e benefícios:
Dentre os benefícios do novo sistema, podemos citar: • Efetivação do enquadramento contábil, de
forma padronizada e pré-estabelecida, de todos os eventos ocorridos no Banco, que estejam previamente cadastrados no Sistema SEDE;
o Sistema Integrado de Contabilidade (S220) e o Sistema de Contas Correntes / Cheque Especial (S048);
• Armazenamento e disponibilidade para consulta (On-Line ou via Relatório/Arquivo) e para processamento por outros sistemas das informações referentes aos eventos recebidos e dos respectivos lançamentos gerados (partidas contábeis, débitos e créditos em C/C);
• Centralização da responsabilidade pelas mudanças no Plano de Contas e nos esquemas contábeis utilizados pelo Banco no Ambiente de Contabilidade cabendo aos demais órgãos da Instituição apenas informar a ocorrência de eventos contábeis;
• Promoção da integração com os diversos sistemas do Banco para viabilizar o recebimento dos movimentos contábeis, em forma de eventos, de modo que alterações de ordem contábil não afetem esses sistemas; • Racionalização dos trabalhos de auditoria
interna, através do acesso direto e tempestivo a informações de todas as unidades/órgãos do Banco;
• Fornecimento aos administradores da Instituição de uma base de dados referente à contabilidade para a tomada de decisão, mediante geração de relatórios gerenciais;
Oportunidade de Negócio
A implantação do Sistema de Entrada de Dados por Eventos permitirá uma padronização na entrada de dados nos sistemas de Contas Correntes e Contabilidade por ser um intermediário no fluxo de informações a estes sistemas. Além disso, não afetará os outros sistemas que enviam os eventos, no caso de alterações de ordens contábeis. A utilização do sistema permitirá a centralização da responsabilidade pelas mudanças no Plano de Contas e nos esquemas contábeis utilizados pela Instituição no Ambiente de Contabilidade, cabendo aos demais órgãos da Insituição apenas informar a ocorrência de eventos contábeis. O novo sistema proporcionará ainda a possibilidade de consultas ou processamento de informações referentes aos eventos recebidos e respectivos lançamentos gerados (partidas contábeis, débitos e créditos em conta corrente).
Descrição dos Stakeholders e Usuários
Stakeholders Relevantes
Papel Nome Responsabilidades
Gerente do Ambiente de Contabilidade
AÍLA Maria Ribeiro de Almeida F102652
• Acompanhar o desenvolvimento do projeto.
Gerente de Projeto
YARA Almeida Freire F096938
MESSIAS Salvino da Cruz F035513
• Fornecer padrões de TI da INSTITUIÇÃO. • Acompanhar implantação do projeto.
Analista SÁVIO Almeida Silveira F141615
• Levantamento dos requisitos
• Elaborar a documentação pertinente ao projeto (visão, regras de negócios e documentos de requisitos, etc).
Arquiteto •
Usuários
Tipo Responsabilidades Gerente do Ambiente de Contabilidade • Gerente de Projeto • Analista • Equipe do ProjetoPrincipais Necessidades dos Stakeholders ou dos Usuários
Stakeholder / Usuário Necessidade Prioridade
Gerente do Ambiente de Contabilidade • Gerente de Projeto • Analista • •
Visão Geral do Produto
O Sistema de Entrada de Dados por Eventos (SEDE) permitirá um fluxo padronizado de informações aos sistemas de Contas Correntes (S048) e ao sistema de Contabilidade (S220). As informações sobre os eventos e lançamentos recebidos poderão ser consultados e acessados por outros sistemas para processamento posterior. O sistema deverá seguir os padrões de segurança definidos pelo Banco para autenticação e autorização de usuários, bem como outros requisitos de segurança definidos pelas políticas do mesmo.
Requisitos Preliminares
• Padronizar a Geração de Lançamentos para o Contas Correntes (S048) • Padronizar a Geração de Lançamentos para o Contabilidade (S220) • Manter Tabelas de Eventos e Matriz de atributos.
• Realizar Críticas nos eventos recebidos
• Realizar Pré-Crítica nos eventos vindos da plataforma baixa • Consultar Eventos recebidos e Tabelas desses eventos • Gerar relatórios diários para consultas On-line.
