Trabalho de Formatura
Rodrigo Vieira Couto
num. USP: 3111441
rcouto@linux.ime.usp.br
Supervisora: Ana Cristina Vieira de Melo
acvm@ime.usp.br
9. Dezembro 2002
Versão 1.0
Resumo:
Relatório sobre o estágio supervisionado realizado na Editora
Abril de Janeiro de 2002 até Dezembro de 2002, na área de
Administração de Dados da Diretoria de Processos e Tecnologia da
Informação. O estágio consistiu de atividades visando pesquisas em
novas tecnologias, elaboração dos padrões de desenvolvimento de
software internos e acompanhamento de projetos.
Gostaria de agradecer inicialmente a meus pais por terem me
presenteado com formação, e informação, de qualidade em minha
infância e adolescência. Agradeço também a minha namorada,
Cristiane, que tolerou alguns (infindáveis) finais de semana que
gastei preparando meus trabalhos (inclusive esse).
Sou muito grato à Universidade de São Paulo e ao Instituto de
Matemática e Estatística que ofereceu-me uma abundante lista de
conhecimentos aos quais tenho grande interesse.
Agradecimentos especiais à Vanessa Paiva, minha gerente
supervisora na Editora Abril, pela atenção e paciência, e a meus
colegas de trabalho Luciano Alves, Fábio Barcarollo e Andréa Lúcia
Helena.
Agradeço também a profa. Ana Cristina Vieira Melo pelo cuidado que
teve por acompanhar meu desempenho ao longo do ano.
A Editora Abril, fundada em 1950, é uma empresa cujo negócio é,
embora não exclusivamente, comunicação. Nesse seguimento,
destaca-se como a maior da América Latina (30 milhões de leitores,
4.1 milhões de assinaturas, 150 títulos, 7 das 10 maiores revistas
do país1), atuando em:
- Revistas
- Livros
- Vídeos
- Música
- Internet
- Cabo e Multisserviços
- Database Marketing
- Educação
Sob o organograma do Grupo, conta-se ainda com a maior gráfica da
América Latina, com uma produção de 350 milhões de exemplares por
ano, e uma espantosa infra-estrutura de distribuição (1717 cidades
de entrega, 92% das entregas feitas porta-a-porta, 2 milhões de
km percorridos por mês, 1828 horas de vôo por mês).
O fundador, Vitor Civita, estabeleceu como missão da empresa a
seguinte frase, bastante divulgada internamente:
A Abril está empenhada em contribuir para a difusão de
informação, cultura e entretenimento, para o progresso da
educação, a melhoria da qualidade de vida, o desenvolvimento da
livre iniciativa e o fortalecimento das instituições
democráticas do país.
Mencionada pelo resto do texto por DTI (sigla designada ao seu
antigo nome: Diretoria de Tecnologia da Informação), a Diretoria
de Processos e Sistemas de Informação é responsável pela constante
reavaliação dos processos vigentes no Grupo (tanto que é
segmentada em gerências que atendendem a cada área de negócio
específica da empresa) e pelo desenvolvimento de sistemas que
implementam soluções que buscam a melhoria desses processos.
A DTI está sob a Unidade de Negócio Serviços
Compartilhados, que garante sua atuação geral dentro do Grupo,
como visto na figura 1.
Figura 1:
Organograma do Grupo Abril do final de 2001
![\includegraphics[scale=0.75]{organograma.eps}](img1.png) |
Historicamente, a área teve vários outros nomes (Administração de
Dados, AD, Adm. Dados e Governança, etc.) sempre tentando abranger
todas as responsabilidades que ela possui.
A área possui como missão:
Garantir a integração dos sistemas e a adoção de Metodologias,
Padrões, Métricas e Ferramentas no desenvolvimento, manutenção e
na gestão de qualidade dos sistemas e processos da área de TI da
Abril.
As responsabilidades de AD, resumidamente, são:
- Administração de Dados
- Manter Mapa de Contexto Geral dos Sistemas Abril
- Acompanhamento de Projetos
- Manutenção de Metodologias e Padrões de Desenv. de Sistemas
- Validação das manutenções em BD
- Auditoria de padrões de BD
- Manutenção e suporte às ferramentas Case
- Novas tecnologias
- Prospecção de Novas Tecnologias de Desenvolvimento de
Sistemas
- Validação da arquitetura de Projetos
- Definição e suporte às ferramentas de apoio ao
desenvolvimento
- Definição e Gerenciamento da Biblioteca de Componentes
Corporativos
- Governança
- Inventário de Sistemas
- Manutenção e suporte ao Relatório de Atividades
- Manutenção e suporte à ferramenta para cálculo do ROI
- Relacionamento e Homologação de fornecedores externos
- Definição e apuração das métricas de sistemas
- Auditoria de padrões operacionais
A equipe de AD é composta da gerente Vanessa Paiva, 3 analistas
seniores e 2 estagiários.
Cada analista está focado em uma das grandes áreas de atuação
(Adm. Dados, Novas tecnologias e Governança), embora não
exclusivamente, e os estagiários dão suporte onde necessário.
No mês de julho, foram fechadas algumas metas para o estágio de
forma a criar uma proposta de monografia relevante à matéria
Mac499 e simular um mini-projeto de DPR, conforme descrito na
seção 2.2.
As metas definidas foram:
- Acompanhamento de Projetos de Sistemas e Manutenção de Sistemas
em Produção
- Elaboração da Metodologia e Padrões para Desenvolvimento de
Sistemas Orientados à Objetos
- Projeto de Outsourcing de Manutenção de Sistemas
(Implantação de Helpdesk de Sistemas e Definição de
Métricas de Sistemas)
- Prospecção de ferramentas e softwares de apoio ao desenvolvimento
de sistemas
- Suporte e customizações na ferramenta Case Rational Rose
Detalharemos cada uma dessas atividades e seus resultados mais
adiante.
- Acompanhamento do Projeto Piloto MAP (Material Promocional)
(Ago - Out)
- Sistema de Segurança
(Ago - Set)
- Definição de um Framework padrão, com componentes
arquiteturais básicos
(Out - Dez)
- Elaboração do Padrão de Interface entre Aplicações
(Nov)
- Prospecção de ferramentas para auditoria de qualidade de
código Java
(Set - Out)
2.2 Programa de DPR
Direção Por Resultados - DPR - é o modelo de gerenciamento por
objetivos da Abril que interliga os sistemas de planejamento,
controle, mensuração e incentivo ao alcance das metas do negócio.
A DPR é composta de duas partes:
- DPR - Resultados Individuais, que tem como objetivo
reconhecer a contribuição dos profissionais para a melhoria dos
resultados da empresa. Por meio desse instrumento os objetivos
individuais dos profissionais de nível executivo e gerencial se
alinham aos objetivos de negócio a serem alcançados ao longo do
ano (Planejamento Operacional).
- DPR - Competências e Carreira, que tem como objetivo
promover o desenvolvimento profissional, proporcionando aos
gestores um instrumento facilitador de feedback, acompanhamento
das equipes e orientação de carreira.
Embora não aplicável oficialmente aos estagiários, a DPR que foi
simulada para o programa que participei foi uma boa experiência,
visto que é uma ótima ferramenta para auxiliar a decisão de foco e
de prioridades de sua carreira.
Desde a entrevista que fiz para seleção, esse assunto foi o foco de
maior interesse que tive no estágio. Havia uma demanda de
reciclagem dos analistas da área de TI quanto a novas tecnologias,
uma vez que o objetivo maior é atender ao negócio.
Era um plano da nova administração da diretoria que a área de AD
também prestasse serviço às outras áreas de "consultoria de
novas tecnologias".
Portanto, grande parte do estágio foi gasto com pesquisas de novas
ferramentas, frameworks, bibliotecas e plataformas que poderiam
ser apresentadas às outras áreas como solução.
Entre essas pesquisas destaco:
- Servidores de aplicação: devido às recentes
decisões sobre a arquitetura do parque de aplicações (seguindo o
desenvolvimento em Java e a arquitetura J2EE[1]),
era necessário paronizar um servidor de aplicação que seria
utilizado pelo Grupo Abril. Já se
sabia de iniciativas que utilizavam o software livre Tomcat -
http://jakarta.apache.org/tomcat/, porém a necessidade do
grupo era de um servidor que comportasse não só o Web Container,
como também um Bussiness Logic Container (EJB Container).
Assim, a partir de uma série de pesquisas, das quais participei
avaliando o mercado e especificações técnicas, foi decidido pelo
uso do ATG Dynamo (http://www.atg.com).
Essa decisão, contudo, foi estratégica e não baseada na qualidade
técnica do produto da ATG, visto que já havia disponíveis um certo
número de licenças para esse produto, referentes a uma empresa que
o Grupo Abril adquiriu. Era de consenso do grupo de pesquisa que
Applications Servers se tornaram commodities e, portanto, não
haveria grandes distinções de produtos.
Como efeito disso, após dois meses da decisão, com o anúncio que a
ATG não daria mais suporte ao Dynamo, teve-se que revogá-la,
optando-se então pelo JBoss (software livre -
http://www.jboss.org) que não foi nem considerado como
opção de escolha na primeira avaliação visto que não havia
suporte.
- Ferramentas de teste e de auditoria de código: Foi de
iniciativa da AD, a proposta de aquisição de ferramentas de teste
de código, uma vez que o desenvolvimento dos sistemas Abril são
realizados por terceiros.
A proposta era de poder gerar um certo número de métricas que
constariam nos contratos com os fornecedores. Métricas essas
que envolveriam desde testes funcionais, a testes unitários de
classe, e testes de carga[10].
Com isso, fui designado para pesquisar dentre um conjunto seleto
de empresas, ferramentas de teste automatizados. Essas empresas
foram mencionadas em pesquisas de mercado realizadas pela Gartner
(http://www.gartner.com).
A Diretoria optou por não adquirir a ferramenta, porém, quando
necessário comprar o serviço de stress test, tal relatório
será utilizado como forma de avaliação de parcerias. Aqueles que
possuirem as ferramentas de teste mencionadas, estarão mais bem
qualificados a trabalhar com a Abril.
A área de Administração de Dados é responsável pela manutenção dos
Padrões Técnicos, Operacionais e Políticos da DTI. Também é
responsável pela elaboração da Metodologia de Desenvolvimento de
Software do Grupo Abril.
A Metodologia e Padrões são publicados na intranet do Grupo e está
acessível a todos os funcionários.
Constantemente durante o estágio houve oportunidades de encorparar
novas melhorias à Metodologia de Desenvolvimento de Software.
Entre elas, participei da inclusão de uma nova fase da Metodologia
- Análise de Requisitos - na qual é descrito o modo de
levantar as necessidades do usuário final e documentá-las de forma
padronizada (modelo de casos de uso).
Esse foi o primeiro passo para migração para uma metodologia
puramente orientada a objetos2, o que vem
ocorrendo através de iniciativas como os Projetos "Pilotos".
Também a participação do Projeto de Controle de Acesso, vide
seção 3.4.3, contribuíra com a inclusão do levantamento
de Políticas de Controle de Acesso na Metodologia.
Esse foi o primeiro padrão que escrevi no meu estágio e também foi
o primeiro padrão publicado que visava o novo mundo OO.
Ele tem como objetivo "descrever a simbologia, nomenclatura e
especificação (documentação) dos elementos representados em um
Diagrama de Classes".
O foco maior foi criar um documento introdutório aos analistas de
forma a orientá-los na documentação padronizada de código
Java(Diagrama de Classes da UML[6]).
Esse padrão, devido ao seu maior impacto nos projetos a serem
desenvolvidos, foi criado por mim e revisado por um grupo formado
por 2 analistas de sistemas e pela Vanessa Paiva.
Foi decidido adotar um subconjunto da arquitetura J2EE (Java 2
Enterprise Edition[1]) devido especialmente a sua
estrutura n-tier (multi-camadas), que permite
escalabilidade, por ser um padrão aberto e por existirem
fornecedores bem capacitados nessa tecnologia (e com experiência)
no mercado brasileiro.
Desse subconjunto, foi optada unicamente as soluções que empregam
o modelo MVC(Model-View-Controller[5]) e
multi-camadas. O padrão J2EE original previa cenários
Cliente-Servidor, entre outros, que não interessavam ao Grupo, e
significariam uma possível estagnação tecnológica.
3.2.4 Padrão de Casos de Uso
A partir do projeto piloto SCPF (vide seção 3.4.1), foi
elaborado esse padrão baseado na especificação da UML[6]
e nas recomendações que a RUP[8] faz sobre
levantamento de requisitos.
A realização desse documento foi o primeiro e grande passo para a
migração da MDS para OO, sendo que foi incorporada a atividade de
Análise de Requisitos nela.
O sucesso desse passo foi demonstrar que o Modelo de Casos de Uso
estabelece um contrato formal entre o usuário e o
desenvolvedor sobre as necessidades funcionais e não-funcionais
que o sistema deve ocorrer, além de gerar métricas de negociação
com fornecedores de software, baseadas em custos por Use Case.
Além dos padrões citados sugeri e concretizei melhorias em
diversos outros padrões:
- (Padrão de) Padrões: especificação de como um padrão deve
ser elaborado para ser publicado.
- Modelagem lógica de dados
- Projeto físico de banco de dados
- Abertura de chamados à Banco de Dados
A principal atividade rotineira da área de AD é o atendimento de
chamados à Banco de Dados. Como a diretoria de TI é segmentada em
áreas de sistemas (clientes dos chamados) e infra-estrutura
(prestadores de serviço), foi estabelecido um fluxo no qual os
analistas que necessitam alterar objetos da base de dados (por
objetos entende-se tabelas, views, triggers, indexes, keys,
columns, etc - enfim, qualquer entidade de um sistema
gerenciador de banco de dados Oracle passível de
alteração[4]) especificam suas necessidades, que
são validadas e homologadas por AD e efetivadas pelos
DBAs(Database Administrators).
É bom notar também que o processo de desenvolvimento de sistemas
da Abril prevê três ambientes de bancos de dados:
- Desenvolvimento: banco dedicado aos analistas e
programadores do projeto/sistema para testes e codificação. Esse
ambiente não é auditado.
- Homologação: banco que tenta espelhar as condições
do banco de Produção, utilizado para homologação de
criação/alteração/remoção de objetos e dados do banco de produção.
Nem todos os projetos possuem verba para esse ambiente,
constituindo na verdade uma exceção.
- Produção: banco de dados onde estão ocorrendo as
transações efetivas do sistema.
Para manter um nível de qualidade de modelos de dados
(consistentes à realidade do banco de produção e bem
documentadas), a AD atua como auditor, interceptando os chamados
aos DBAs e só permitindo a continuidade se o modelo estiver de
acordo com os padrões estabelecidos.
A Metodologia de Desenvolvimento de Sistemas também prevê que,
para que a primeira versão do schema do banco seja
implantada, é necessária uma validação completa e geral do modelo
de dados, onde são realizadas por AD as seguintes validações:
- Aderência de nomenclatura de objetos ao Padrão de Modelagem
de Dados estabelecido
- Consitência e integridade referencial entre as entidades
- Clareza do Dicionário de Dados das entidades e atributos
3.4.1 Projeto Colaboradores
O Projeto Colaboradores (apelido para SCPF - Sistema de
Contratação de Pessoas Físicas), foi o primeiro piloto a
utilizar a nova Metodologia de Desenvolvimento de Sistemas
Orientado a Objetos do Grupo Abril.
Apenas a sua modelagem de processo foi realizada internamente.
Todos os outros passos, de levantamento de requisitos a
implementação, foram realizados por uma consultoria de Campinas,
Ci&T (http://www.cit.com.br), especializada em
desenvolvimento de ambientes J2EE.
Por ser um experimento, a gerência de AD foi alocada como
responsável por absorver as técnicas aplicadas a esse projeto, bem
como as melhores práticas de desenvolvimento de sistemas OO, e
incluí-las na nova Metodologia.
Para tanto, fui encarregado de, especialmente, observar a
modelagem de casos de uso, trabalho esse que resultou no novo
Padrão de Casos de Uso (na seção 3.2.4).
Embora meta do meu estágio, minha participação nesse projeto foi mínima.
Minha colaboração foi em ajudar na implementação do sistema de
Help Desk, denominado Get-a-Help, da empresa G&P
(http://www.gpnet.com.br), para que este estivesse
sincronizado com os sistemas que possuíamos inventariados num
recente banco de dados criado por AD.
3.4.3 Projeto Controle de Acesso
Talvez minha maior contribuição para o Grupo Abril tenha sido a
participação nesse projeto.
Ele trata do desenvolvimento de uma solução unificada de controle de acesso a
aplicações e banco de dados.
Como requisitos, havia a necessidade de criar um componente (na
verdade vários, um para cada plataforma) que pudéssemos acoplar
aos sistemas (tanto legado3 quanto novos) de forma que toda
autenticação4 e
autorização5
fossem realizadas através de um serviço único.
Também era necessário a criação
de um frontend único de administração para ambos, acesso a banco de
dados e sistemas, de forma a facilitar os processos de criação, remoção e
alteração de dados de usuários.
Por último, porém não menos importante, era necessário que o
componente conversasse com o Serviço de Diretórios do Grupo que
identifica cada funcionário a seu email e conexão à rede. Dessa
forma, finalmente integrar todos os repositórios de identidade.
Para tal, realizei nas últimas semanas de setembro um levantamento
com os analistas responsáveis sobre as soluções para controle de
acesso nas aplicações já existentes na Abril. Foram definidos para
o estudo 13 sistemas das mais diversas tecnologias e plataformas.
A partir da conclusão do levantamento, iniciei um estudo sobre as
funcionalidades que o Banco de Dados Oracle oferece para
controle de acesso. Foram avaliadas diversas possibilidades de
proteção dos dados em diversos níveis de atuação (Autenticação,
Acesso a objetos, Acesso a registros).
Após isso, foi concluído que a melhor forma de resolver todos os
problemas de centralização de usuários à proteção de linhas de
tabela, seria ter o cadastro de usuários e suas permissões em um
serviço de diretórios[7] de modo que todas as instâncias
do Oracle pudessem consultá-lo.
Essa estratégia traria como produto um processo unificado de
geração usuários, independente de DBAs. Esses usuários seriam
únicos no parque de aplicações. Uma grande vantagem é o fato desta
solução não exigir alterações de código do sistemas legado, e
mesmo assim garantir uma segurança maior de seus dados.
Porém, ao se levantar o custo de ter a opção Advanced
Security Options do Oracle, necessária para poder utilizar o
servidor de diretório e as opções de certificação, soube-se que
era impossível poder aplicar a estratégia ponderada.
Mesmo devido às imposições de custos ao projeto, foi decidido que
o controle a BD ainda seria realizado primeiro. Uma outra
arquitetura foi imaginada de forma que haveria apenas usuários de
banco de dados que representassem as aplicações. Esse modelo trás
como beneficio o fato que a administração de usuários deixa de
estar atrelado aos DBAs, o número de usuários de banco seria
mínimo (possíveis reduções de custos se for adotado um modelo de
cobrança por número de usuários) e ainda haveria segurança nos
níveis de acesso a objetos e acesso a registro.
Com as modificações organizacionais da diretoria ocorridas em
Fevereiro de 2002, a responsabilidade pela página de TI na
intranet local foi repassada para AD.
Dessa forma, o controle de publicação de padrões e de arquivos
específicos a alguns processos da Diretoria ficou como tarefa de
AD, mais especificamente minha.
Também fui designado a oferecer suporte às ferramentas homologadas
para desenvolvimento de software (vide seção 6.1) para
todos os analistas da DTI.
Dos estagiários que entraram comigo no processo seletivo do começo
de 2002, fui a única exceção ao ter como supervisora uma gerente.
Isso proporcionou pontos positivos e negativos.
Como ponto positivo, foi o contato direto com os projetos mais
avançados, em termos tecnológicos, que havia na Abril. Isso
porque a Vanessa Paiva, gerente de AD, sempre tomou iniciativas de
atualização das técnicas e tecnologias empregadas na DTI. Tive
também a experiência de participar de decisões que afetam
diretamente o modo de trabalho dos analistas da área.
Porém, o fato de responder diretamente a uma gerente não permitiu
um acompanhamento mais direto do meu estágio, visto sua
indisponibilidade de agenda.
Mesmo assim, os demais analistas da área, em especial Andréa Lúcia
Helena e Luciano Alves (que foi recentemente transferido para a
gerência), auxiliaram-me em muitas das minhas dúvidas e
dificuldades.
Houve duas avaliações formais de desempenho requisitadas pelo
departamento de RH. Interessante notar que grande parte dos pontos
avaliados não se referiam aos conhecimentos técnicos do
estagiário.
Dentre as disciplinas oferecidas no curso do BCC, as cruciais para
o meu estágio foram:
- Engenharia de Software: visto que meu estágio
requisitou que eu dissertasse sobre diferentes metodologias de
desenvolvimento de software, testes automatizados, linguagens e
ferramentas CASE[10], creio que esta foi uma das
matérias mais importantes do curso.
Temo apenas que devido à curta duração da disciplina, não tenhamos tido
a experiência necessária para que pudéssemos ter enraizados os
conceitos passados em aula. Acredito ser de grande relevância a
criação de uma outra matéria obrigatória no BCC: Laboratório de
Engenharia de Software.
- Sistemas de Banco de dados: essa matéria foi a que
me capacitou para realizar os trabalhos de dia-a-dia do meu
estágio - atendimento de chamados a Banco de Dados. Embora já
houvesse experiência de BD no meu estágio anterior, esse curso me
forneceu a base para poder ter, desde a compreensão sobre objetos
do banco de dados, até o senso crítico sobre modelos que
recebia para validar.
- Programação Orientada a Objetos: embora menos
presente, porém não menos relevante, POO garantiu que eu aplicasse
os conceitos essenciais de objetos em todo o desenvolvimento da
MDS e dos Padrões que participei, principalmente quanto a UML.
6.1 Ferramentas utilizadas
Tive como principais ferramentas de trabalho no meu estágio duas
ferramentas CASE (Computer-aided Software
Engineering[10]):
- AllFusion ERWin Data Modeler: essa ferramenta
auxilia a criação e gerenciamento de modelos de dados (conceitual,
lógico e físico).
É crucial para o processo de validação de modelos de dados que a
AD realiza, uma vez que as diferenças entre modelos e Banco
de Dados são detectadas utilizando a opção de Complete
Compare da ferramenta.
- Ratonial Rose: essa foi uma ferramenta desenvolvida
pela Rational (empresa criada pelos Three Amigos - Booch,
Rumbaugh e Jacobson - criadores da UML[6]), cujo objetivo
era dar suporte a toda a Metodologia desenvolvido pela mesma (RUP,
vide seção 6.3.1), de forma a ajudar desde a análise de
processos e levantamento de requisitos, até a geração automática
de esqueletos de código java.
Além da utilização da metodologia RUP (vide seção
6.3.1), utilizei padrões de programação orientada a
objetos, principalmente MVC[5][2], de
forma a ajudar a elaborar minha recomendação de arquitetura padrão
a ser utilizada pelo grupo. A arquitetura MVC prevê a maioria dos
cenários que os sistemas do grupo devem implementar.
6.3.1 Rational Unified Process
A mesma empresa que participou do Projeto Colaboradores (seção
3.4.1), Ci&T, realizou um treinamento sobre o Rational
Unified Process, metodologia definida pelos próprios criadores
como[9]:
"Um processo de Engenharia de Software, dirigido para guiar
organizações que desenvolvem software e seus clientes."
Trata-se de um framework de metodologias, voltado para a
arquitetura e design orientados a objetos. É fortemente baseado em
processos iterativos de desenvolvimento. Ele é segmentado em macro
workflows, os quais são executados paralelamente (com
intensidades diferenciadas) durante todo o decorrer do projeto,
sendo que a cada ciclo (esses, subdivididos em grupos: Gestação,
Elaboração, Construção e Transição) do processo iterativo se tenha
resultados concretos e apresentáveis.
Figura 2:
Tempo x Workflows x Intensidades do
RUP[8]
![\includegraphics[scale=0.5]{rup.eps}](img2.png) |
Foi oferecido a todos os estagiários da DTI um treinamento básico
de 4 horas sobre Análise e Modelagem de Processo. Essa área é
vista pelos próprios analistas como o ponto mais forte de atuação
da diretoria.
O primeiro desafio ao qual fui apresentado, e que durou até o
final do estágio, foi o fato de estar atuando numa área que
divergia bastante da minha formação clássica, matemática e
algorítmica. Várias vezes tive que parar e refletir se o que eu
estava pensando como solução seria mais adequado aos meus
clientes. Às vezes era difícil abrir mão de uma solução mais
tecnicamente elegante por esse motivo.
Outro grande desafio foi o fato de ter sido designado a escrever
Padrões. Como a tarefa requeria que eu adaptasse a tecnologia
sempre para o contexto Abril, basear-me na literatura nem sempre
era suficiente. Como exemplo tive a tarefa de propor um plano de
transição da Metodologia Estruturada para a Orientada a Objetos de
forma graduada. Ou seja, deveria introduzir os conceitos de OO
pouco a pouco (versão a versão) dentro da MDS plenamente conhecida
de forma a induzir uma conscientização dos analistas quanto aos
benefícios que esta nova abordagem traria.
Houve algumas solicitações de trabalhos para mim que claramente
não surtiriam resultados relevantes, ou como minha própria gerente
falava: "não agregavam nenhum valor", e que mesmo assim eram
cobradas. Uma delas foi o Padrão de Interface entre Aplicações
(aos íntimos, Padrão de XML) cuja idéia inicial era definir
metadados para quaisquer possíveis novas comunicações entre
sistemas de diferentes plataformas tecnológicas. Tarefa
impossível. Portanto, restringi-me a traduzir a definição da
linguagem XML e DTD[3] e, assim, terminei por fazer
um padrão superficial.
Outra grande frustração foi referente ao Projeto Controle de
Acesso (vide seção 3.4.3), onde estava com "carta branca"
para propor uma solução que atendesse a todos os requisitos do
projeto. A solução que levantei, e que foi bem aceita, era de
utilizar as opções de segurança que o gerenciador de banco de
dados Oracle oferecia para integrar o controle de acesso ao
Serviço de Autenticação e Autorização. Assim, teria-se uma solução
que controlaria segurança dos repositórios de dados, mesmo para os
sistemas legado.
O problema era que o Grupo Abril não possuía licenças para usar
essas opções especiais do banco e isso teria um custo muito alto.
Com isso, o grande benefício do projeto foi inviabilizado.
Assim, termino por relatar que, mesmo com inúmeras propostas de
renovação do parque tecnológico, a Abril ainda se mantém obsoleta
em termos tecnológicos. Isso devido aos altos custos para
investimentos e receios de mudanças tecnológicas. E disso vem a
grande barreira que enfrentei, tentar vender novas tecnologias
para uma empresa com outros objetivos estratégicos (reduzir
custos), além da resistência a mudanças, por parte dos analistas.
Internamente, o ambiente de trabalho em AD sempre foi muito bom.
Sempre houve uma convivência muito agradável, a menos de alguns
pequenos desentendimentos, entre os membros da gerência.
Foi notável também a flexibilidade que pude ter quanto a horários
para poder manejar minha grade de aulas do último semestre do
curso.
Porém, devido ao fato de nosso atendimento de chamados requerer,
algumas, vezes um certo grau de intransigência com os analistas,
devido a erros ou melhorias a serem feitas em seus modelos,
diversas vezes o clima de trabalho com as outras gerências foi
prejudicado.
Contudo, essa situação era a exceção. Os analistas de DTI
compreendem o papel de AD (auditoria) e sabem que algumas
"intransigências" não eram de cunho pessoal, e sim de exigência de
cumprimento de padrões.
Basicamente, a diferença entre a cooperação de equipes na
faculdade com as do trabalho é bem clara: a presença de um
cliente.
Na faculdade todo trabalho que é desenvolvido tem como objetivo a
aprendizagem de algum assunto. Já no estágio, a cobrança vem de
terceiros cujas responsabilidades são diretamente relacionadas ao
negócio da empresa. Ou seja, se há atrasos, há prejuízos ao
atendimento de necessidades de negócio.
A grande melhoria que vejo que poderia ter no programa de estágio
oferecido pelo Grupo Abril é dar a oportunidade de participar de
um projeto (mesmo que de menor escala), do começo ao fim. Eu só
tive a chance depois que mais de 70% do programa já havia sido
realizado.
Há indícios que para o ano de 2003, essa melhoria seja efetivada.
Também enxergo que se houvesse maior abertura do Grupo a Softwares
Livres, diversos problemas de recursos de projeto seriam
resolvidos. Por Software Livre, restrinjo-me àqueles que são
fortemente aderidos a padrões e que a comunidade já os tenha
aprovado (como Apache, GNU/Linux, ...).
Levo desses quases 11 meses de estágio diversas lições
profissionais e de vida.
Primeiramente, aprendi a discernir os momentos em que estou
tentando aprender ou aperfeiçoar uma técnica, dos momentos em que
estou empregando-a para servir alguém. Nesses últimos, é crucial
se apegar às necessidades do seu cliente, sem perder a noção da
excelência técnica, pois é isso que norteia as soluções dadas.
E reitero o clichê de que teoria e prática são muitas vezes
diferentes no mundo empresarial.
Mas o mais importante foi a seguinte frase que me foi dita por um
consultor que trabalhou para o Grupo por alguns poucos dias:
Não adianta apenas apontar um defeito. Você deve encará-lo
como uma oportunidade e sempre apresentá-lo junto a uma solução,
por mais simples ou ingênua que possa parecer.
- 1
-
Stephanie Bodoff, Dale Green, Kim Haase, Eric Jendrock, Monica Pawlan, and Beth
Stearns.
The J2EE tutorial.
Addison-Wesley Longman Publishing Co., Inc., 2002.
- 2
-
Dan Malks Deepak Alur, John Crupi.
Core J2EE Patterns: Best Practices and Design Strategies.
Prentice Hall / Sun Microsystems Press, 1 edition, 2001.
- 3
-
W. Scott Means Elliotte Rusty Harold.
XML in a Nutshell, 2nd Edition: A Desktop Quick Reference.
O'Reilly & Associates, Inc., 2 edition, 2002.
- 4
-
Ramez Elmasri and Shamkant B. Navathe.
Fundamentals of database systems.
Addision-Wesley, 2000.
- 5
-
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Design Patterns: Elements od Reusable Object-Oriented Software.
Addison-Wesley Professional Computing Series. Addison-Wesley
Publishing Company, New York, NY, 1995.
- 6
-
Linda Heaton.
OMG Unified Modeling Language Specification, v1.4.
OMG - Object Management Group, September 2001.
http://www.omg.org/technology/documents/formal/uml_2.htm.
- 7
-
Tim Howes and Mark Smith.
The ldap application program interface.
Available from ftp://ds.internic.net/rfc/rfc1823.txt, August
1995.
Request for Comments 1823.
- 8
-
P. B. Kruchten.
The Rational Unified Process. An Introduction.
Addison-Wesley, 2000.
- 9
-
Philippe Kruchten.
What is the rational unified process?
The Rational Edge, January 2001.
http://www.therationaledge.com/content/jan_01/f_rup_pk.html.
- 10
-
Roger S. Pressman.
Software engineering: a practitioner's approach.
McGraw-Hill Higher Education, 5th ed. edition, 2001.
Trabalho de Formatura
This document was generated using the
LaTeX2HTML translator Version 99.2beta6 (1.42)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -t 'Trabalho de Formatura' -dir html -split 0 -show_section_numbers -html_version 4.0 -local_icons -antialias -white -auto_navigation monografia.tex
The translation was initiated by Rodrigo Vieira Couto on 2002-12-09
Footnotes
- ... país1
- Fonte: Intermeios + Projeção Abril
- ... objetos2
- OOAD - Object-oriented
Analysis & Design: disciplina que descreve como um software deve
funcionar e os requisitos do seu usuário, e como criar o modelo de
como o código deve se comportar. [10]
- ... legado3
- Por sistema legado se entende
uma aplicação que foi desenvolvida em algum momento do passado e
não necessariamente segue as regras, padrões e tecnologias
vigentes no momento.
- ...
autenticação4
- autenticação: ato de comprovação da
identidade de um sujeito
- ...
autorização5
- autorização: ato de confirmar a
permissão de uma identidade quanto a uma certa funcionalidade
Rodrigo Vieira Couto
2002-12-09
