Por exemplo: Submeta para aprovação do cliente um cronograma, projeto, orçamento de horas ou seja lá qual for o nome que você dá para aquele documento com prazos para o desenvolvimento de um sistema. Clientes em universos paralelos podem questionar você que 16 horas é muito tempo para a criação de uma feature qualquer, ainda que ela seja complexa. Diz que é possível fazer em 8 horas tranquilamente. Vejam, 16/8, é a tal proporção 2/1 que citei. Clientes em universos paralelos mais velozes podem sugerir que o tempo caia de 16 horas para 4 horas, afinal é só uma tela. Ou seja, este universo tem uma proporção de tempo de 4/1 se comparado com o universo normal, onde nós desenvolvedores mortais vivemos. É um universo Speed Racer.

Outros clientes vivem em universos com peculiaridades complexas na estrutura temporal. Nós, desenvolvedores mortais temos freqüentemente dificuldade em compreender tal lógica que desafia todos os conceitos da física. Por exemplo, certa vez estava trabalhando no tunning de um sistema que ajudei a desenvolver. O sistema permitia que uma certa atividade pudesse ser feita em lotes de itens cujo tipo não vem ao caso aqui. Então o usuário preparou uma planilha com os tempos atuais da atividade quando um item, quinze itens ou trinta itens eram submetidos. Vamos dizer que o resultado foi 1x, 15x e 30x. Obviamente todos insatisfatórios no rápido e misterioso universo em que eles vivem. Ao lado desta tabela, havia outra com os tempos esperados. Eles queriam que um item levasse 0,5x tempo. Até ai tudo bem. O problema era que quinze itens deveriam levar não 7,5x como esperado, mas sim 5x. E trinta itens deveriam levar 8x e não 15x. Ou seja, quanto mais itens processados, menor era o tempo individual de cada um, eles tendiam a zero. Se conseguísse atender o cliente, talvez se eu processasse milhões de itens eu conseguiria fazer o tempo correr ao contrário. Não fiz este teste porque eu poderia abrir um buraco negro ou alguma coisa assim e hoje você não estaria lendo isso.

Há ainda universos onde parar o tempo é algo corriqueiro. Suponha que seu cliente tenha aprovado seu cronograma e depois se lembrou de outra feature que ele quer no aplicativo. Ele não aceita mudar o prazo final, não aceita pagar horas extras para o desenvolvimento e não aceita pagar por mais recursos no projeto. Ele insistirá que dá para encaixar a tal feature no projeto sem comprometer o bolso dele e o prazo final. O que me leva a crer que no universo onde ele vive é possível parar o tempo, desenvolver a feature e depois soltar o tempo para que ele corra novamente.

Clientes são pessoas com estas e outras incríveis capacidades físicas que me admiram a cada contato e projeto novo. Há sempre algo surpreendente e desafiador por trás de cada solicitação em um projeto.

PATH=$PATH:$HOME/bin
export PATH unset USERNAME
# Definicoes Para o Usuario Oracle
TMP=/tmp; export TMP TMPDIR=$TMP; export TMPDIR
ORACLE_BASE=/oracle/product/app; export ORACLE_BASE ORACLE_HOME=$ORACLE_BASE/10R2/db; export ORACLE_HOME ORACLE_SID=BANCO1; export ORACLE_SID ORACLE_TERM=xterm; export ORACLE_TERM PATH=/usr/sbin:$PATH; export PATH PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH CLASSPATH=$ORACLE_HOME/jre:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH
DATABKP=`date +%Y%m%d%H%M%S` echo "$DATABKP" > /tmp/data.log rman log=/tmp/logbkpDGUARD.${DATABKP}.log << EOF connect target <a href="mailto:sys@bdorigem">sys@bdorigem</a>
connect auxiliary / connect catalog <a href="mailto:spcrman@rman">spcrman@rman</a>
run { ALLOCATE auxiliary CHANNEL c1 DEVICE TYPE DISK FORMAT '/DADOS/FULL/rman/%U'; ALLOCATE auxiliary CHANNEL c2 DEVICE TYPE DISK FORMAT '/DADOS/FULL/rman/%U'; ALLOCATE auxiliary CHANNEL c3 DEVICE TYPE DISK FORMAT '/DADOS/FULL/rman/%U'; ALLOCATE auxiliary CHANNEL c4 DEVICE TYPE DISK FORMAT '/DADOS/FULL/rman/%U'; ALLOCATE auxiliary CHANNEL c5 DEVICE TYPE DISK FORMAT '/DADOS/FULL/rman/%U'; ALLOCATE auxiliary CHANNEL c6 DEVICE TYPE DISK FORMAT '/DADOS/FULL/rman/%U'; duplicate target database for standby; release channel c1; release channel c2; release channel c3; release channel c4; release channel c5; release channel c6; } EOF

Nesse caso até a parte o restore rodou sme problmas, porém ao tentar rodar o script interno de final do duplicate aparece a mensagem de erro abaixo:

Finished restore at 30-DEC-10
contents of Memory Script:
{
switch clone datafile all;
}
executing Memory Script
released channel: c1
released channel: c2
released channel: c3
released channel: c4
released channel: c5
released channel: c6
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 12/30/2010 18:40:06
RMAN-03015: error occurred in stored script Memory Script
RMAN-06004: ORACLE error from recovery catalog database: ORA-03135: connection lost contact
ORACLE error from recovery catalog database: ORA-03114: not connected to ORACLE

Para solucionar esse problema devemos seguir os 13 passos a seguir na ordem crescente:

PASSO 1.
Após o erro,o banco estará montado, deveremos então gerar um script do controlfile para ser editado nos passos posteriores através do seguinte comando:

alter database backup controlfile to trace;

PASSO 2
após o comando deve-se ir até a pasta udump abaixo do $ORACLE_BASE/admin/banco1/udump e fazer um rename desse arquivo para identificálo como controlfile atual.

Mv spcap1_ora_626734.trc controlfile03_01_2011.txt

PASSO 3

voltar para o home com o comando “/”

setar as variaveis do ASM com o comando “. .ASM”

#PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:.
export PATH
if [ -s "$MAIL" ]
# This is at Shell startup. In normal then echo "$MAILMSG"
# operation, the Shell checks fi
# periodically.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# Oracle specific environment # .profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# Oracle specific environment
ORACLE_BASE=/oracle/product/app
ORACLE_HOME=/oracle/product/asm
ORACLE_ASM_HOME=/oracle/product/asm
ORACLE_CRS_HOME=/oracle/product/crs
ORACLE_SID=+ASM1 #
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib export
TNS_ADMIN=$ORACLE_HOME/network/admin
ORACLE_NLS33=$ORACLE_HOME/nls/data
EDITOR=vi # User specific environment and startup programs
PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin:$ORACLE_RAC_HOME/bin:$ORACLE_CRS_HOME/bin:$ORACLE_HOME/OPatch:/sbin
export PATH ORACLE_BASE ORACLE_HOME ORACLE_SID ORACLE_RAC_HOME ORACLE_CRS_HOME ORACLE_ASM_HOME LD_LIBRARY_PATH ORACLE_NLS33 EDITOR
export TEMP=/tmp export TMP=/tmp export TMPDIR=/tmp
umask 022
export PS1="$ORACLE_SID "'$PWD'" > "
echo " " echo " Hostname : `hostname`" echo " ORACLE_SID : $ORACLE_SID " echo " ORACLE_HOME : $ORACLE_HOME " echo " USER : `whoami` " echo " " echo " " -------

entrar no ASM com o comando “AMSCMD”
ir para a pasta de datafiles com o comando “cd +dg1/dbale/datafile”
listar todos as datafiles com o comando “ls -lart”
copiar os nomes selecionando todos e copiando para um editor de texto qualquer

PASSO 4

Editar o controlfile gerado no PASSO 1 e substituir os nomes do datafiles pelos nomes e caminho copiados do ASM.

PASSO 5

Se o banco for Cluster (que é o nosso caso) inibir todos os parametros de cluster_database*** do init.

PASSO 6

Tirar o banco do ar com o comando “shutdown immediate;”
Subir o banco em nomount com o comando “startup nomount;”
Recriar o banco usando o script de controlfile editado, já apontando para os novos caminhos.

PASSO 7

Criar scripts de rename dos datafiles e catalog do RMAN para serem usando nos passos posteriores atraves do script abaixo:

spool /oracle/renamefiles.txt select 'SET NEWNAME FOR DATAFILE '||FILE#||' to '||''''||name||''''||';' from v$datafile; spool off
--spool /oracle/renamelogs.txt --select 'SET NEWNAME FOR LOGFILE '||group#||' to '||''''||member||''''||';' --from v$logfile ; --where IS_RECOVERY_DEST_FILE='YES'; --spool off
--spool /oracle/renametmpfiles.txt --select 'SET NEWNAME FOR TEMPFILE '||FILE#||' to '||''''||name||''''||';' --from v$tempfile; --spool off
spool /oracle/catalogfiles.txt select 'catalog datafilecopy '||''''||name||''''||';' from v$datafile; spool off

PASSO 8

Tirar o banco do ar com o comando “shutdown immediate;”
Subir o banco em nomount com o comando “startup nomount;”
entrar no RMAN com o comando “rman target / ”
procurar o controlfile de standby gerado logo depois do backup restaurado e fazer o restore usando o seguinte comando :

 restore controlfile from '/caminho/stbcontrolfile20101229020000.ctf'”

PASSO 9

Rodar o script que cataloga os datafiles gerado no passo 7 com o seguinte comando dentro do rman:

“@/oracle/catalogfiles.txt

OBS: Esse passo é o mais demorado e tem duração de mais de 2 horas. PASSO 10 Rodar o script que renomeia os datafiles gerado também no passo 7 com o seguinte comando dentro do rman: “@/oracle/renamefiles.txt” PASSO 11

Ainda dentro do RMAN, catalogar todos os archives da area atraves do comando catalog abaixo que no meu caso está apontando para o diretório “/DADOS/archives”:

“catalog start with ‘/DADOS/archives;”

PASSO 12

criar o script de recover abaixo deve rodar como nohup:

PATH=$PATH:$HOME/bin
export PATH unset USERNAME

# Definicoes Para o Usuario Oracle
TMP=/tmp; export TMP TMPDIR=$TMP; export TMPDIR
ORACLE_BASE=/oracle/product/app;
export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/10R2/db;
export ORACLE_HOME
ORACLE_SID=bancos1;
export ORACLE_SID
ORACLE_TERM=xterm;
export ORACLE_TERM
PATH=/usr/sbin:$PATH; export PATH PATH=$ORACLE_HOME/bin:$PATH;
export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib;
export LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/jre:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib;
export CLASSPATH
DATABKP=`date +%Y%m%d%H%M%S` echo "$DATABKP" > /tmp/data.log rman log=/tmp/reclogbkpDGUARD.${DATABKP}.log >> EOF
connect target /
run {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/DADOS/archives/';
ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/DADOS/archives/';
ALLOCATE CHANNEL c3 DEVICE TYPE DISK FORMAT '/DADOS/archives/';
ALLOCATE CHANNEL c4 DEVICE TYPE DISK FORMAT '/DADOS/archives/';
ALLOCATE CHANNEL c5 DEVICE TYPE DISK FORMAT '/DADOS/archives/';
ALLOCATE CHANNEL c6 DEVICE TYPE DISK FORMAT '/DADOS/archives/';
recover database;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
release channel c5;
release channel c6;
} EOF
nohup scriptacima.sh

Obs: Acompanhar o log no diretorio /tmp

PASSO 13
Depois de aplicar todos os archives existentes e catalogados pelo rman, iniciar o processo de recover automatico pelo dataguard através do sqlplus com o seguinte comando:

sqlplus / as sysdba
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 4 disconnect from session;

1. Em projetos ágeis não é necessário fazer uma grande entrega no final do projeto. É possível e desejável que se faça pequenas entregas com a possibilidade do cliente iniciar o uso imediato do que já foi entregue. Isso por si só já leva a uma maximização do ROI dado que o projeto já pode ser usado enquanto novas funcionalidades são criadas. Cada nova entrega pode trazer um pouco de retorno.

2. Como podemos e devemos fazer pequenas entregas, em projetos em que os métodos ágeis são usados, a tendência natural é ignorar os itens que não geram valor. Estudos mostram que somente 20% das funcionalidades são usadas sempre ou frequentemente e 64% das funcionalidades são desperdício.

Isto tudo também faz com que o projeto tenda a ser finalizado antes, liberando os recursos para outras demandas.

3. Em  projetos tradicionais, a mudança de escopo não é bem-vinda, mas em métodos ágeis, as mudanças são bem-vindas, principalmente, quando elas levam a uma melhor adaptação do projeto às necessidades de negócio com definição de prioridades entre elas.

Será que não podemos fazer várias pequenas entregas no lugar de uma grande entrega?

Será que o escopo não pode ser alterado?

Será que as funcionalidades não podem ser reordenadas?

Métodos ágeis representam sim e muito uma quebra de vários paradigmas em relação a forma de como os projetos são conduzidos tradicionalmente e  isso pode ser muito bom se bem utilizado.

Os grandes ERPs de mercado são globalizados como tudo atualmente, mas não há uma localização tão complexa como a feita para o nosso país. Vivemos em um verdadeiro emaranhado de atos legais. Em números divulgados pelo Banco Mundial em 2008, as empresas brasileiras gastavam em média 2600 horas por mês para atender as obrigações acessórias da legislação. Sem dúvida, esse número aumentou consideravelmente de lá para cá. E, para o correto cumprimento dessas obrigações, a base de dados está dentro dos ERPs. Sendo assim, temos de nos adaptar – dentro de funcionalidades da chamada localização – a um número insano de atos legais federais, estaduais, municipais, áreas incentivadas, tributos retidos, operações de substituição tributária e outros.

Além do desafio de desenvolver funcionalidades técnicas que atendam à necessidade de ter uma base de dados íntegra e com qualidade fisco-contábil-tributária, há o entendimento funcional do cenário fiscal propriamente dito, o que em alguns casos requer grande ‘cultura tributária’.  Tomemos como exemplo o caso da PIS e da Cofins, regime não cumulativo, objeto da EFD PIS COFINS, renomeada de EFD Contribuições.

Todos os cenários necessários ao atendimento da legislação – no caso da PIS COFINS, uma caótica coletânea de mais de 60 atos legais –, um sem número de soluções de consulta e várias questões ainda em aberto no CARF (Conselho Administrativo de Recursos Fiscais) precisam ser atendidos pelos ERPs e devem, portanto, estar previstos na ‘Localização Brasil’.

Existem situações tão variadas como alíquota básica, alíquotas específicas setoriais (como o regime automotivo), bases reduzidas em operações com bens de capital, entre tantas outras. É muitas vezes difícil explicar aos estrangeiros o porquê da Localização ser tão extensa e tão complexa. Afinal, ela é assim porque a legislação brasileira é extensa e complexa. Enquanto a localização de um ERP em um país europeu corresponde a uma pequena parte do todo, no caso do Brasil muitas vezes equivale a praticamente metade das consistências efetuadas pelo ERP.

Outro grande desafio que não pode deixar de ser mencionado é a implantação da localização, focando aqui na parte fiscal e contábil dentro do ERP. Se houve um grande esforço técnico para atender a demanda, acompanhado, obviamente, do conhecimento necessário para a adequação acontecer da forma desejada, passamos agora para a fase em que precisamos de um consultor funcional, com grande conhecimento nos assuntos ligados à localização, para ter condições de se comunicar com o usuário em níveis próximos.

Há um grande desgaste quando o usuário não tem empatia com o profissional funcional responsável pela implantação, por estarem em níveis de conhecimento muito diferentes. Nesse momento, mesmo tendo sido feito todo um esforço para que o desenvolvimento da localização atendesse às necessidades da melhor maneira possível, corre-se o risco de perder tudo o que foi conquistado até o momento no instante em que o cliente e o profissional responsável pela implantação estão frente a frente. E esse é um problema grave, já que – ao contrário de outras matérias-primas abundantes no mercado – esse tipo de recurso humano é bastante escasso.

Em resumo, há dois fatores muito importantes – e cada vez mais valorizados – nos ERPs comercializados no Brasil: a correta conceituação da ‘Localização Brasil’, com a adequação e o desenvolvimento de suas funcionalidades, e a implantação – que deve ser realizada de forma empática com os clientes e utilizando os recursos disponíveis prontamente, de modo que as variáveis sejam realmente atendidas. Para ambas é necessário um conhecimento profundo das normas impactantes na chamada ‘Localização Brasil’.

Para todos que estão envolvidos nesse cenário (usuários, clientes, consultorias e fábricas de softwares), é importante ter em mente que o sucesso da utilização de um ERP depende totalmente da aderência das funcionalidades da ‘Localização Brasil’. E para se atingir esse ponto, bem como para o desenvolvimento de customizações visando atender aos ditames legais localizados, o conhecimento técnico da cultura e das rotinas fiscais e contábeis é tão importante quanto o papel desempenhado por programadores e desenvolvedores de primeiro time. Só assim o resultado terá grandes chances de sucesso neste mercado que é hoje muito mais exigente do que há alguns anos.

Muitas vezes nos deparamos com questões de âmbito financeiro para uma tomada de decisão.

Neste artigo, estarei expondo alguns ítens e conceitos técnicos interessantes para a utilização de servidores Oracle com Sistema Operacional Solaris, os quais podem prover uma redução considerável de custos com hardware.

A Oracle com seu Sistema Operacional Solaris (Adquirido juntamente com a compra da SUN), oferece um recurso muito interessante de Containers.

Um Container é nada mais que um servidor virtual, ou seja, você estará com um servidor hospedeiro (Global Zone) e um servidor “parasita” (Local Zone).
Exatamente desta maneira, desde que haja um bom planejamento e adequado mapeamento de recursos, pode-se obter uma economia considerável em relação a compra de hardware.

Por exemplo, vamos imaginar uma demanda de 3 servidores de banco de dados oracle, os quais, por definição e organização do negócio, devem rodar em máquinas distintas, com IPs separados, cada qual com a sua instance oracle. Além disto, sei que as bases não terão uma carga muito significativa e em estudos de Capacity Planning, identifico que utilizando 3 servidores separados, vou ter muito recurso ocioso.

Neste caso, posso otimizar o consumo de recursos, juntando 3 containers num mesmo domínio, com isto, apenas um servidor físico hospedaria 3 servidores virtuais.
Na maioria dos casos, isto proporciona uma grande economia e ainda sem desperdícios de recursos ociosos.

Você pode estar se perguntando:  - Como organizar isto?

Bem, existem algumas formas, estarei demonstrando a seguir alguns passos para facilitar esta organização, tecnicamente é algo simples mas em termos de negócio será extremamente útil.

Vamos considerar que a memória dos 3 servidores será compartilhada, sem divisões, o consumo determinado pela SGA definida em cada base e depois aumentará de acordo com a quantidade de sessões.

Para CPU, inicialmente é necessário definir quantas CPUs possuo no servidor, sendo que após identificado a quantidade de processadores, é necessário que sejam estimados os consumos para cada uma das bases, consequentemente a quantidade que irei alocar para cada servidor virtual.

Lembro que neste momento, é importante ter em mente que o próprio servidor hospedeiro necessita de pelo menos 1 cpu (note que esta unidade corresponde a 1 core)
Feita a definição de quantidade de cpus por servidor virtual, existe a necessidade de criar pools de configuração e dos containers em si.

Vou citar o exemplo com um Container Sparse, o qual julgo como mais útil, pois sua administração fica muito mais simples (Sistema Operacionar do servidor virtual é herdado do servidor “hospedeiro”).

A sequência de comandos abaixo poderá ser utilizada pelo administrador do SO, para a criação de cada um dos três Containers :
# zonecfg -z container1
zonecfg:container1> create
zonecfg:container1> set zonepath=/zones/container1
zonecfg:container1> set autoboot=true
zonecfg:container1> verify
zonecfg:container1> commit
zonecfg:container1> exit
# zoneadm -z container1 install
# zoneadm -z container1 boot

Lembrando que o que foi efetuado neste passo, foi uma instalação de SO, portanto é necessário efetuar as configurações básicas do SO:
# zlogin -C container1
(Seguir com configurações básicas, indicando o tipo de terminal, time zone, endereço ip, senha de root, etc)

Após criar os containers, será necessário utilizar as informações de acordo com as decisões tomadas (Em relação ao número de CPUs). Este é o momento que utilizo mais um recurso do Solaris, Resource Controls. Segue abaixo os passos para ativar este recurso, dedicando 2 processadores ao servidor virtual container1:
# pooladm -e
# pooladm -s
# poolcfg -c ‘create pset my-pset (uint pset.min=2; uint pset.max=2)‘
# poolcfg -c ‘create pool my-pool‘
# poolcfg -c ‘associate pool my-pool (pset my-pset)‘
# pooladm -c
# pooladm -s
# zonecfg -z container1
zonecfg:container1> set pool=my-pool
zonecfg:container1> verify
zonecfg:container1> commit
zonecfg:container1> exit

Neste momento, basta efetuar um boot no container1 para que o mesmo funcione exclusivamente com 2 processadores.
# zoneadm -z container1 reboot

Como pode ser notado, não é complicado para que o administrador de Sistema Operacional Solaris efetue esta configuração.

Para um leigo, poderia ser algo um pouco mais complexo para assimilar, mas o principal ponto é que, com este tipo de utilização, conseguimos isolar servidores virtuais, para que cada um tenha sua utilização um pouco mais independente, atendendo diferentes tipos de demanda e economizando recursos de hardware que poderiam ficar subutilizados.

Assim, por exemplo, com apenas um servidor com 8 cpus e 32GBs, posso criar 3 servidores virtuais de 2 cpus cada, sem que um influencie o outro em termos de consumo de processamento.

Sobraria ainda mais 2 processadores para o servidor Global (Hospedeiro) e somente teria a memória de 32GBs compartilhada entre todos os servidores.
Ou seja: Compro apenas um servidor e utilizo a funcionalidade de três.

Seguindo nesta linha, podemos utilizar a criatividade e montar ambientes diversos, com mais servidores ou mais cpus, configurações de hardware diferenciados, mas economizando em hardware, o que é sempre muito interessante para todos.

    SQL>  select * from v$transportable_platform;

     PLATFORM_ID PLATFORM_NAME                            ENDIAN_FORMAT

   ----------- ---------------------------------------- --------------

             1 Solaris[tm] OE (32-bit)                  Big

             2 Solaris[tm] OE (64-bit)                  Big

             7 Microsoft Windows IA (32-bit)            Little

            10 Linux IA (32-bit)                        Little

             6 AIX-Based Systems (64-bit)               Big

             3 HP-UX (64-bit)                           Big

             5 HP Tru64 UNIX                            Little

             4 HP-UX IA (64-bit)                        Big

            11 Linux IA (64-bit)                        Little

            15 HP Open VMS                              Little

             8 Microsoft Windows IA (64-bit)            Little

             9 IBM zSeries Based Linux                  Big

            13 Linux x86 64-bit                         Little

            16 Apple Mac OS                             Big

            12 Microsoft Windows x86 64-bit             Little

            17 Solaris Operating System (x86)           Little

            18 IBM Power Based Linux                    Big

            20 Solaris Operating System (x86-64)        Little

            19 HP IA Open VMS                           Little

1. Verifique se há restrições

————————————————

Reveja as “Limitações no Uso Transportable Tablespace” seção na Nota 371556,1. Entre outras coisas, objetos que residem no tablespace SYSTEM e objetos pertencentes a SYS não serão transportados.

Isto inclui, mas não está limitado à usuários, privilégios, Stored Procedures PL/SQL e views.

Se você usar SPATIAL INDEX, aplicar a solução na Nota 579136,1 “IMPDP TRANSPORTABLE TABLESPACE  FAILS for SPATIAL INDEX” antes de continuar

Verifique se os tablespaces serão auto-suficientes

 execute sys.dbms_tts.transport_set_check('TBS_DADOS,TBS_INDICE,USERS,TOOLS', true);

 select * from sys.transport_set_violations;

==> Essas violações devem ser resolvidas antes de trasportar os tablespaces.

Coloque as tablespaces em modo READ ONLY

ALTER TABLESPACE TOOLS READ ONLY;

ALTER TABLESPACE USERS READ ONLY;

ALTER TABLESPACE TBS_DADOS  READ ONLY;

ALTER TABLESPACE TBS_INDICE READ ONLY;

3. Exporte os metadados

 exp userid=\'/ as sysdba\' transport_tablespace=y tablespaces=TBS_DADOS,TBS_INDICE,USERS,TOOLS file=spc_tts.dmp log=exp_spc_tts.log statistics=none

Note: Os dados da tabela não serão exportados

Sobre o export dos metadados usando transportable tablespace…

For tablespace REPOSIT …

      . exporting cluster definitions

      . exporting table definitions

      . . exporting table                MTG_COL_DEP_CHG

      . . exporting table                MTG_DATABASES

      ....

      . . exporting table              ALEX11_SYSUSERS

      . exporting referential integrity constraints

      . exporting triggers

      . end transportable tablespace metadata export

      Export terminated successfully without warnings.

4. Verifique a ordenação (endianness) do banco de dados de destino e converta, se necessário

—> Execute localmente a conversão do endian compatível antes da etapa de importação:

    rman target=/

    Recovery Manager: Release 10.1.0.1.0 - 64bit Beta

    connected to target database: V101B2 (DBID=3287908659)

    RMAN> convert tablespace 'TBS_DADOS,TBS_INDICE,USERS,TOOLS'

    2>  to platform='Linux x86 64-bit'

    3> FORMAT='/DADOS/FULL/transport_linux/%U';

5. Mova os datafiles e o arquivo do dump de exportação

——————————————————————

          $ftp tts.dmp

               +

                /database/db101b2/V101B2/datafile/reposit01.dbf (no conversion)

               or

                /tmp/reposit01.dbf (converted file if conversion had been required)

6. Importe os metadados

————————————————

       $ imp userid=\'/ as sysdba\' TRANSPORT_TABLESPACE=Y  file=spc_tts.dmp log=spc_imp_tts.log TABLESPACES= TBS_DADOS,TBS_INDICE,USERS,TOOLS datafiles=u01/transport_linux/dt.dbf,u01/transport_linux/idx.dbf,u01/transport_linux/users.dbf,u01/transport_linux/tools.dbf, (or /tmp/reposit01.dbf )

7. Altere as tablespaces importadas para READ WRITE

——————————————————————-

ALTER TABLESPACE TOOLS READ WRITE;

ALTER TABLESPACE USERS READ WRITE;

ALTER TABLESPACE TBS_DADOS  READ WRITE;

ALTER TABLESPACE TBS_INDICE  READ WRITE;

Preservando estatísticas ao transportar Tablespaces no Oracle

Este é um roteiro para transportar um tablespace sem ter que analisar novamente tabelas e índices. Isto naturalmente supõe que as estatísticas otimizadoras já tenham sido coletadas. O exemplo usa um schema chamado DEMO e um tablespace chamado TRANSTS.

1. Preserve as estatísticas:

exec DBMS_STATS.CREATE_STAT_TABLE ('DEMO','DEMOSTATS');

exec DBMS_STATS.EXPORT_SCHEMA_STATS ('DEMO','DEMOSTATS');

2. Transforme o tablespace em READ ONLY, como preparação para o transporte:

 ALTER TABLESPACE transts READ ONLY;

3. Verifique se não há nenhuma dependência que venha a violar as restrições de transporte:

 exec dbms_tts.transport_set_check('TRANSTS', TRUE);

SELECT * FROM transport_set_violations;

4. Exporte as definições de dicionário do tablespace:

 exp TRANSPORT_TABLESPACE=y TABLESPACES=transts \ TRIGGERS=y CONSTRAINTS=y GRANTS=y FILE=tts.dmp LOG=exptts.log

5. Faça um upload para um FTP ou copie os arquivos de dados e exporte o arquivo da origem para o destino;

6. Crie usuários no banco de dados alvo, caso eles ainda não tenham sido criados;

7. Ligue os tablespaces ao banco de dados alvo:

imp TRANSPORT_TABLESPACE=y \

     DATAFILES=('/opt/oracle/data/TRANSTS_1.dbf') \

     TABLESPACES=(transts) \

      FILE=tts.dmp LOG=imptts.log

8. Marque o tablespace como READ WRITE. Dessa forma, RMAN reconhecerá sua existência. Caso seja necessário, é possível reverter o ajuste do tablespace para READ ONLY:

 ALTER TABLESPACE transts READ WRITE;

9. Importe as estatísticas preservadas:

 exec DBMS_STATS.IMPORT_SCHEMA_STATS ('DEMO','DEMOSTATS');

Espero que seja útil para vocês o quanto foi útil para mim, boa leitura.

Como auditar e gerar relatórios de auditoria em Bancos de dado Oracle.

Habilitando Auditoria

O primeiro  passo é  habilitar a auditoria, para isso será  necessário mudar o parâmetro de inicialização audit_trail e definir o tipo de auditoria desejado:

OS : Auditoria Habilitada, os registros vão ser gravados em diretórios do sistema em arquivos de auditoria.
DB ou TRUE : Auditoria é habilitada, os registros de auditoria serão armazenadas no database (SYS.AUD$)
XML : Auditoria é habilitada, os registros serão armazenados em formatos XML.
NONE ou FALSE : Auditoria é desabilitada.
DB_EXTENDED : Trabalha igual ao parâmetro DB, mais as colunas SQL_BIND e SQL_TEXT são preenchidas.

Quando selecionamos os modos OS ou XML, são criados arquivos contendo os registros do auditoria no diretório definido pelo parâmetro audit_file_dest.

Considerando um tipo de auditoria DB, executaremos o seguintes comandos:

SQL> ALTER SYSTEM SET audit_trail = “DB” SCOPE = SPFILE;

SQL> shutdown immediate

SQL> startup

O artigo está divido em:

1. Conexões de auditoria administrativa
2. Auditoria no nível de objeto
3. Auditoria no nível de privilégio
4. Auditoria de Instruções

Mostrarei em cada seção o que pode ser auditado, como verificar o que é auditado e alguns exemplos de relatório de auditoria.

Auditando:
————————————–
A auditoria pode ser definida em nível de instrução, nível de objeto e nível de privilégio.
Existe também auditoria de conexões administrativas, que são registrados através de log.

1. Auditando Conexões administrativas
————————————–
Conexões administrativas são CONNECT INTERNAL e CONNECT / AS SYSDBA.

O usuário SYS é o usuário mais útil e importante para qualquer banco de dados Oracle. Vamos dar uma olhada como um DBA pode impedi-lo se ele está sendo mal utilizado.

Como auditar conta SYS

Há apenas dois parâmetros que precisam ser definidos para auditar qualquer conta SYS, o audit_file_dest e o AUDIT_SYS_OPERATIONS.
O primeiro define o local para arquivos de auditoria e o segundo liga ou deliga a auditoria do SYS com ON / OFF.

Os arquivos de auditoria serão criados no diretório definido pelo parâmetro audit_file_dest com o nome ora_.aud. Esse arquivo geralmente têm seguintes informações:

Arquivo de auditoria / u01/app/oracle/admin/ALEBD/adump/ora_14725.aud
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: hostname.domainname
Release: 2.6.9-34.ELsmp
Version: #1 SMP Fri Apr 12 13:52:53 EST 2011
Machine: i686
Instance name: ALEBD
Redo thread mounted by this instance: 1
Oracle process number: 25
Unix process pid: 134745, image: oracle@hostname.domainname (TNS V1-V3)

Tue Mar 6 13:21:31 2012
ACTION : ‘CONNECT’
DATABASE USER: ‘/’
PRIVILEGE : SYSDBA
CLIENT USER: oracle
CLIENT TERMINAL: pts/1
STATUS: 0

Com todas as informações relacionadas à sessão como ‘connect’ e todos os comandos válidos, ele fornece informações sobre o servidor, sistema operacional, versão, Maquina, etc. porém ele não armazena os comandos inválidos.

Os arquivos de auditoria também armazenam informações de logins inválidos. Para verificar logins inválidos, execute os seguintes comandos:

grep-i “status:” * aud | grep-i-v “status: 0″.

Parâmetros que devem ser definidos

alter system set audit_file_dest=’/u04/app/oracle/oradata/alex/audit’ scope=spfile;
alter system set audit_sys_operations=true scope=spfile;
Reinicie a banco de dados e pronto, está feito.

As Informações de auditoria podem ser visualizados em formato de texto ou no formato XML, dependendo da configuração do parâmetro AUDIT_TRAIL

2. Auditoria no nível de objeto
—————————
Objetos que podem ser auditados são: tabelas, visões, sequências, pacotes, procedimentos armazenados e funções. Note que, porque alguns objetos pode ser dependente de outrosobjetos (exemplo função -> visão -> tabela), vários registros de auditoria podem ser inseridos quando esses objetos forem auditados.

Opções de auditoria objeto são definidas para todos os usuários do banco de dados e não podem ser definidos
para usuários individuais.

Quais as opções que podem ser definidas? Isto pode ser visto a partir de all_def_audit_opts.

Exemplo opções de auditoria de objetos
——————————-

SQL> connect system / manager
SQL> select * from all_def_audit_opts;

Resultado:

ALT DEL AUD COM GRA IND INS LOC REN SEL UPD REF EXE
—————————————
- / – / – / – / – / – / – / – / – / – / – / – / – / -

Estes correspondem aos seguintes opções de objecto respectivamente:

alter, audit, comment, delete, grant, index, insert, lock, rename, select, update, reference e execute .

Todas as referências, excepto e executar pode ser aplicadas a tabelas, caso contrário você receberá o erro ora-1982 “opção inválida auditoria para tabelas”.

Exemplo de auditoria em SCOTT.EMP
—————————–

SQL> connect system / manager
SQL> audit select on scott.emp by session;

Confira: Quais objetos são auditados

SQL> col owner format a7
SQL> col object_name format a7
SQL> select * from dba_obj_audit_opts
where owner=’SCOTT’ and OBJECT_NAME=’EMP’;

resultado:

OWNER OBJECT_ OBJECT_TY ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE
——- ——- ——— — — — — — — — — — — — — —
SCOTT EMP TABLE -/- -/- -/- -/- -/- -/- -/- -/- -/- S/S -/- -/- -/-

Gera algumas informações de auditoria:

SQL> connect scott / tiger
SQL> select * from emp;
=> Todas as linhas de SCOTT.EMP são mostrados
SQL> connect t / tl
SQL> select * from SCOTT.EMP;
=> ERROR at line 1:
ORA-00942: tabela ou visão não existe
SQL> connect system / manager
SQL> select * from SCOTT.EMP;
=> Todas as linhas de SCOTT.EMP são mostrados

Resultados da auditoria:
SQL> connect system/manager

SQL> col username format a8
SQL> col priv_used format 999
SQL> /

SQL> select username, priv_used, ses_actions from dba_audit_object
where obj_name=’EMP’ and owner=’SCOTT’;

Resultado:
USERNAME PRIV_USED SES_ACTIONS
——– —————————————- —————-
SYSTEM SELECT ANY TABLE ———S—
T ———F—
SCOTT ———S—

3. Auditoria no nível de privilégio
——————————

Todos os privilégios de sistema podem ser auditados.
Diferentes privilégios podem ser selecionados a partir da system_privilege_map.
Se você tentar usar um valor que não pertence à lista, você receberáo seguinte erro:

SQL> audit drop snapshot by access;
audit drop snapshot by access
*
ERROR at line 1:
ORA-00956: opção ausente ou inválido de auditoria

Exemplo: privilégios de sistema auditáveis
————————————
SQL> connect system / manager
SQL> select * from system_privilege_map;

Resultado (este resultado é dependente da versão):

Nome do privilégio
———- —————————————-
-3 ALTER SYSTEM
-4 AUDIT SYSTEM
-5 CREATE SESSION
-6 ALTER SESSION
-7 RESTRICTED SESSION
-10 CREATE TABLESPACE
-11 ALTER TABLESPACE
-12 MANAGE TABLESPACE
-13 DROP TABLESPACE
….. Não estão sendo mostrados todos os resultados ……
-167 GRANT ANY PRIVILEGE
-172 CREATE SNAPSHOT
-173 CREATE ANY SNAPSHOT
-174 ALTER ANY SNAPSHOT
-175 DROP ANY SNAPSHOT
-194 WRITEDOWN DBLOW
-195 READUP DBHIGH
-196 WRITEUP DBHIGH
-197 WRITEDOWN
-198 READUP
-199 WRITEUP

Exemplo de auditoria no CREATE TABLE de Scott e System
————————————————– -

SQL> connect system/manager
SQL> audit create table by scott, system;
=> Audit succeeded.

Isto significa que cada create table é auditado para o system e o scott uma vez por sessão.
Cada um deve criar a tabela ser auditado, em seguida, a cláusula ‘by access’ deve ser adicionada.

verificar: Quais privilégios estão auditados

SQL> col user_name format a7
SQL> col privilege format a15
SQL> connect system/manager
SQL> select * from sys.dba_priv_audit_opts;

Resultado:

USER_NA PRIVILEGE SUCCESS FAILURE
——- ————— ———- ———-
SCOTT CREATE TABLE BY ACCESS BY ACCESS
SYSTEM CREATE TABLE BY ACCESS BY ACCESS

Gere algumas informações de auditoria:

SQL> connect scott / tiger
SQL> create table t1 (c1 number);
create table t1 (c1 number)
*
ERRO na linha 1:
ORA-00955: nome já está sendo usado por um objeto existente
SQL> create table tsc (c1 number);
= Table> criado
SQL> connect t / tl
SQL> create table tsc (c1 number);
=> Tabela criada
SQL> connect system / manager
SQL> create table scott.t1 (c1 number);
=> Create table scott.t1 (c1 number)
ERRO na linha 1:
ORA-00955: nome já está sendo usado por um objeto existente
SQL> create table tsc (c1 number);
=> Tabela criada

Resultados da auditoria:

SQL> connect system/manager

SQL> col username format a8
SQL> col priv_used format 999
SQL> /

SQL> select username, priv_used, ses_actions from dba_audit_object;
Resultado:

USERNAME PRIV_USED SES_ACTIONS
——– —————————————- ——————-
SCOTT CREATE TABLE
SCOTT CREATE TABLE
SYSTEM CREATE TABLE

SQL> connect system/manager

SQL> select action, action_name, username
from dba_audit_trail ;

Resultado:

ACTION ACTION_NAME USERNAME
———- ————————— ——–
1 CREATE TABLE SCOTT
1 CREATE TABLE SCOTT
1 CREATE TABLE SYSTEM

4. Auditoria no nível de instruções
———————-
Auditoria de instruções é uma auditoria seletiva de diversos grupos de comandos sql, esse comandos podem ser comandos ddl (data definition Language) ou comandos DML (Data Manipulation Language).

Por exemplo, quando o comando ‘audit table’ é auditado, comandos create, alter e drop table também são auditados.
Quando a instrução ‘audit select table’ é auditado todas as instruções select em tabelas, visões, Snapshots .. serão auditados.

A diferença com auditoria privilégio é que no último caso, um privilégio de sistema é auditado.
Por exemplo, ” audit create table ” só vai auditar o comando create table e não comandos de alter table ou drop table.

Quando instruções semelhantes e opções de privilégios são definidas apenas um registro de auditoria é gerado.

Exemplo: instruções auditáveis
—————————–
As instruções que podem ser aditadas podem ser visteas da stmt_audit_option_map.

SQL> connect system/manager
SQL> select * from stmt_audit_option_map;

Resultado (este resultado é dependente versão):

OPTION# NAME PROPERTY
———- —————————————- ———-
3 ALTER SYSTEM 0
4 SYSTEM AUDIT 0
5 CREATE SESSION 0
6 ALTER SESSION 0
7 RESTRICTED SESSION 0
8 TABLE 0
9 CLUSTER 0
10 CREATE TABLESPACE 0
11 ALTER TABLESPACE 0
12 MANAGE TABLESPACE 0
13 DROP TABLESPACE 0
….. não estão sendo mostrados todos resultados ……
221 CONTEXT 0
234 ON COMMIT REFRESH 0
235 EXEMPT ACCESS POLICY 0
236 RESUMABLE 0
237 SELECT ANY DICTIONARY 0
238 DEBUG CONNECT SESSION 0
239 DEBUG CONNECT USER 0
240 DEBUG CONNECT ANY 0
241 DEBUG ANY PROCEDURE 0
242 DEBUG PROCEDURE 0

165 rows selected.

SQL> select * from stmt_audit_option_map
where name like ‘%TABLE%’;

Resultado:

OPTION# NAME PROPERTY
———- —————————————- ———-
8 TABLE 0
10 CREATE TABLESPACE 0
11 ALTER TABLESPACE 0
12 MANAGE TABLESPACE 0
13 DROP TABLESPACE 0
14 TABLESPACE 0
15 UNLIMITED TABLESPACE 0
40 CREATE TABLE 0
41 CREATE ANY TABLE 0
42 ALTER ANY TABLE 0
43 BACKUP ANY TABLE 0
44 DROP ANY TABLE 0
45 LOCK ANY TABLE 0
46 COMMENT ANY TABLE 0
47 SELECT ANY TABLE 0
48 INSERT ANY TABLE 0
49 UPDATE ANY TABLE 0
50 DELETE ANY TABLE 0
54 ALTER TABLE 0
57 LOCK TABLE 0
58 COMMENT TABLE 0
65 SELECT TABLE 0
66 INSERT TABLE 0
67 UPDATE TABLE 0
68 DELETE TABLE 0
69 GRANT TABLE 0

Exemplo de Auditoria em TABELAS do Scott e System
———————————————

SQL> connect system/manager
SQL> audit table by scott, system;
=> Audit succeeded.

verifique: Quais declarações estão auditadas

SQL> col user_name format a8
SQL> col proxy_name format a6
SQL> col audit_option format a9
SQL> col privilege format a15
SQL> connect system/manager
SQL> select * from dba_stmt_audit_opts;
Resultado:

USER_NAM PROXY_ AUDIT_OPT SUCCESS FAILURE
——– —— ——— ———- ———-
SYSTEM TABLE BY ACCESS BY ACCESS
SCOTT TABLE BY ACCESS BY ACCESS

Gere algumas informações de auditoria:

SQL> connect scott/tiger
SQL> create table t1 (c1 number);
create table t1 (c1 number)
*
ERROR at line 1:
ORA-00955: name is already used by an existing object
SQL> drop table t1;
=> table dropped
SQL> connect system/manager
SQL> create table scott.t1(c1 number);
=> table created
SQL> drop table no;
=> *
ERROR at line 1:
ORA-00942: table or view does not exist

Resultados da auditoria:

SQL> connect system/manager

SQL> col username format a8
SQL> col priv_used format 999

SQL> select username, priv_used, ses_actions from dba_audit_object;

Resultado:

USERNAME PRIV_USED SES_ACTIONS
——– —————————————- ——————-
SCOTT CREATE TABLE
SCOTT CREATE TABLE
SYSTEM CREATE TABLE
SQL> connect system/manager

SQL> select action, action_name, username
from dba_audit_trail ;

Resultado:

ACTION ACTION_NAME USERNAME
———- ————————— ——–
1 CREATE TABLE SCOTT
12 DROP TABLE SCOTT
1 CREATE TABLE SYSTEM
12 DROP TABLE SYSTEM

SQL> select username, priv_used, ses_actions de dba_audit_object;

Resultado:

USERNAME PRIV_USED SES_ACTIONS
——– —————————————- ——————-
SCOTT CREATE TABLE
SCOTT
SYSTEM CREATE ANY TABLE
SYSTEM

Exemplo de auditoria SELECT TABLE do scott e system
————————————————– -

SQL> connect system/manager
SQL> audit select table by scott, system;
=> Audit succeeded.

Confira: Quais declarações são auditadas

SQL> col user_name format a8
SQL> col proxy_name format a6
SQL> col audit_option format a13
SQL> col privilege format a15
SQL> connect system/manager
SQL> select * from dba_stmt_audit_opts;

Resultado:

USER_NAM PROXY_ AUDIT_OPTION SUCCESS FAILURE
——– —— ————- ———- ———-
SYSTEM SELECT TABLE BY SESSION BY SESSION
SCOTT SELECT TABLE BY SESSION BY SESSION

Gere algumas informações para auditoria:

SQL> connect scott/tiger
SQL> delete from emp where ename=’KING’;

SQL> connect system/manager
SQL> insert into scott.emp (empno, ename) values (1, ‘TEST’);
SQL> select * from scott.emp;

Resultados da auditoria:

SQL> connect system/manager

SQL> col username format a8
SQL> col priv_used format 999

SQL> select username, priv_used, ses_actions from dba_audit_object;
Resultado:

USERNAME PRIV_USED SES_ACTIONS
——– —————————————- ——————-
SCOTT ———S——
SCOTT ———S——
SYSTEM ———S——
SYSTEM SELECT ANY TABLE ———S——
SYSTEM ———S——
SYSTEM ———S——
SYSTEM ———S——
SCOTT ———S——
SYSTEM ———S——
SYSTEM ———S——
SYSTEM ———S——

SQL> connect system/manager

SQL> select action, action_name, username
from dba_audit_trail ;

Resultado:

ACTION ACTION_NAME USERNAME
———- ————————— ——–
103 SESSION REC SCOTT
103 SESSION REC SCOTT
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM
103 SESSION REC SCOTT
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM
103 SESSION REC SYSTEM

Inicio este artigo falando sobre o ciclo de vida das ferramentas de desenvolvimento Oracle. Ciclo de vida, compreende um produto desde sua fase de lançamento, aquisição de maturidade através de inúmeras correções, patchsets e minipatches, até a sua completa substituição por uma nova versão/release, mudança de arquitetura ou o lançamento de um novo produto.

Obsolescência

Atualmente, muitas empresas ainda possuem aplicações grandes e complexas em releases antigos da plataforma Oracle, mais específicamente em Forms/Reports 4.5, 6i ou anterior. Estas versões já encerraram seu ciclo de vida, o que singnifica que suas aplicações estão fora da matriz de suporte e compatibilidade, e que se torna mandatório planejar em seus próximos orçamentos de T.I., investimentos para sua modernização. Oracle declara em seu documento “SOD – Statement of Direction (2009) para ferramentas de desenvolvimento”, que as ferramentas Forms/Reports não serão descontinuadas, porém a Oracle recomenda fortemente que as empresas se mantenham no topo de sua pilha de tecnologia (últimas versões), para garantir a plena estabilidade de seus produtos.

Modernização e Refactoring

A sequência de modernização recomendada ficaria da seguinte forma:
Duas camadas (Client-Server 4.5/6i ou anteriores) -> Três camadas (adição de Middletier em 11g) -> 100% Web/J2EE em ADF 11g.

Para aquelas empresas que pensam em simplesmente modernizar suas aplicações Forms/Reports, o caminho mais adequado, seria um projeto de migração de para a última versão (11g), modificando sua arquitetura de duas para três camadas. Para aquelas que alêm de modernizar suas aplicações, também têm o objetivo de seguir a tendência da tecnologia Oracle, o caminho mais adequado seria um projeto de refactoring (reescrita de parte do código) de suas aplicações para a arquitetura J2EE ADF 11g. A arquitetura ADF 11g utiliza o paradigma MVC (Model-View-Controller), dividindo a lógica da aplicação em camadas distintas: Controle, Modelo e Visual, o que permite o isolamento da lógica de negócios da aplicação da camada visual (front-end). Neste último modelo, o projeto certamente ficaria mais extenso e com custo mais elevado, porém garante um ciclo de vida mais longo e um visual mais leve e moderno às antigas aplicações.

Em resumo, seja qual for o caminho adotado: migrar ou refazer, o ponto é que existem caminhos viáveis para a modernização destas aplicações. É muito importante também optar por um profissional ou consultoria que tenha experiência e casos de sucesso neste tipo de projeto.

Eduardo Arruda – eduardo.arruda@domainconsult.com.br

Bem, minha bola de cristal dá “tela azul” toda vez que tento fazer previsões, mas podemos discutir alguns cenários que já estão claramente delineados.
Os desenvolvedores estão às voltas com uma verdadeira convergência tecnológica, onde Cloud Computing, mobilidade, social business, Big Data e Internet of Things requerem novas habilidades para o desenvolvimento de aplicações inovadoras. As empresas esperam que sejam desenvolvidas novas aplicações para novos dispositivos, para resolver novos tipos de problemas.

O desafio das empresas e de seus desenvolvedores é de criar estas novas aplicações, ao mesmo tempo em que devem manter as atuais funcionando sem interrupções. Em muitas organizações isso significa manter programas Cobol e escrever aplicações PHP ou Ruby simultaneamente.

As aplicações que farão diferença em um mercado altamente competitivo criam grandes oportunidades, mas ao mesmo tempo, geram novos desafios. Desenvolver uma aplicação usando interfaces touch-screen ou de reconhecimento de voz, que interaja com tecnologias de mídia social como Facebook ou Twitter demandam skills, métodos e processos diferentes. Por exemplo, a computação social demanda skills sociológicos e antropológicos para criar novos processos que atendam à demanda das interações sociais que os usuários desejam. Não espero que os desenvolvedores estudem a fundo antropologia, mas as equipes de desenvolvimento deverão ter uma multidisciplinaridade de skills que trabalharão em conjunto. Assim, métodos e práticas de desenvolvimento colaborativo serão fundamentais para a criação destas novas aplicações.

Também é desafiadora a criação de aplicativos que interajam com tecnologias de Big Data como Hadoop e MapReduce. Juntando com mobilidade e social business teremos aplicações socialytics (social business + business analytics) sendo acessadas por dispositivos móveis como smartphones e tablets.

Hadoop é um desafio à parte. Hadoop é um conjunto de diversos projetos Open Source desenvolvidos para trabalhar com grandes volumes de dados, de forma paralela. Para termos uma ideia do Hadoop pense que ele contém projetos como o Hadoop/MapReduce que é um framework Java para processamento paralelo, HDFS que é um sistema de arquivos distribuídos, Pig (linguagem de programação), Hive (linguagem similar ao SQL, chamado de HiveSQL), e diversos outros. Uma visita ao http://hadoop.apache.org/ mostra os diversos projetos associados ao Hadoop.

Cada projeto não necessariamente se integra com os demais e, portanto, é necessário um exaustivo trabalho de integração. Surgem então as distribuições Hadoop, que atuam mais ou menos de forma similar às distribuições Linux. Existem várias distribuições, cada uma com características diferentes. Entre as mais conhecidas temos a Cloudera, a InfoSphere BigInsight da IBM (que usa GPFS ou General Parallel File System) como alternativa ao HDFS, e DataStax, que usa Cassandra ao invés do HDFS. Portanto, muito estudo e trabalho pela frente!

O recente CES 2012 (Consumer Electronics Show) mostrou mais alguns futuros desafios para os desenvolvedores. Os interfaces estão saindo rapidamente do tradicional contexto teclado+mouse para multitouch, voz, gestos, reconhecimento facial e mesmo “eye tracking”. Já temos casos de sucesso: o Siri do iPhone 4S sinaliza que os usuários começarão a interagir com seus dispositivos através de comandos de voz. A Samsung anunciou um conjunto de APIs abertas e um SDK (Software Development Kit) para desenvolvimento de aplicações para sua Smart TV. Recentemente realizou uma competição para desenvolvedores criarem aplicativos para esta plataforma e coisas muito interessantes foram geradas. Vejam em http://www.samsungsmarttvchallenge.eu/. A LG anunciou o Gesture Cam, que permite o controle da TV através de gestos, de forma similar ao Kinect do Xbox360. Provavelmente em breve as diferenças entre PCs, TVs, smartphones e tablets serão apenas o tamanho da tela, uma vez que todos usarão os mesmos interfaces.

A Internet das Coisas (Internet of Things ou IoT) também abre novas frentes. Estamos falando de coisas como eletrodomésticos, automóveis, ativos das empresas (edifícios inteligentes, por exemplo) e infraestrutura das cidades conectadas à Interrnet e interagindo entre si e com os aplicativos corporativos. Quando adicionamos inteligência (leia-se software) aos objetos e eles começm a interagir e negociar entre si, isso nos abre inúmeras oportunidades de novos negócios. Claro que as empresas vão olhar esta possibilidade de obter vantagens competitivas com atenção. Um exemplo é a criação de uma logistica muito mais inteligente que a maioria das empresas tem hoje. Imaginem uma “self-controlled logistics”!

Bem, o que os executivos demandarão? Novos aplicativos que explorem a IoT e que por sua vez, demandam novos skills dos desenvolvedores como EDA (event-driven architecture). Um texto basico sobre EDA pode ser encontrado na Wikipedia.

Claro, .NET e Java continuarão a dominar o cenário das linguagens usadas nas empresas, pelo menos no horizonte previsível. Mas começam a surgir espaços para novas linguagens como Perl, Ruby ou PHP. Por brincadeira consultei algumas vagas de desenvolvedores para o Facebook e encontrei de maneira geral demandas por profissionais que conheçam Java e/ou C++ e tenham conhecimento de PHP, Perl ou Python, além, é claro de Hadoop.

Este cenário leva a outra discussão: até que pontos os métodos ágeis de desenvolvimento substituirão ou complementarão os métodos de desenvolvimento mais tradicionais? Me parece que os métodos ágeis estarão mais próximos da velocidade de resposta que os negócios demandam dos desenvolvedores. Além disso, está claro que os desenvolvedores nunca terão todas as respostas para as inúmeras demandas dos seus usuários. Aí é que entra o conceito das aplicações mashup. Os usuários passarão a também desenvolver pequenas aplicações em cima das APIs geradas pelos desenvolvedores. Veremos os desenvolvedores-cidadãos! E isso tende a se acelerar a medida que a geração digital se insere no mercado de trabalho. Eles entram nas empresas já com vários anos de prática na criação de apps para smartphones e tablets (são verdadeiros app entrepreneurs) e vão querer usar seus skills para desenvolver apps para interagirem com as aplicações corporativas.

Na minha opinião, as aplicações serão cada vez mais heterogêneas em tecnologias, misturando diversas linguagens no mesmo sistema. Além disso, novas funcionalidades deverão ser incorporadas de um dia para o outro. SOA (service-oriented architecture) e os métodos SODA (service-oriented development of applications) são a resposta.
Por tudo que debatemos, nosso amigo ficou mais preocupado ainda… Por outro lado enxergou que terá, como desenvolvedor, uma longa carreira pela frente!

SQL> startup mount

ORA-15032: not all alterations performed
ORA-15063: diskgroup “<DISK GROUP NAME>” lacks quorum of 2 PST disks; 0 found
Este erro pode ocorrer se:

a) disco ASM (s) não é visível no sistema operacional.
b) parâmetro ASM_DISKSTRING não está definido corretamente na instância ASM (s)
c) metadados ASM em disco foram substituídos ou corrompidos

Se você já viu esse erro ou outro erro indicando a corrupção metadados ASM e verificou que o disco(s) é visível com as permissões corretas no sistema operacional e que o parâmetro ASM_DISKSTRING está configurado corretamente, os seus Metadados ASM podem estar corrompidos. Se este for o caso, talvez seja necessário recriar sua instância ASM (s) e seus grupo de discos. As etapas são:

1. Garantir que você tenha um backup RMAN prévia de todos os bancos de dados usando ASM
2. Encerre a instância ASM (s)
3. Use dd para limpar os metadados a partir de discos ASM
4. Re-criar o seu grupo de discos ASM (s)
5. Restaurar bancos de dados

PASSO 1: Verifique se você tiver um RMAN Backup anterior de todos os bancos de dados usando ASM
————————————————– ————————

A única maneira que você pode se recuperar de corrupção de metadados ASM é ter uma Backup RMAN do banco de dados em uma área que não foi afetados por um falha da intancia ASM. Como parte de sua estratégia de recuperação, você deve considerar backup em fita ou uso de um outro storage terciário para salvaguardar os seus backups.

Exemplo de backup RMAN:

1. Conectar ao banco de dados RMAN alvo para backup

rman nocatalog target /

2. Faça o backup seu banco de dados, logs Arquivo e arquivos de controle. Exemplo:

RMAN> backup device type disk format ‘/u03/backup/%U’ database plus archivelog;
RMAN> backup device type disk format ‘/u03/backup/ctrlf_%U’ current controlfile;

3. Manualmente façar cópias de seus SPFILEs. Exemplo:

CREATE PFILE=’/u03/app/oracle/product/10.1.0/dbs/init<sid>.ora’
FROM SPFILE=’/+DATA/V10FJ/spfile.ora’;

Se você não tem um bom backup de todos os bancos de dados (datafiles, control_files, redo logs, logs de arquivo), NÃO CONTINUE ALÉM DO PASSO 1!

PASSO 2: DESLIGUE A INSTÂNCIA(S) ASM
————————————–

Pare de suas instâncias de banco de dados e instâncias ASM com sqlplus ou srvctl (RAC)

Exemplo SQLPLUS:

setenv ORACLE_SID +ASM
sqlplus ‘/ as sysdba’
SQL> shutdown immediate

setenv ORACLE_SID DBSCOTT
sqlplus ‘/ as sysdba’
SQL> shutdown immediate

SRVCTL (RAC) Exemplo:

srvctl stop asm -n <node name 1>
srvctl stop asm -n <node name 2>
srvctl stop database -d <DB_NAME>

PASSO 3: USE DD PARA LIMPAR O METADATA de discos ASM
————————————————– -

Todos os metadados ASM devem ser limpos antes de tentar re-criar instâncias ASM e diskgroups. Comando exemplo:

dd if=/dev/zero of=/dev/rdsk/c1t4d0s4 bs=8192 count=12800

PASSO 4: Recriar o seu grupo de disco(s) ASM
—————————————-

Definir o seu ORACLE_SID à sua instância ASM e criar uma novo diskgroup.
Exemplo:
setenv ORACLE_SID +ASM
sqlplus ‘/ as sysdba’
SQL> startup nomount
SQL> create diskgroup data disk ‘/dev/rdsk/c1t4d0s4′;
SQL> shutdown immediate
SQL> startup mount

PASSO 5: DATABASES RESTORE
——————————————————–
1. Use RMAN para restaurar os control_files e o banco de dados.
Exemplo:
rman target /
RMAN> restore controlfile from ‘/u03/backup/ctrlf_<string>’; — onde <string> é uma string unica gerada pelo %U.
RMAN> alter database mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open resetlogs;

2. Se conecte à instância ASM e obtenha o nome do controlfile.
Exemplo:
setenv ORACLE_SID +ASM
sqlplus ‘/ as sysdba’
SQL> select name, alias_directory from v$asm_alias;

Procure o nome controlfile no diretório on estão os CONTROLFILES :Exemplo

4. Editar o init <SID>. Ora e alterare o parâmetro para apontar para control_files, aquele identificado a partir da view v$asm_alias do ASM.

5. Recrie o spfile. Exemplo:

SQL> create spfile=’+DATA/V10FJ/spfileV10FJ.ora’
from pfile=’/u03/app/oracle/product/10.1.0/dbs/pfile.out’;

6. Deslige e reinicie a instância para usar o spfile recém-criado.

7. Repita o “PASSO 5″ seção para bancos de dados adicionais.

————————-

APÓS TODOS ESSES PASSOS É SOMENTE SUBIR A INTANCIA.

Inicie a instância usando a cópia local de seu pfile a partir do passo 1.

setenv ORACLE_SID DBALE
sqlplus ‘/ as sysdba’
SQL> startup nomount pfile=init<sid>.ora

É isso aí, espero ajudar muitas pessoas que sofreram com esse problema como eu sofri.

Além destas aplicações específicas, está se abrindo um espaço imenso para o uso de tablets e smartphones em qualquer setor de negócios. Hoje já somos tão dependentes dos nossos smartphones e tablets que nenhuma empresa pode impedir ou restringir seu uso corporativo. Um smartphone de hoje tem tanto poder computacional quanto um supercomputador dos anos 80, como o então famoso Cray (na época). Portanto, nenhuma empresa pode ignorar a potencialidade que cada usuário tem em suas mãos ou em seu bolso. Pelo contrário, deve incentivá-lo mais ainda, mesmo que isto demande novos desafios para a área de TI.

Uma maneira de vermos as mudanças que já estão em curso é olharmos para trás e compararmos o atual momento com o surgimento dos PCs. Na chamada era PC, existiam dois mundos: a Web, usada de forma pessoal, para buscas e acesso a sites, mais focada em entretenimento e utilizada em casa. Nas empresas o acesso às informações e sistemas ficava restrito aos PCs oficiais instalados dentro de seus escritórios. Os funcionários só tinham acesso aos sistemas desenvolvidos e mantidos pela área de TI. Com a disseminação da Web 2.0 e as mídias sociais, os funcionários passaram a acessar a Web também de seus PCs e laptops oficiais. Agora a Web já fazia parte das atividades profissionais. No atual mundo dos tablets e smartphones vemos que os funcionários estão conectados a qualquer hora e lugar, acessando não apenas sistemas internos, mas também a Web e de forma inovadora vemos aplicações integrando estes sistemas internos com apps externas disponíveis em apps markets. Um exemplo é acoplar o FourSquare e outras mídias sociais a aplicativos corporativos disponíveis ao pessoal de vendas, para eles encontrarem e reforçarem seus laços de relacionamento com seus potenciais clientes.

Outra mudança significativa é que antes a TI era única que homologava, comprava e emprestava os PCs e laptops aos funcionários. Nos tempos do BlackBerry também… mas, hoje os próprios funcionários trazem de casa seus tablets e smartphones e querem usá-lo na empresa. Saímos de um ambiente homogêneo e controlado para um ambiente heterogêneo, com cada usuário dispondo não só de smartphones diferentes, mas cada um deles acessando não apenas os aplicativos da empresa, mas os aplicativos que ele, usuário, seleciona nos mercados de apps.

Querem ter uma ideia das diferenças de uso entre laptops e smartphones? Vejam a tabela abaixo:

Tabela de Apps Móveis

O desafio para a área de TI é que estes aparelhos estão entrando nas empresas por todos os lados. Impedir seu uso é impossível, mas é necessário criar procedimentos que garantam a segurança e privacidade dos dados considerados críticos para o negócio. Sim, é um belo desafio. Os modelos tradicionais de controle e homologação não são mais adequados ao mundo dos smartphones. Não é simples separar o lado profissional do pessoal. O FourSquare que citei no exemplo acima. É de uso pessoal? Mas se acoplado ao sistema de CRM da empresa, não passa a ser corporativo? A área de TI tem que começar colocar em prática novos métodos de gestão, adotando tecnologias específicas de MDM (Mobile Device Management), que permitam obter um nível de gerenciamento adequado aos seus requerimentos de governança, muitos deles forçados pelo compliance a regulações a que estão sujeitas. Recomendo a leitura de um artigo muito interessante, publicado em 2010, pela InfoWorld, que mostra uma tabela comparativa dos recursos de segurança dos sistemas operacionais dos smartphones. Vejam em http://tinyurl.com/4vh8rm3. Não está 100% atualizado, mas serve de referência para um estudo mais aprofundado. Outra alternativa a ser considerada é o uso de virtualização nos próprios smartphones, criando ambientes separados (pessoal e profissional) no mesmo dispositivo. Existem algumas alternativas despontando no mercado como a MVP (Mobile Virtualization Platform) da VMWare e o conceito de hypervisor, adotado pela Open Kernel Labs.

O mundo dos smartphones e tablets abre oportunidades de interação que não existiam nos laptops e PCs. Nestes a interação era basicamente o consumo e a criação de conteúdo, que requer apenas um interface simples, como tela e mouse/teclado. Com recursos como GPS, câmeras fotográficas/vídeo e novos interfaces como voz, gestos e outros, o engajamento e interação dos usuários com os aplicativos torna-se muito mais abrangente. Um exemplo simples: você interage de forma totalmente diferente com um game através do Kinect ou Wii que usando apenas os teclados e o mouse. Neles você imerge no próprio jogo. Com novos interfaces dos smartphones será a mesma coisa. O nível de engajamento será diferente do simples ouvir, falar e teclar.

Temos aí outro desafio para a área de TI. Os seus aplicativos deverão ter sua camada de interface redesenhadas para explorar as características dos smartphones e tablets. Hoje foram desenhados para explorar o paradigma do interface via teclado e mouse. Não tem interfaces intuitivos como as apps dos smarthones e isso vai demandar um bom trabalho de redesenho dos interfaces. Provavelmente veremos HTML5 começando a dar sinais de vida nos aplicativos corporativos! Veremos também a área de TI escrevendo novos aplicativos, voltados para explorar as funcionalidades intrínsecas dos smartphones como localização geográfica, acelerômetros, compassos, sensores de proximidade, câmeras fotográficas, etc. Estes aplicativos deverão explorar o fato dos usuários estarem com seus smartphones em locais e situações que não estariam com seus PCs e laptops e ao mesmo tempo eles querem que sua experiência de uso seja similar a que já estão acostumados a ter nestes dispositivos.

Os CIOs não podem esperar o mundo dos smartphones chegar. Ele já chegou. No mundo do PCs ele tinha o controle da situação. Hoje, os usuários podem acessar dados e apps de nuvens sem passar pela área de TI. Podem baixar aplicativos e os usarem em lugar de aplicativos oficiais. E manter os dados em nuvens como o DropBox. O que os CIOs devem fazer? Não lutar contra.

Mas, engajar-se ativamente e fazer com que a área de TI seja a influenciadora deste mundo wireless. O usuário tem em suas mãos um supercomputador dos anos 80 e impedir seu uso seria um contrassenso. Mas, apoiando e influenciando melhores práticas para seu uso é uma estratégia vencedora.

A conversa gerou algumas conclusões interessantes, que compartilho aqui:

a) TI não poderá desenvolver tudo sozinho. Deixe os usuários desenvolverem e escolherem seus aplicativos, mas exerça influência sobre o processo. Crie iniciativas de “P&D” interno, apoiando os usuários a criarem suas próprias soluções e interfaceando estas soluções via APIs seguras (estas desenvolvidas por TI) aos sistemas corporativos.

b) Adote práticas, métodos e tecnologias que permitam implementar a política de BYOD (Bring Your Own Device) na empresa. Uma sugestão é começar ao poucos, liberando a política primeiro a alguns setores e depois aos demais. É um aprendizado que só se vai se dar na prática. Não existe nenhum manual que oriente como fazer isso com sucesso.

c) Não seja pessimista e nem otimista ao extremo. Provavelmente durante muito tempo existirão PCs, laptops, smartphones e tablets. Alguns funcionários deixarão de usar laptops e PCs, mas outros continuarão a usá-los. Uma estratégia de adoção e disseminação da mobilidade e estudos de payback ajudarão na tomada de decisão. Não esqueça que um uso descontrolado de redes 3G poderá aumentar em muito os custos operacionais.

d) Mude o modelo de gestão e governança de TI. Os modelos atuais foram criados para o mundo PC. Modelos como o BYOD e a heterogeneidade de dispositivos vai demandar novas práticas e processos. Uma sugestão seria adotar um processo evolutivo, ajustando e aperfeiçoando as práticas à medida que mais experiências forem sendo adquiridas, tanto pelos usuários, como pela própria área de TI.

e) Não ignore a necessidade de novos skills e tecnologias. Os seus desenvolvedores tem fluência em HTML5, Android e iOS? Existem tecnologias de MDM na organização? A sua equipe de segurança está devidamente preparada para este novo mundo?

No final ficou a questão: Os CIOs tem a grande oportunidade de catalisar, liderar e influenciar este mundo dos smartphones e tablets. Mas o trem já está deixando a estação. Não podem apenas ficar olhando… Neste caso outros liderarão o processo.

Temos que agregar valor aos acionistas na entrega de cada projeto e temos que fazer nosso trabalho de forma mais humana e em parte para que possamos fazer coisas melhores.

Agregando valor de forma rápida, os gestores e os acionistas dentre outros tornam o negócio mais rentável e também tiram proveito dos métodos ágeis.

Minha sensação é que tem sido explicado e conversado muito sobre ser ágil, mas para as pessoas de negócios nunca é suficiente, pois todas as coisas maravilhosas sobre métodos ágeis representam para muitos executivos somente algo bonito numa apresentação e/ou anarquista onde o projeto vai perder o controle. Porém, ao estudar e entender os frameworks ágeis fica claro que não existe anarquia, nem perda de controle e sim um foco na entrega de valor.

Existem vários frameworks ágeis e dentre eles estão Extreme Programming (XP), Scrum, Lean Software Development, Kanban, Feature Driven Development (FDD), Adaptive Software Development (ASD), Agile Unified Process (AUP), Essential Unified Process (EssUP), Dynamic Systems Development Method (DSDM), Crystal, etc.

Claro que não existe bala de prata nos métodos ágeis que mate todos os monstros que virão, mas existe um foco no valor e isso é o mais relevante.

Finalmente, para quem ainda é cético, vale a pena olhar a certificação ágil criada pelo PMI e os estudos apresentados pelo Gartner Group dentre outros, pois deixam claro que é possível se beneficiar desta forma de pensar.

Este artigo visa apresentar os motivos pelos quais não se utiliza a técnica APF (Análise por Ponto de Função) nos processos e projetos relacionados à implementação, suporte e melhorias de ERPs.

2 – ERP

2.1 – Definição

Sistemas Integrados de Gestão Empresarial (SIGE ou SIG), em inglês Enterprise Resource Planning (ERP), são sistemas de informação que integram todos os dados e processos de uma organização em um único sistema. A integração pode ser vista sob a perspectiva funcional (sistemas de: finanças, contabilidade, recursos humanos, fabricação, marketing, vendas, compras, etc.) e sob a perspectiva sistêmica (sistema de processamento de transações, sistemas de informações gerenciais, sistemas de apoio à decisão, etc.). Os ERPs, em termos gerais, são uma plataforma de software desenvolvida para integrar os diversos departamentos de uma empresa, possibilitando a automação e armazenamento de todas as informações de negócios.

2.2 – Objetivo

O objetivo do ERP é a gestão integrada dos negócios das Empresas.

2.3 – Tarefas Envolvidas

A seguir descrevemos sucintamente as tarefas envolvidas no ciclo de vida de um ERP numa Empresa.

2.3.1 – Implementação

As tarefas a seguir estão relacionadas com o ciclo de Implementação, ou Instalação, do ERP na Empresa usuária.

2.3.1.1 – Levantamento das Necessidades

Esta tarefa consiste em obter todas as informações necessárias à Implementação correta do ERP na Empresa usuária de forma que o mesmo cubra a maior parte das necessidades de negócio da Empresa que estejam no escopo previsto na contratação do ERP.

Este levantamento é realizado através de entrevistas com os Usuários Chave da Empresa usuária e a definição do escopo detalhado deve ser validada tanto pela fornecedora do ERP, quanto pela Direção da Empresa usuária a fim de alinhar todas as expectativas que envolvem a Implementação do ERP.

Esta tarefa se inicia durante o processo de pré-venda do ERP em um nível superficial e vai, passo a passo, sendo aprofundado durante o processo técnico-comercial e chega a seu ponto de maior profundidade no início do Projeto de Implementação do ERP.

Esta tarefa envolve tanto o conhecimento do negócio por parte dos Usuários Chave da Empresa usuária, quanto o conhecimento das melhores práticas de mercado e das funcionalidades fornecidas pelo ERP por parte dos Consultores do Fornecedor do ERP, para que possam ser definidos, ao final desta tarefa, qual será a abrangência das demais tarefas no Projeto de Implementação, isto é, Parametrização/Configuração, Customização, Capacitação, Testes Unitários e Testes Integrados.

Esta tarefa pode utilizar até 10% (dez por cento) dos esforços envolvidos no Projeto de Implementação.

2.3.1.2 – Parametrização/Configuração

Esta tarefa consiste em Parametrizar/Configurar o ERP para atender às Necessidades de Negócio da Empresa usuária conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Parametrizar/Configurar consiste em imputar valores nos parâmetros disponíveis no ERP a fim de que este se comporte da maneira pretendida pelo Fornecedor do ERP e desejada pela Empresa usuária.

Parametrizar/Configurar NÃO envolve qualquer tipo de programação/codificação, uma vez que toda Parametrização/Configuração se restringe às funcionalidades oferecidas como padrão pelo ERP.

Esta tarefa pode utilizar até 50% (cinquenta por cento) dos esforços envolvidos no Projeto de Implementação.

2.3.1.3 – Customização

Esta tarefa consiste em ajustar, através de programação/codificação, as funcionalidades oferecidas como padrão pelo ERP a fim de atender às Necessidades de Negócio da Empresa usuária que não possam ser atendidas através de Parametrização/Customização das funcionalidades oferecidas como padrão pelo ERP conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa consiste, ainda, em desenvolver, através de programação/codificação, novas funcionalidades, originalmente não oferecidas como padrão pelo ERP, a fim de atender às Necessidades de Negócio da Empresa usuária que não possam ser atendidas através de Parametrização/Customização das funcionalidades oferecidas como padrão pelo ERP conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 20% (vinte por cento) dos esforços envolvidos no Projeto de Implementação.

2.3.1.4 – Capacitação

Esta tarefa consiste em capacitar os Usuários, Chave e/ou Finais, da Empresa usuária nas funcionalidades padrão do ERP Parametrizadas/Configuradas, bem como nas funcionalidades padrão do ERP Customizadas e nas funcionalidades Desenvolvidas, para o atendimento às Necessidades de Negócio da Empresa usuária conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 5% (cinco por cento) dos esforços envolvidos no Projeto de Implementação, e, proporcionalmente, até 1% (um por cento) deste esforço, especificamente para a Capacitação nas Customizações.

2.3.1.5 – Testes Unitários

Esta tarefa consiste em testar, de forma unitária, cada uma das funcionalidades Parametrizadas/Configuradas ou Customizadas nas tarefas anteriores a fim de garantir sua aderência individual em relação ao resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 10% (dez por cento) dos esforços envolvidos no Projeto de Implementação, e, proporcionalmente, até 2% (dois por cento) deste esforço, especificamente para a Capacitação nas Customizações.

2.3.1.6 – Testes Integrados

Esta tarefa consiste em testar, de forma integrada, todas as funcionalidades Parametrizadas/Configuradas e Customizadas nas tarefas anteriores a fim de garantir sua aderência, como conjunto, em relação ao resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 20% (vinte por cento) dos esforços envolvidos no Projeto de Implementação, e, proporcionalmente, até 4% (quatro por cento) deste esforço, especificamente para a Capacitação nas Customizações.

2.3.2 – Suporte Pós-Implementação

As tarefas a seguir estão relacionadas com o ciclo de vida que ocorre após a Implementação, ou Instalação, do ERP na Empresa usuária.

2.3.2.1 – Software

As tarefas a seguir estão relacionadas com o ERP propriamente dito enquanto conjunto de programas de computador que oferece uma miríade de funcionalidades que visam atender, de forma padrão, às Necessidades de Negócio das Empresas usuárias.

Estas tarefas são de responsabilidade exclusiva do fornecedor do ERP e são cobertas pelo contrato de Manutenção e Suporte firmado entre o fornecedor do ERP e as Empresas usuárias.

2.3.2.1.1 – Correção

Esta tarefa consiste em corrigir comportamentos diferentes do previsto/definido por algum dos programas que compõe o ERP e consiste em ajustar, através de programação/codificação, a funcionalidade em desalinho.

2.3.2.1.2 – Melhoria

Esta tarefa consiste em ampliar o espectro de abrangência de uma funcionalidade já disponibilizada no ERP, ou incluir uma nova funcionalidade na lista das já oferecidas às Empresas usuárias.

Esta tarefa consiste em ajustar, ou desenvolver, através de programação/codificação, a funcionalidade a ser aprimorada ou incluída.

2.3.2.2 – Parametrização/Configuração

As tarefas a seguir estão relacionadas com o Projeto de Implementação do ERP na Empresa usuária e depende de alterações no cenário em que esta Empresa atua, quer por motivos internos (aumento de vendas, mudanças de processo, etc.), quer por motivos externos (ruptura tecnológica, mudanças em seu mercado de atuação, alterações legais ou fiscais, etc.), ou é consequência de incorretude na execução das tarefas Teste Unitário e Teste Integrado descritas acima.

Parametrizar/Configurar NÃO envolve qualquer tipo de programação/codificação, uma vez que toda Parametrização/Configuração se restringe às funcionalidades oferecidas como padrão pelo ERP.

2.3.2.2.1 – Correção

Esta tarefa consiste em corrigir comportamentos diferentes do previsto/definido por alguma das parametrizações/configurações das funcionalidades padrão do ERP e consiste em ajustar, através de configuração/parametrização a funcionalidade em desalinho.

2.3.2.2.2 – Melhoria

Esta tarefa consiste em ajustar às novas necessidades de negócio da Empresa usuária os comportamentos diferentes dos atualmente necessários, por alguma alteração no cenário em que esta Empresa atua, as parametrizações/configurações das funcionalidades padrão do ERP em desalinho.

2.3.3 – Customização

As tarefas a seguir estão relacionadas com o Projeto de Implementação do ERP na Empresa usuária e depende de alterações no cenário em que esta Empresa atua, quer por motivos internos (aumento de vendas, mudanças de processo, etc.), quer por motivos externos (ruptura tecnológica, mudanças em seu mercado de atuação, alterações legais ou fiscais, etc.), ou é consequência de incorretude na execução das tarefas Teste Unitário e Teste Integrado descritas acima.

2.3.3.1.1 – Correção

Esta tarefa consiste em corrigir comportamentos diferentes do previsto/definido por alguma das customizações e consiste em ajustar, através de programação/codificação, a funcionalidade em desalinho.

2.3.3.1.2 – Melhoria

Esta tarefa consiste em ajustar às novas necessidades de negócio da Empresa usuária os comportamentos diferentes dos atualmente necessários, por alguma alteração no cenário em que esta Empresa atua, as customizações e consiste em ajustar, através de programação/codificação, a funcionalidade em desalinho.

2.3.4 – Elucidação de Dúvidas de Usuários

Esta tarefa consiste em elucidar dúvidas dos Usuários, Chave ou Finais, da Empresa usuária em relação ao pleno uso das funcionalidades do ERP implementadas nesta Empresa, quer através de Parametrização/Configuração, quer através de Customização, bem como elucidar dúvidas destes Usuários quanto à possibilidade de incremento destas funcionalidades a fim de efetivar todo o potencial que é oferecido pelo ERP.

Esta tarefa NÃO envolve qualquer tipo de Programação/Codificação ou Parametrização/Configuração. 

3 – APF (Análise por Ponto de Função)

3.1 – Definição

Método Padrão para medir Software do ponto de vista do Usuário através da quantificação da funcionalidade fornecida e prevê que estas medidas são “afinadas” pela repetição de projetos equivalentes.

3.2 – Objetivo

Medir o desenvolvimento e melhoria/manutenção de SOFTWARE de forma independente da tecnologia utilizada para sua implementação.

3.3 – Resultados

A APF é uma técnica eficaz na geração de indicadores para a gerência de projetos de software[1].

4 – Conclusão

Em função da APF (Análise por Ponto de Função) ser um Método cujo objetivo é a medição prévia e a gestão de Projetos de Software, e os Projetos de Implementação e Pós-Implementação de ERP não poderem ser caracterizados como Projetos de Software uma vez que não são intrinsecamente ligados à codificação/programação, os Projetos de Implementação e de Pós-Implementação não podem ser metrificados e/ou gerenciados pela APF.

No limite, apenas 27% (vinte e sete por cento) de um Projeto de Implementação de ERP estão intrinsecamente ligados à codificação/programação, conforme lista de tarefas a seguir:

• Customização
• Capacitação (no que tange às Customizações)
• Testes Unitários (no que tange às Customizações)
• Testes Integrados (no que tange às Customizações)

Este percentual não é suficientemente relevante para que todo o Projeto de Implementação de ERP seja metrificado e/ou gerenciado pela APF.

Os Projetos de Implementação de ERP não possuem repetição em relação aos itens de Customização, uma vez que se estes itens passarem a se repetir a funcionalidade inerente a estes deve passar a ser fornecida de maneira padrão pelo ERP e deixará de ser Customização, passando a se tratar de uma Parametrização/Configuração e, novamente, não podendo ser metrificada e/ou gerenciada pela APF.

Em se tratando de Projetos de Pós-Implementação, das seguintes tarefas, apenas as duas últimas estão relacionadas com as Empresas usuárias do ERP, e são de volume estatisticamente pouco representativo, cerca de 25% (vinte e cinco por cento), o que não as torna suficientemente relevante para que todo o Projeto de Pós-Implementação de ERP seja metrificado e/ou gerenciado pela APF.

• Correções de Software (de responsabilidade e visibilidade restritas ao fornecedor do ERP)
• Melhorias de Software (de responsabilidade e visibilidade restritas ao fornecedor do ERP)
• Correções de Customizações
• Melhorias de Customizações

Assim, pelas razões expostas acima, o APF não se aplica a Projetos de Implementação e Pós-Implementação de ERPs.

Para continuar sobrevivendo nos dias atuais, as empresas precisam buscar continuamente caminhos para cortar custos operacionais e obter vantagens competitivas, pois se assim não o fizerem seus concorrentes certamente o farão, deixando-as para trás. Uma das formas que as empresas têm procurado para se manter competitivas é automatizar seus fluxos de trabalho através do uso de aplicações de produtividade tais como ferramentas de gerenciamento de conteúdo eletrônico (ECM) e automação de escritório.

Entretanto, devido ao fato destes processos requererem aprovações formais e estarem sujeitos a regulamentações, as empresas são levadas a pensar que seus sistemas de gerenciamento de conteúdo eletrônico não são capazes de operar sem o uso do papel. Assim, elas voltam a imprimir documentos em papel para que sejam fisicamente assinados, depois digitalizados, arquivados, encaminhados aos seus signatários e, muitas vezes, extraviados durante este processo. Isto literalmente emperra processos de negócios tidos como eficientes, ao mesmo tempo em que aumenta os custos operacionais.

Automatizando Processos de Aprovação e Formalização

Muitos processos dentro do fluxo de trabalho de uma empresa requerem aprovações ou autorizações formais. Um caminho ideal para resolver esta questão passa pela adoção de uma solução corporativa de assinatura digital que permita automatizar os processos de aprovações, formalizações e autorizações, possibilitando à empresa manter um controle completo sobre todo o fluxo, desde a criação do documento até a sua formalização (assinatura), arquivamento e auditoria. Esta solução aumenta o retorno que a empresa terá sobre o investimento inicial, necessário para a implantação do processo de automatização do negócio, à medida que não será mais necessário interromper o processo eletrônico para reintroduzir o papel (documento físico) no processo.

Cada contrato em papel, formalizado através da assinatura de próprio punho, custa para as empresas, dentro de uma estimativa extremamente conservadora, a importância de R$ 37,87 em impressão, cartórios, transporte e encaminhamento, digitalização, arquivamento e perda e recuperação de documentos. Embora um pouco menores (cerca de 30% menores) estes mesmos custos são experimentados pelas outras partes de cada contrato (fornecedores, parceiros, etc.).

Implementar uma solução de assinatura digital de contratos eletrônicos pode significar uma redução, dependendo do cenário analisado, de até 80% dos custos tidos com o processo de formalização de contratos baseados em papel. Como o investimento inicial para a implantação da solução é extremamente baixo, o prazo para o retorno do investimento é seguramente muito curto, não ultrapassando pouquíssimos meses ou até mesmo dias, mesmo em cenários onde existe a necessidade de serviços de integração e/ou personalização. Com a assinatura digital, seus clientes, fornecedores e parceiros de negócios também estarão se beneficiando, não só da redução dos custos, mas também da otimização dos processos.

Nos próximos artigos estaremos detalhando os custos inerentes ao processo de formalização de contratos, demonstrando as vantagens da adoção da assinatura digital.

A Green Hat foi adquirida pela IBM no início de 2012 com o objetivo de integrar o portfólio de produtos RATIONAL voltados à qualidade de software e assim fortalecer a estratégia da IBM em oferecer soluções que favorecem o desenvolvimento ágil.

Um dos princípios da metodologia ágil é “satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado” e isto pode ser alcançado com as soluções Green Hat, que permitem aos desenvolvedores conduzir testes durante a fase de desenvolvimento, através de um ambiente virtualizado, o qual tem a capacidade de simular serviços dependentes e aplicações inteiras, proporcionando testes de integração com outros sistemas sem a necessidade de se construir um laboratório de testes, com todos os artefatos de hardware e software que compõem o ambiente de produção.

Imagine o desenvolvimento de uma aplicação que se comunica com muitos outros sistemas e com os mais diversos protocolos e tecnologias como HTTP, web services, SOA, JMS, TIBCO, IBM WebSphere MQ e SAP. Nestes casos, construir uma infraestrutura física ou instâncias na nuvem para fins de teste vai demandar tempo dos desenvolvedores além de ser caro para a empresa. Com as soluções Green Hat é possível a criação de “serviços virtuais” que simulam o comportamento de um aplicativo inteiro. Estes “serviços virtuais” podem rodar em um hardware commodity, em uma nuvem privada ou pública e assim, cada desenvolvedor e analista de testes, pode facilmente ter seu próprio ambiente de teste.

Utilizar o tempo dos desenvolvedores para garantir produtos de alta qualidade, minimizar o custo de desenvolvimento e entregar produtos com maior agilidade é primordial em todos os mercados.

Considerando a atual demanda de mercados em expansão como smartphones e tablets, que requerem cada vez mais aplicações, estes requisitos são ainda mais evidentes, pois os consumidores esperam produtos que atendam totalmente as suas expectativas, de maneira segura e sem bugs. Neste cenário, ao utilizar as soluções Green Hat, um ambiente de teste virtual pode ser configurado numa questão de minutos versus semanas, e também, por uma fração do custo que seria montar este ambiente físico.

Sintetizando, as soluções Green Hat promovem:

• Redução do Custo de Testes de Software:
  • Custos de infraestrutura na construção do laboratório de testes podem ser reduzidos em até 90%;
  • O trabalho envolvido na criação de ambientes de teste pode ser reduzido em até 80%;
  • O custo atrelado a testes envolvendo tecnologias de terceiros e taxas de serviço podem ser diminuídos  ou eliminados.
• Redução do Ciclo de Desenvolvimento do Software:
  • Ambientes de teste podem ser configurados em minutos versus semanas;
  • Os analistas de testes podem focar sua atuação nos testes, ao invés de usarem seu tempo na configuração dos ambientes de teste;
  • Mais testes de regressão podem ser feitos durante o desenvolvimento, ou seja, haverá maior garantia que não surgirão novos defeitos em componentes já testados.
• Aumento da Qualidade do Software:
  • Os desenvolvedores possuem recursos para testar o software durante o desenvolvimento, ainda na camada API (Application Programming Interface).
  • Grandes equipes que trabalham em diferentes partes de um aplicativo podem efetivamente fazer desenvolvimento paralelo por meio da virtualização de diferentes partes do sistema, promovendo a colaboração.

Acompanhe os próximos artigos e saiba mais sobre a solução Green Hat, pois falaremos sobre casos reais e como empresas nos Estados Unidos, Europa e Austrália estão se beneficiando destas soluções.

Para mais informações, contate arodacki@br.ibm.com